Ai đó có thể giải thích cách tiếp cận "Giả mạo nó cho đến khi bạn thực hiện" trong Phát triển theo hướng thử nghiệm?

Question

Tôi có vấn đề để hiểu sự tiến hóa của mã khi bạn đã sử dụng phương pháp TDD "Giả mạo cho đến khi bạn làm cho CNTT".

Ok, bạn đã giả mạo nó, giả sử bạn trả về một hằng số để kiểm tra bị hỏng có màu xanh ở đầu. Sau đó, bạn lại xác thực mã của bạn. Sau đó, bạn chạy thử nghiệm tương tự mà sẽ vượt qua rõ ràng bởi vì bạn đã giả mạo nó!

Nhưng nếu một bài kiểm tra đang trôi qua thì bạn có thể dựa vào điều đó như thế nào, đặc biệt là khi bạn biết rằng bạn đã giả mạo điều đó?

Làm cách nào để thử nghiệm giả được tái cấu trúc với việc tái cấu trúc mã thực sự của bạn để nó vẫn có thể đáng tin cậy?

Cảm ơn

Answer 1

Trước tiên, bạn tạo thử nghiệm đơn vị kiểm tra chức năng mới không tồn tại.

Bây giờ, bạn có một thử nghiệm đơn vị cho một phương pháp không tồn tại. Sau đó, bạn tạo ra phương thức mà không làm bất cứ điều gì và biên dịch thử nghiệm đơn vị của bạn, nhưng tất nhiên, thất bại.

Sau đó, bạn sẽ xây dựng phương pháp, chức năng cơ bản, v.v. cho đến khi thử nghiệm đơn vị của bạn thành công.

Đó là (loại) phát triển theo thử nghiệm.

Lý do bạn có thể tin tưởng vào điều này là bạn nên thực hiện bài kiểm tra đơn vị của mình để nó thực sự kiểm tra chức năng của bạn. Tất nhiên, nếu nó chỉ trả về một hằng số và bạn chỉ cần kiểm tra trên đó, bạn có một vấn đề. Nhưng sau đó, kiểm tra đơn vị của bạn chưa hoàn thành.

Bài kiểm tra đơn vị của bạn nên (theo lý thuyết) kiểm tra mọi dòng. Và nếu bạn đã làm điều đó OK, điều này sẽ làm việc.

Answer 2

Câu trả lời ngắn gọn là: viết thêm kiểm tra.

Nếu phương thức trả về hằng số (khi cần tính toán), chỉ cần thêm kiểm tra cho điều kiện có kết quả khác. Vì vậy, chúng ta hãy nói rằng bạn có những điều sau đây:

@Test 
public void testLength() 
{ 
    final int result = objectUnderTest.myLength("hello"); 
    assertEquals(5, result); 
} 

và myLength được thực hiện như return 5, sau đó bạn viết một (thêm) thử nghiệm tương tự nhưng vượt qua trong "foobar" thay vào đó và khẳng định rằng kết quả là 6.

Khi bạn đang viết các bài kiểm tra, bạn nên cố gắng hết sức chống lại việc thực hiện và cố gắng viết một cái gì đó để lộ những thiếu sót của nó. Khi bạn đang viết mã, tôi nghĩ bạn có nghĩa là rất laissez-faire và làm ít nhất là cần thiết để làm cho những thử nghiệm khó chịu màu xanh lá cây.

Answer 3

Điều này có thể đề cập đến việc thực hành sử dụng mocks/stubs/giả mạo mà hệ thống/lớp học của bạn được thử nghiệm cộng tác.

Trong trường hợp này, bạn "giả" cộng tác viên, không phải thứ bạn đang thử nghiệm, bởi vì bạn không có triển khai giao diện của cộng tác viên này.

Vì vậy, bạn giả mạo nó cho đến khi bạn "làm cho nó", có nghĩa là bạn thực hiện nó trong một lớp cụ thể.

Answer 4

Giả sử bạn cho phép viết điều đơn giản nhất có thể để vượt qua bài kiểm tra hiện tại của bạn. Thông thường, khi bạn viết một trường hợp thử nghiệm cho một tính năng mới, điều đơn giản nhất có thể là trả về một hằng số. Khi một cái gì đó đơn giản đáp ứng các bài kiểm tra của bạn, đó là bởi vì bạn không (chưa) có đủ các bài kiểm tra. Vì vậy, viết một bài kiểm tra khác, như @Andrzej Doyle nói. Bây giờ tính năng bạn đang phát triển cần một số logic cho nó. Có lẽ đây là điều đơn giản nhất có thể là viết logic cơ bản nếu có để xử lý hai trường hợp thử nghiệm của bạn. Bạn biết bạn đang giả mạo nó, vì vậy bạn biết bạn chưa hoàn thành. Khi nó trở nên đơn giản hơn để viết mã thực tế để giải quyết vấn đề của bạn hơn là mở rộng giả mạo của bạn để trang trải thêm một trường hợp thử nghiệm khác - đó là những gì bạn làm. Và bạn đã có đủ các trường hợp kiểm tra để đảm bảo rằng bạn đang viết đúng.

Answer 5

Trong TDD, tất cả các yêu cầu được thể hiện dưới dạng thử nghiệm. Nếu bạn giả mạo một cái gì đó và tất cả các bài kiểm tra vượt qua, yêu cầu của bạn được đáp ứng. Nếu điều này không mang lại cho bạn hành vi mong đợi, thì bạn đã không thể hiện tất cả các yêu cầu của bạn như là các bài kiểm tra.

Nếu bạn tiếp tục giả mạo tại thời điểm này, cuối cùng bạn sẽ nhận thấy rằng giải pháp đơn giản nhất là thực sự giải quyết vấn đề.