Làm thế nào/những gì để thử trong BDD

Question

Tôi biết một trong những ý định của Dan North trong việc phát triển BDD là di chuyển từ vựng ra khỏi sự phức tạp của miền thử nghiệm. Tuy nhiên, trong việc thực hiện một cách tiếp cận bên ngoài, có vẻ như chúng tôi vẫn yêu cầu một số hiểu biết về hành vi nhạo báng (hoặc hành vi cứng đầu, nếu bạn thích). Bắc đề nghị trong this video rằng nếu tôi bắt đầu với các đối tượng miền ngoài cùng và làm việc theo cách của tôi vào bên trong, tôi giả lập cộng tác viên khi tôi phát hiện ra chúng và sau đó thay thế chúng bằng cách triển khai thích hợp. Vì vậy, cuối cùng, tôi kết thúc với một tập hợp các bài kiểm tra end-to-end.

Martin Fowler dường như thấy nó khác một chút trong this blog post khi ông xác định hai trại TDD: "TDD cổ điển" sử dụng các đối tượng thực nếu có thể và mô hình khi cần thiết và "mockist TDD". . Anh thấy BDD đang chăm sóc về phía sau. Tức là, khi kết thúc phát triển một tính năng, phương pháp "giả lập" sẽ để lại mocks trong các thử nghiệm thực tế (xin lỗi để sử dụng từ đó trong một cuộc thảo luận BDD).

Công bằng, cả hai vật liệu đều có tuổi, và có lẽ mọi thứ trở nên rõ ràng hơn khi BDD tiến hóa dọc theo dòng giữa được áp dụng ở cấp đơn vị và mức chấp nhận.

Nhưng câu hỏi của tôi dành cho cộng đồng về cơ bản là: khi câu chuyện của tôi hoàn thành, bao nhiêu bài kiểm tra đầu cuối của tôi thực sự là bao nhiêu? North explains rằng BDD yêu cầu trừu tượng hóa. Ví dụ: khi tôi thử nghiệm hành vi đăng nhập, thì kịch bản của tôi sẽ nêu chi tiết ý nghĩa của quá trình đăng nhập. Tuy nhiên, khi tôi thực hiện một số trường hợp khác mà yêu cầu nhưng không phải là về việc đăng nhập, tôi không muốn phải thực hiện các bước đó lặp đi lặp lại. Tôi muốn một sự trừu tượng dễ dàng chỉ đơn giản là nói "Với tôi đã đăng nhập", vì vậy tôi có thể thực hiện hành vi khác của mình. Vì vậy, dường như cách tiếp cận trừu tượng của tôi sẽ là ở chỗ tôi thử một số cộng tác viên (hoặc cung cấp một "kiểm tra kép"), và một số kịch bản có thể sử dụng chúng nhiều hơn những người khác. Ví dụ, tôi luôn luôn giả lập các tài nguyên bên ngoài, chẳng hạn như một DB hay một máy chủ thư?

Có lẽ tôi đang đặt câu hỏi sai. BDD là tất cả về giao tiếp, rút ​​ngắn chu kỳ phản hồi và khám phá những gì bạn không biết. Có thể cái gì và cái gì không giả tạo là một câu hỏi không liên quan, miễn là hành vi mà chúng ta quan tâm thực sự hoạt động. Tôi tò mò về cách tiếp cận của người khác ở đây.

Answer 1

Tôi nghĩ rằng điều quan trọng là tập trung vào B của các hành vi BDD.

Hiện tại, tôi có xu hướng bỏ qua các yếu tố giao diện người dùng và bỏ qua các lớp kiên trì - sau tất cả các ngày này, nếu có bất kỳ logic nghiệp vụ nào trong các lớp đó (chúng tôi có xu hướng chỉ ràng buộc mô hình đối tượng trực tiếp với giao diện người dùng hoặc DB các khung công tác có sẵn và được kiểm tra nghiêm ngặt).

