Tôi đang thử nghiệm phát triển dựa trên thử nghiệm và tôi thấy rằng tôi thường gặp phải một tình huống sau:

1. Tôi viết bài kiểm tra cho một số chức năng X. Những bài kiểm tra thất bại.
2. Trong khi thử triển khai X, tôi thấy rằng tôi cần triển khai một số tính năng Y ở lớp dưới của mã. Vì thế...
3. Tôi viết bài kiểm tra cho Y. Bây giờ cả hai bài kiểm tra cho X và Y đều thất bại.

Khi tôi có 4 tính năng trong các lớp mã khác nhau được thực hiện cùng một lúc và tôi đã mất tập trung vào những gì tôi thực sự đang làm (quá nhiều thử nghiệm thất bại cùng một lúc).

Tôi nghĩ rằng tôi có thể giải quyết điều này bằng cách nỗ lực nhiều hơn vào việc lập kế hoạch cho các nhiệm vụ của mình ngay cả trước khi tôi bắt đầu viết bài kiểm tra. Nhưng trong một số trường hợp, tôi không biết rằng mình sẽ cần phải đi sâu hơn, vì ví dụ tôi không biết rõ về API của lớp thấp hơn.

Tôi nên làm gì trong những trường hợp như vậy? TDD có khuyến nghị nào không?

Điều tốt là bạn nhận ra mã của mình dưới sự kiểm tra cần hỗ trợ. Thay vì triển khai nó ngay lập tức, hãy tạo một giao diện và sử dụng các giả để đảm bảo các bài kiểm tra của bạn đang gắn thẻ đúng mã. Sau khi bạn vượt qua các bài kiểm tra đó, bạn có thể chuyển sang thực hiện mã mà nó dựa vào.

Sơ khai và giả có thể được sử dụng để mô phỏng chức năng chưa được sửa đổi / triển khai. Họ cũng có thể giúp bạn giải quyết các phụ thuộc gây ra loại 'phản ứng dây chuyền' này.

Mặt khác, có lẽ chỉ giữ một thử nghiệm (thất bại) thúc đẩy thay đổi tiếp theo là cách tiếp cận tốt nhất.

Các thử nghiệm khác nhắm vào mã dựa trên chức năng mới có thể bị vô hiệu hóa tạm thời vì chúng không thực sự phù hợp vào thời điểm này. trong trường hợp của bạn, hãy vô hiệu hóa các kiểm tra cho X cho đến khi bạn triển khai Y, v.v.

Bằng cách đó, bạn có thể tập trung vào thay đổi tiếp theo, đó là điều bạn muốn, tôi nghĩ vậy.

Dừng lại

Có vẻ như có thể có hai vấn đề riêng biệt ở đây:

1. bạn đã quên một số câu chuyện và kịch bản thử nghiệm và không khám phá chúng cho đến khi bạn bắt đầu thực hiện một kịch bản thử nghiệm cụ thể và / hoặc

2. bạn thực sự đang thực hiện kiểm tra đơn vị chứ không phải kiểm tra tính năng TDD

Đối với # 1, dừng lại , quay lại và cập nhật các câu chuyện và kịch bản thử nghiệm, sau đó bắt đầu lại với một kịch bản khác.

Đối với # 2, hãy dừng lại và nhớ rằng bạn đang thử nghiệm các tính năng, không phải đơn vị, vì vậy hãy sử dụng giả để làm bóng trên các giao diện khác và / hoặc triển khai thêm mã để thực hiện kiểm tra mà không cần thêm các kịch bản thử nghiệm mới. Điều này giả định rằng bạn không thiếu các kịch bản thử nghiệm, nhưng thay vào đó - và điều này thực sự phổ biến - thử nghiệm đơn vị kết hợp và TDD.

Đây là một câu hỏi hay và một sự thất vọng lớn đối với tôi cũng như với TDD. Tôi cảm thấy như TDD thiếu trong kịch bản này khi bạn không có cách nào để biết các thành phần hoặc tính năng cấp thấp hơn bạn sẽ cần cho đến khi bạn bắt đầu phát triển.

Cá nhân tôi thấy rằng TDD chỉ hoạt động nếu bạn biết chính xác những gì bạn cần làm và những gì bạn cần gọi để thực hiện một tính năng. Các nhà phát triển không phải lúc nào cũng biết mọi thứ trước khi chúng tôi bắt đầu, vì vậy tôi đã thấy rằng cách tốt nhất cho bản thân để giảm thiểu chính tình huống mà bạn mô tả:

Nguyên mẫu

Khi tôi tạo các ứng dụng nguyên mẫu đơn giản để khám phá và khám phá các phương pháp và cách tiếp cận với một vấn đề kỹ thuật thì tôi phát hiện ra rất nhiều công việc chân và đưa nghiên cứu đó ra khỏi đường trước khi tôi bắt đầu. Thiết kế và ước tính cũng trở nên dễ dàng hơn rất nhiều.

Nếu nguyên mẫu phải liên quan đến mức nó trở thành ứng dụng thì tôi khuyên bạn không nên làm điều lười biếng tuy nhiên và xây dựng các bài kiểm tra đơn vị cho nguyên mẫu của bạn sau khi thực tế.

Bạn nên biết thêm về API cấp thấp hơn tại thời điểm đó và có thể giả định thành công API cấp thấp hơn trong các thành phần cấp cao hơn của bạn.

Nó phụ thuộc vào loại bài kiểm tra viết của bạn trong khi làm TDD.

Mô hình cổ điển là viết các bài kiểm tra đơn vị và sử dụng các giả hoặc sơ khai để tách bài kiểm tra khỏi các "đơn vị" mã khác.

Có nhiều mô hình thay thế khác như ATDD trong đó kiểm tra một ngăn xếp đầy đủ hoặc kiểm tra ngăn xếp gần như đầy đủ. Trong trường hợp cụ thể này, các bài kiểm tra viết của bạn khẳng định hành vi chương trình yêu cầu không phải là một đơn vị mã, do đó bạn sẽ không viết các bài kiểm tra khác. Bạn sẽ nhận được việc thực hiện roundtrip để đáp ứng bài kiểm tra. Sau đó, bạn thêm các thử nghiệm khác cho các tính năng / hành vi khác.