Các trường TDD ở London và Chicago là gì?

Tôi đã được nghe về phong cách Luân Đôn so với phong cách Chicago (đôi khi được gọi là phong cách Detroit) của Phát triển hướng thử nghiệm (TDD).

Hội thảo của Nhóm người dùng lập trình cực đoan Utah:

TDD theo phong cách tương tác còn được gọi là phong cách mockist , hay phong cách London sau câu lạc bộ Extreme Thứ ba của London, nơi nó trở nên phổ biến. Nó thường tương phản với TDD theo phong cách Detroit hoặc cổ điển dựa trên nhà nước hơn.

Xưởng của Jason Gorman :

Hội thảo bao gồm cả trường TDD ở Chicago (kiểm tra hành vi và tam giác dựa trên tiểu bang) và trường London , nơi tập trung nhiều hơn vào kiểm tra tương tác, chế giễu và TDD từ đầu đến cuối, đặc biệt nhấn mạnh vào Thiết kế có trách nhiệm và Nói, Đừng hỏi cách tiếp cận với OO gần đây được phổ biến lại bởi cuốn sách Phần mềm hướng đối tượng phát triển tuyệt vời của Steve Freeman và Nat Pryce .

Bài viết TDD cổ điển hay "Trường học London"? của Jason Gorman là hữu ích, nhưng các ví dụ của anh ấy làm tôi bối rối, bởi vì anh ấy sử dụng hai ví dụ khác nhau thay vì một ví dụ với cả hai cách tiếp cận. Sự khác biệt là gì? Khi nào bạn sử dụng từng phong cách?

Giả sử bạn có lớp được gọi là "sổ cái", một phương thức gọi là "tính toán" sử dụng "Máy tính" để thực hiện các loại phép tính khác nhau tùy thuộc vào các đối số được truyền cho "phép tính", ví dụ "nhân (x, y)" hoặc "trừ ( x, y) ".

Bây giờ, giả sử bạn muốn kiểm tra những gì xảy ra khi bạn gọi ledger.calculate ("5 * 7").

Trường Luân Đôn / Tương tác sẽ giúp bạn khẳng định liệu Calculator.multiply (5,7) có được gọi hay không. Các khung mô phỏng khác nhau rất hữu ích cho việc này và nó có thể rất hữu ích nếu, chẳng hạn, bạn không có quyền sở hữu đối tượng "Máy tính" (giả sử đó là một thành phần hoặc dịch vụ bên ngoài mà bạn không thể kiểm tra trực tiếp, nhưng bạn có biết bạn phải gọi theo một cách riêng).

Trường Chicago / State sẽ giúp bạn khẳng định liệu kết quả có phải là 35. Các khung jUnit / nUnit thường hướng tới việc này.

Cả hai đều là các xét nghiệm hợp lệ và quan trọng.

Bài viết Mocks Ar't Stub , của Martin Fowler là một giới thiệu tốt về chủ đề này.

Tùy thuộc vào phong cách thiết kế bạn chọn (và các nguyên tắc thiết kế mà bạn xây dựng chương trình của mình), có ít nhất hai cách để nhìn thấy một đối tượng:

1. Là một đơn vị thực hiện tính toán dựa trên đầu vào. Kết quả của việc tính toán này, đối tượng có thể trả về một giá trị hoặc thay đổi trạng thái của nó.
2. Là một yếu tố hoạt động giao tiếp với các yếu tố khác trong hệ thống bằng cách truyền tin nhắn.

Trong trường hợp đầu tiên, bạn quan tâm đến những gì phát sinh từ quá trình xử lý hoặc ở trạng thái nào đối tượng còn lại sau quá trình xử lý đó. Đây là nơi các phương thức như assertEquals()nhập hình ảnh. Trong trường hợp này, không có vấn đề gì nhiều đối tượng khác tham gia vào quá trình xử lý, phương thức nào được gọi, v.v. Loại xác minh này được gọi là xác minh dựa trên trạng thái và là kiểu "cổ điển".

Trong trường hợp thứ hai, vì hầu hết các đối tượng thậm chí không trả về bất kỳ kết quả nào (ví dụ: voidcác phương thức trong Java), bạn quan tâm nhiều hơn đến cách các đối tượng giao tiếp với nhau và nếu chúng truyền đúng thông điệp trong các trường hợp do thử nghiệm áp đặt. Những tương tác này thường được xác minh với sự trợ giúp của các khung giả. Loại xác minh này được gọi là xác minh dựa trên hành vi hoặc dựa trên tương tác. Một trong những ý nghĩa của nó là kỹ thuật có tên là Behavior Driven Development, qua đó bạn phát triển một lớp giả định rằng các cộng tác viên của nó đã tồn tại (mặc dù chúng có thể chưa tồn tại), vì vậy bạn có thể mã hóa các giao diện của chúng.

Lưu ý rằng đây không phải là một hoặc / hoặc sự lựa chọn. Bạn có thể có một phong cách thiết kế pha trộn cả hai cách tiếp cận để tận dụng tốt nhất từng phương pháp.