Như một ví dụ, trong một ứng dụng WPF gần đây (đơn giản) mà tôi đang xây dựng: các bài kiểm tra chấp nhận sử dụng ViewModel làm điểm vào/ra ngoài của ứng dụng - và mọi thứ từ kho dữ liệu đã được mô phỏng. Tất cả các quy tắc và logic của ứng dụng tồn tại ở đâu đó giữa hai - và thực sự, đó là những hành vi của ứng dụng cần được xác định và thử nghiệm.

Answer 2

Điều gì để mô phỏng phụ thuộc vào kiến ​​trúc. Đối với MVVM, bạn có thể giả lập mô hình để kiểm tra mô hình xem. Đối với MVP, bạn có thể thử chế độ xem và/hoặc mô hình để kiểm tra người trình bày. Nếu bạn muốn viết các bài kiểm tra đầu cuối thay vì các bài kiểm tra đơn vị, sau đó bạn kiểm tra thông qua khung nhìn/người trình bày đến đầu kia của ứng dụng (lớp dịch vụ/cơ sở dữ liệu).

Answer 3

Với tôi, BDD cho phép tôi xác minh rằng tôi đã tạo đúng thứ. Điều đó có nghĩa là nếu tôi cắm ứng dụng của mình vào một cơ sở dữ liệu thực và sử dụng giao diện người dùng thực, nó sẽ hoạt động chính xác.Đó là kết thúc để kết thúc bạn đang nói về.

Bây giờ nếu ứng dụng của tôi cắm vào bộ nhớ trong và tôi nói chuyện với ứng dụng thông qua cấp API của nó (vì vậy ngay bên dưới giao diện người dùng). Tôi sẽ mong đợi nó hành xử chính xác theo cùng một cách.

Bây giờ đó là điều, chúng ta cần phải rõ ràng về những gì chúng tôi có ý nghĩa của hành vi, hành vi chúng ta là thú vị khi chúng tôi làm BDD là gì.

Trong trường hợp của tôi, nếu tôi bắt đầu từ một câu chuyện của người dùng và viết kịch bản, tôi quan tâm chủ yếu đến hành vi đi qua API ứng dụng, lớp dịch vụ, thực thể miền, trợ giúp, v.v ... không quan tâm nhiều đến những gì sẽ xảy ra trong giao diện người dùng cũng như cơ sở dữ liệu. Thịt thật là tất cả các mã được viết ở phía máy chủ. Đó là hành vi mà tôi quan tâm. Nếu bạn nghĩ như vậy thì có nghĩa là loại bỏ UI và DB, bởi vì chúng tôi không quan tâm đến những người này. Hành vi mong đợi của giao diện người dùng là hiển thị Dữ liệu mà ứng dụng của tôi cung cấp. Giao diện người dùng là một điều ngu ngốc. Hành vi mong đợi của DB là lưu trữ và truy xuất các thực thể mà ứng dụng của tôi cung cấp hoặc muốn. Đó cũng là một điều thực sự ngu ngốc. Bây giờ mọi thứ khác, đó là nơi tất cả sự thông minh và tôi chịu trách nhiệm.

Vì vậy, tôi sẽ vui vẻ chạy các kịch bản BDD của mình mà không cần giao diện người dùng và sử dụng phiên bản bộ nhớ của các kho lưu trữ của tôi. Phần thưởng tôi nhận được từ đó thực sự là bài kiểm tra thực sự nhanh, tập trung và có thể duy trì.

Về giao diện người dùng và DB, tôi sẽ viết các bài kiểm tra đơn vị javascript để kiểm tra hành vi trong đó, hôm nay một số giao diện người dùng có thể có nhiều logic hiển thị để ẩn và hiển thị nội dung, nhưng loại hành vi đó khác với hành vi các câu chuyện của người dùng của tôi các tình huống bdd (họ không nên nói về giao diện người dùng).

Đối với DB, tôi sẽ viết các bài kiểm tra tích hợp chỉ để kiểm tra xem các kho lưu trữ thực sự của tôi có thể đọc và ghi nội dung trên DB hay không.

Và cuối cùng tôi sẽ viết một vài kết thúc để kiểm tra kết thúc để kiểm tra mọi thứ đều OK khi được kết nối với nhau.