Có bao nhiêu đơn vị thử nghiệm trước khi bắt đầu mã hóa một phương pháp/lớp học?

Question

Tôi bắt đầu (cố gắng ít nhất) để viết mã bằng các nguyên tắc TDD và tôi có câu hỏi này: tôi cần viết bao nhiêu bài kiểm tra trước khi bắt đầu viết mã?

Lấy ví dụ một giả thuyết Math lớp học và phương pháp Divide(int a, int b).

a) Tôi có phải kiểm tra đầy đủ tất cả các phương thức của Math lớp (Sum, Average, ...) trước khi bắt đầu mã hóa Math?

b) Tôi có phải kiểm tra đầy đủ phương pháp Divide, khẳng định ví dụ để chia cho số không, trước khi bắt đầu mã hóa phương pháp?

c) Hoặc tôi có thể tạo một xác nhận thử nghiệm đơn giản và xác minh rằng nó không thành công, viết mã và kiểm tra xem có ổn không, gặt lại quá trình cho từng xác nhận của phương pháp?

Tôi nghĩ tùy chọn c) là chính xác, nhưng tôi không thể tìm thấy câu trả lời cho nó (tôi đã thực hiện một số tìm kiếm nhưng không thể tìm thấy câu trả lời dứt khoát).

Answer 1

Tùy chọn của bạn c đại diện hoàn toàn bằng sách TDD.

Bạn viết một bài kiểm tra không thực hiện tính năng của lớp bạn đang làm việc và sau đó viết chỉ đủ mã để vượt qua bài kiểm tra đó. Sau đó, bạn làm điều này một lần nữa, cho các bài kiểm tra tiếp theo. Bằng cách làm theo cách này, bạn sẽ thấy mỗi đoạn mã mới bạn viết rất tập trung vào một trường hợp sử dụng cụ thể/kiểm tra và cũng thấy rằng các thử nghiệm của bạn vẫn khác biệt với những gì chúng bao gồm.

Bạn muốn kết thúc làm việc theo kiểu tái cấu trúc lại màu đỏ-xanh, do đó định kỳ bạn quay lại cả mã và thử nghiệm của bạn cho những nơi bạn có thể tái cấu trúc mọi thứ thành thiết kế tốt hơn.Tất nhiên, trong thế giới thực, bạn có thể kết thúc viết nhiều bài kiểm tra màu đỏ, hoặc viết nhiều mã hơn một bài kiểm tra cụ thể, hoặc thậm chí viết mã mà không có bài kiểm tra, nhưng đang chuyển ra khỏi TDD và chỉ nên thực hiện thận trọng.

Bài viết wikipedia về điều này thực sự khá tốt. http://en.wikipedia.org/wiki/Test-driven_development

Answer 2

Vâng Bạn có lẽ có thể viết

@Test 
public void testDivide() { 
    Math math = new Math(); 
    int result = math.divide(20,2); 
    Assert.assertNotNull(result); 
} 

Vậy là xong, bây giờ khi bạn chạy thử nghiệm của bạn này sẽ thất bại, do đó bạn sửa chữa phương pháp Math.divide của bạn. và thêm các trường hợp trong bước tiếp theo

đây là một cách rất lý tưởng nhưng mọi người đều biết nó không phải lúc nào cũng theo cách này.

Answer 3

Điều đầu tiên bạn muốn làm là viết một đặc điểm kỹ thuật cho từng phương pháp bạn muốn triển khai. Trong đặc tả của bạn, bạn cần phải giải quyết nhiều trường hợp góc như bạn quan tâm và xác định hành vi mà phương thức của bạn sẽ dẫn đến khi thực hiện các trường hợp đó.

Khi đặc điểm kỹ thuật của bạn hoàn tất, bạn thiết kế các thử nghiệm cho từng phần của đặc điểm kỹ thuật của bạn đảm bảo rằng mỗi thử nghiệm không vượt qua hoặc thất bại do điều kiện ốp góc. Tại thời điểm này, bạn đã sẵn sàng để mã hóa việc triển khai và thực hiện hàm của bạn. Khi điều này hoàn tất, bạn tinh chỉnh đặc điểm kỹ thuật/kiểm tra/triển khai của mình khi cần thiết cho đến khi kết quả chính xác là những gì bạn mong muốn từ việc triển khai của mình.

Sau đó, bạn ghi lại mọi thứ (đặc biệt là lý do của bạn để xử lý các trường hợp góc).

Answer 4

Giống như những người khác đã đề cập, tùy chọn c của bạn sẽ là cách TDD thuần túy để thực hiện việc này. Ý tưởng là để xây dựng mã của bạn lên trong gia số nhỏ màu đỏ-xanh refactor. Một ví dụ đơn giản về điều này là Bowling Kata của Robert Martin.

Answer 5

Định nghĩa của "đơn vị" là not universal, đôi khi đơn vị là lớp, đôi khi nó có thể là một phương pháp. Vì vậy, không có câu trả lời phổ quát thực sự.

Trong trường hợp cụ thể này, tôi sẽ xem đơn vị là phương thức để không phải tất cả các phương pháp trước khi bắt đầu mã hóa. Thay vào đó, tôi sẽ làm mọi thứ theo từng bước, phương pháp sau các phương pháp. Điều này loại bỏ a).

Tuy nhiên, khi viết một bài kiểm tra cho một phương pháp, tôi sẽ viết một bài kiểm tra nghiêm ngặt, tôi sẽ kiểm tra và các trường hợp không qua, kiểm tra ở các giới hạn, kiểm tra các giá trị đặc biệt, vv. 'xác định một hợp đồng và hợp đồng này nên bao gồm tình huống đặc biệt. Suy nghĩ của họ từ đầu làm giúp đỡ. Và đối với tôi, quan điểm của việc có một ánh sáng màu xanh lá cây là được thực hiện vì vậy tôi muốn thử nghiệm của tôi là đầy đủ. Và tôi nghĩ rằng đây là b).

Nếu thử nghiệm của bạn không đầy đủ, thì bạn thực sự không được thực hiện với đơn vị của bạn ngay cả khi thử nghiệm được chuyển và tôi không thực sự thấy điểm. Tôi đoán rằng đây là c).

Vì vậy, lựa chọn của tôi sẽ là b).

Answer 6

Nếu bạn đang đi cho đầy đủ, bạn nên thiết kế và mã kiểm tra đơn vị của bạn trước khi phát triển và sau đó phát triển các chức năng chính cho các bài kiểm tra đơn vị tạo ra. Bạn càng hiểu rõ hơn về phạm vi và chất lượng cuối cùng càng tốt. Nếu thời gian và chức năng cho phép, tôi sẽ tạo các thử nghiệm cho mỗi phương thức/chức năng.