Bạn có thực sự phải làm BDD / TDD theo cách thử nghiệm đầu tiên không?

Mặc dù tôi chưa từng tham gia dự án TDD hoặc BDD, hoặc tôi đã từng nói rằng họ đang làm TDD nhưng cách đó khá xa, đây là những điều tôi nghĩ và thực sự cố gắng đọc nhiều nhất có thể trong khoảng.

Quay lại câu hỏi. Khi bạn đang thực hiện BDD, bạn nên viết "bài kiểm tra" của mình trước và làm cho nó thất bại, phải không? Và sau đó thực hiện tính năng đó hoặc những gì bạn gọi nó. Nhưng nếu bạn thực hiện điều này đến cùng cực thì đây có thể là một kiểu phát triển từ trên xuống không? Bạn đang nhìn vào UI của bạn và nói, "Tôi muốn có tính năng / hành vi này ở đây". Sau đó, bạn sửa UI của mình để thực hiện tính năng đó và mã hỗ trợ UI. Tại thời điểm này, bạn chưa thực hiện bất kỳ logic kinh doanh hoặc logic truy cập dữ liệu nào, bạn vừa thực hiện hành vi của mình. Những gì tôi đang nhắm đến thay vì viết bài kiểm tra trước tiên bạn viết mã UI của bạn trước. Trong một số trường hợp, nó sẽ dẫn đến cùng một mã cho lớp truy cập dữ liệu và lớp doanh nghiệp, vì bạn sử dụng mã UI để xác định những gì doanh nghiệp của bạn cần hỗ trợ.

Tất nhiên, bạn nên bổ sung điều này bằng các thử nghiệm được sử dụng để đảm bảo rằng tính năng này hoạt động như trong tính năng.

Có suy nghĩ gì không?

Bạn đang nói về BDD từ góc độ cao về kiểm tra giao diện người dùng của bạn. Kiểm tra là một chút mịn hơn ở cấp độ này so với thấp hơn trong mã bên Javascript / máy chủ của bạn.

Một số cuốn sách tôi đã đọc trên TDD nói rằng bạn nên viết mã như thể các hệ thống cơ bản tồn tại và chỉ cần viết đủ để bài kiểm tra của bạn vượt qua. Bạn có thể viết sơ khai trên máy chủ để vượt qua các bài kiểm tra hành vi UI. Sau đó, bạn bắt đầu tại đường may sơ khai này và viết một số bài kiểm tra đơn vị cho mã phía máy chủ của bạn và tìm cách thực hiện đầy đủ.

Tôi thường mã hóa như thể các lớp bên dưới tồn tại để vượt qua bài kiểm tra cấp độ cao, nó có cảm giác như đi xuống một lỗ thỏ và trích xuất nhiều lớp khác để đáp ứng bài kiểm tra cấp cao, sau đó viết bài kiểm tra cho các cấp độ thấp hơn này. Như bạn đã nhận ra, nó giúp bạn tập trung bắt đầu với các bài kiểm tra cấp cao hơn.

Như bất kỳ lập trình viên dày dạn nào cũng biết, có rất nhiều lớp để phát triển phần mềm. Tôi có xu hướng làm việc thấp hơn UI và nghĩ về dữ liệu hoặc hành vi mà UI của tôi cần từ máy chủ và bắt đầu từ đó (có thể vì tôi không làm nhiều UI trong những ngày này).

Nếu tôi thực sự trung thực, trích xuất một lớp từ các lớp bên dưới có nghĩa là tôi không thực hiện kiểm tra trước nhưng ... trong vài phút hoặc đôi khi vài giờ tôi sẽ kiểm tra mã đó. Điều này vẫn mang lại lợi ích cho tôi khi tôi giúp xem nơi bạn có thể cần cung cấp phụ thuộc cho một lớp và tôn trọng nguyên tắc trách nhiệm duy nhất - nếu khó kiểm tra, bạn đang làm quá nhiều ở một nơi, v.v.

Đúng! Mặt khác, những gì bạn nhận được là thử nghiệm theo định hướng phát triển .

Tuy nhiên, thực tế mà nói, có những vấn đề khó tiếp cận bằng cách sử dụng TDD "thuần túy". Bạn có thể viết hiệu quả hơn bằng cách viết một số mã sản xuất chưa được phát hiện lên trước và bao quát nó bằng các bài kiểm tra sau (và học cách tiếp cận các vấn đề tương tự với TDD trong tương lai). Nhìn vào kỹ thuật này , mà tác giả của nó gọi là TDD rửa và lặp lại vì muốn có một thuật ngữ tốt hơn.

Nếu bạn không viết bài kiểm tra của mình trước tiên, bạn sẽ không thúc đẩy sự phát triển thông qua các bài kiểm tra của mình. Ergo, bạn không làm phát triển dựa trên thử nghiệm!

Nếu bạn muốn làm việc theo cách này, đi cho nó. Nhưng đó không phải là sự phát triển dựa trên thử nghiệm.

Những gì bạn mô tả nghe có vẻ giống như phương pháp Thiết kế Front-Ahead . Thật không may, Front-Ahead Design là cú đâm châm biếm của Alex Papadimoulis vào các phương pháp nhanh nhẹn.

Cá nhân, tôi tin rằng việc suy nghĩ về thử nghiệm trong giai đoạn thiết kế là rất quan trọng. Nó thực sự tuyệt vời khi thực hiện công việc, nhưng cách duy nhất bạn có thể chắc chắn rằng bạn có một sản phẩm hoạt động là nếu bạn đã thử nghiệm từng mảnh một. Cách để giải quyết vấn đề này là kết hợp các bài kiểm tra Đơn vị và nhóm QA lành nghề làm việc trong quan hệ đối tác.

Bây giờ cách bạn cài đặt dendsline này vào nhóm của bạn là tùy thuộc vào bạn. TDD là một trong những chiến lược như vậy - và một chiến lược có vị trí của nó, và có rất nhiều biến thể khác. Tuy nhiên, TDD không đặc biệt phù hợp để phát triển bố cục UI.