Làm cách nào để phân tích tính năng "toàn bộ ngăn xếp" thành các thử nghiệm chấp nhận, tích hợp và đơn vị?

Question

Tôi là người mới đến Hành vi Thúc đẩy Phát triển và tôi đang cố gắng tìm hiểu nó. Tôi đang sử dụng MSpec & Watin cho các bài kiểm tra chấp nhận và MSpec cho bài kiểm tra đơn vị với ASP.Net MVC 4. Tôi có một kịch bản đơn giản về đăng ký người dùng.

Khi người dùng nhập username, password, email, vv và nhấp chuột vào nút đăng ký
Cần xác nhận địa chỉ email
Nó nên kiểm tra xem tên người dùng đã không tồn tại
Nó nên đăng ký người dùng
Nó nên gửi một email chào mừng
Nó phải chuyển hướng đến trang chủ

có những điều mà tôi muốn thử nghiệm mà không thể được kiểm tra bằng Wa tin như gửi email, kiểm tra xem người dùng có tồn tại hay không vv. Đây sẽ là một phần của kiểm tra bộ điều khiển. Điều này có nghĩa là thử nghiệm chấp nhận của tôi sẽ chỉ là khi người dùng đăng ký anh ta nên được chuyển hướng đến trang chủ? Làm thế nào để tôi phá vỡ toàn bộ quá trình này thành các bài kiểm tra?

Nếu các kiểm tra này được thực hiện trong các thử nghiệm khác nhau và mức độ khác nhau thì làm cách nào để nhận báo cáo tóm tắt có sẵn với MSpec mà tôi đã triển khai tất cả các tính năng? Tôi là một chút nhầm lẫn như thế nào mọi người phá vỡ những nhiệm vụ và sau đó làm thế nào họ nhận được báo cáo tập thể, vv

Answer 1

kiểm tra đơn vị của bạn sẽ bao gồm một cái gì đó như:

• Kiểm tra rằng mã đăng ký một người dùng ném một ngoại lệ nếu tên người dùng không được cung cấp.
• Kiểm tra xem mã xác thực mật khẩu có hoạt động hay không.

Về cơ bản lấy các đơn vị nhỏ của mã và kiểm tra chúng.

Đối với các bài kiểm tra chấp nhận, bạn sẽ chuyển sang cấp độ tiếp theo và tích hợp các tính năng này để đảm bảo chúng hoạt động. Vì vậy, bạn có thể có một bài kiểm tra chấp nhận kiểm tra toàn bộ tính năng đăng ký:

Given I am a new user 
When I complete the register user form 
Then I will be redirected to the home page 

Given I am a new user 
When I complete the register user form 
And I have not entered a valid password 
Then I will be shown an error message 

Hoặc điều gì đó trong khu vực đó.

Cá nhân tôi không phải là một fan hâm mộ lớn viết bài kiểm tra giao diện người dùng, vì giao diện người dùng có thể thay đổi thường xuyên (nghĩa là bạn phải sửa các bài kiểm tra bị hỏng bởi những thay đổi đó); cộng với tôi cảm thấy như tôi đã nhân đôi nỗ lực bằng cách viết các bài kiểm tra đơn vị theo sau bởi các bài kiểm tra chấp nhận.

Tuy nhiên, ATDD có thể mang lại lợi ích cho bạn khi nói đến khách hàng của bạn, vì bạn có thể liên lạc với họ về cách bạn đã thử nghiệm ứng dụng. Nó dễ dàng hơn nhiều để hiển thị cho họ một bài kiểm tra BDD (được viết bằng văn bản) thay vì sau đó public void ValidatePassword_PasswordNotValid_ExpectFalse.

Đây là một trong những tình huống mà bạn cần phải thử ATDD để biết liệu bạn có được hưởng lợi từ nó hay không.

Answer 2

Bắt đầu lần đầu với các thử nghiệm chấp nhận để thúc đẩy sự phát triển của bạn (Bên ngoài trong). Bạn sẽ cần phải viết các tình huống sau:

tài cố gắng đăng ký với một email không hợp lệ

Đây là một trong là khá dễ dàng

tài cố gắng đăng ký với tên đăng nhập đã tồn tại

Đối với ứng dụng này, bạn cần có khả năng cắm ứng dụng của mình trên trong kho lưu trữ bộ nhớ (Tôi khuyên bạn nên sử dụng IoC Container để dễ dàng định cấu hình ứng dụng của bạn). Bằng cách đó, trước tiên bạn sẽ sử dụng ứng dụng của mình để đăng ký người dùng 'Bob' và xem điều gì sẽ xảy ra khi bạn cố đăng ký lại bằng thông tin đăng nhập đó. Vì vậy, về cơ bản, giải pháp là sử dụng Mẫu Kho lưu trữ và có triển khai bộ nhớ thay vì triển khai DB thực của bạn. Tôi giả định ở đây rằng DB của bạn không chứa bất kỳ logic nghiệp vụ nào, nếu không sẽ an toàn hơn khi sử dụng DB thực để bạn có thể thực hiện các quy tắc nghiệp vụ trong DB. Điều đó khá phổ biến trong các hệ thống cũ. Lợi thế của kho lưu trữ trong bộ nhớ là các thử nghiệm của bạn sẽ chạy nhanh hơn và bạn sẽ không cần viết mã rách phức tạp. Với DB thực, bạn sẽ cần phải đảm bảo rằng DB được làm sạch giữa mỗi bài kiểm tra để đảm bảo kiểm tra độc lập và chạy thử nghiệm với DB chậm hơn rất nhiều.

tài khoản đăng ký thành công

Đối với một này, bạn sẽ cần phải kiểm tra sự chuyển hướng đó là khá dễ dàng. Đối với phần email, thông thường, bạn sẽ cần phải cắm ứng dụng của mình vào cuống bằng cách sử dụng mẫu Bộ điều hợp. Bạn có thể triển khai thực đơn như một số trong hàng đợi bộ nhớ, theo cách đó bạn sẽ có thể xác nhận xem email đã được ứng dụng của bạn gửi đúng chưa.

Về đơn vị kiểm tra

Nếu bạn đang có kế hoạch viết thẩm tra cú pháp email trên của riêng bạn, tôi muốn đề nghị để kiểm tra đơn vị đó một phần ngày của riêng mình.

Như Augusto đã đề cập, Growing Object-Oriented Software, Guided by Tests là cuốn sách tuyệt vời để tìm hiểu ATDD và TDD.

Chiến lược chung là luôn bắt đầu với các bài kiểm tra chấp nhận mức cao để thúc đẩy sự phát triển của bạn. Mock dịch vụ bên ngoài mà bạn không thể chạy trong bộ nhớ hoặc dịch vụ mà bạn không thể cài đặt cục bộ hoặc không dễ dàng để kiểm tra. Kiểm tra đơn vị sử dụng TDD khi nó có ý nghĩa.