Tôi đã cố gắng làm theo một quy trình làm việc TDD lỏng lẻo cho một trong các dự án nguồn mở của tôi. Đó là một API cho các lập trình viên khác sử dụng.Tôi có nên viết các bài kiểm tra trước khi chúng biên dịch không?
Như vậy, một khía cạnh quan trọng cũng như làm cho API "hoạt động" cũng đang thiết kế cách nó sẽ được tiêu thụ. Tôi đã nghe một số người nói rằng các bài kiểm tra viết trước khi họ biên dịch sẽ lãng phí thời gian và dễ bị viết lại liên tục cho đến khi API ổn định. Tôi cũng nghe nói rằng nó nên làm theo một quy trình làm việc như sau:
- Viết các bài kiểm tra mà sẽ không biên dịch
- Làm cho nó biên dịch
- Làm cho nó xanh
Tôi đã cố gắng làm theo quy trình này, nhưng tôi kết thúc với một số điều kỳ lạ. Ví dụ, trong API của tôi, tôi có hai phương pháp:
Handles(string pattern); //had this one already
Handles(IPatternMatcher pattern); //needed this one
tôi cần để có được những hình thức thứ hai của phương pháp bổ sung vào API của tôi. Vì vậy, tôi đã kết thúc với một thử nghiệm đơn giản chết như vậy:
public void Handles_SupportsIPatternMatcher()
{
var api=new MyAPI();
api.Handles(new TestPatternMatcher());
}
Mà có vẻ như một sự lãng phí sau khi nó được thực hiện.
Tôi có nên tiếp tục theo quy trình làm việc này hoặc có cách để cải thiện quy trình này không? Làm thế nào để giữ cho các bài kiểm tra viết về cơ bản chỉ kiểm tra lỗi biên dịch? Vì đó là API tiêu thụ công khai, tôi có nên lo lắng về các thử nghiệm như thế này không?
"Red-Green-Refactor" có vẻ tốt hơn nhiều so với "Will Compile-Compiles-Green": P –
Đây là một câu hỏi rất hay cho programmers.stackexchange.com –
@SimonWhitehead cũng ... lỗi trình biên dịch kỹ thuật cũng được tính là "màu đỏ" :) – Earlz