Các thử nghiệm đầu cuối so với thử nghiệm đơn vị, các thử nghiệm có nên được tách rời?

Tại công ty của chúng tôi, chúng tôi thường đảm bảo rằng chúng tôi viết bài kiểm tra từ đầu đến cuối cho các trang web / ứng dụng web của chúng tôi. Điều đó có nghĩa là chúng tôi truy cập một URL, điền vào một biểu mẫu, gửi biểu mẫu đến một URL khác và kiểm tra kết quả của trang. Chúng tôi làm điều này để kiểm tra xác thực mẫu, kiểm tra các mẫu HTML có các biến ngữ cảnh chính xác, v.v.

Chúng tôi cũng sử dụng nó để gián tiếp kiểm tra logic cơ bản.

Tôi đã được một đồng nghiệp nói rằng lý do cho việc này là chúng tôi có thể tách ra và thay đổi việc thực hiện cơ bản tại bất kỳ thời điểm nào miễn là các bài kiểm tra từ đầu đến cuối vượt qua.

Tôi đang tự hỏi liệu loại tách rời này có ý nghĩa hay đó chỉ là một cách để tránh viết thử nghiệm cho các đơn vị mã nhỏ hơn?

Kiểm tra đầu cuối cũng là cần thiết. Làm thế nào khác bạn có thể biết bạn nối tất cả các đơn vị với nhau một cách chính xác? Với mã rất đơn giản, có thể kiểm tra tất cả các đường dẫn thông qua mã chỉ bằng các thử nghiệm đầu cuối, nhưng khi bạn nhận được nhiều lớp hơn, việc làm như vậy sẽ tốn kém hơn rất nhiều.

Ví dụ: giả sử bạn có ba lớp, mỗi lớp có năm đường dẫn có thể. Để kiểm tra tất cả các đường dẫn trong toàn bộ ứng dụng sẽ yêu cầu 5 ³ thử nghiệm đầu cuối, nhưng bạn có thể kiểm tra tất cả các đường dẫn qua mỗi đơn vị chỉ với 5 · 3 thử nghiệm đơn vị. Nếu bạn chỉ thực hiện kiểm tra đầu cuối, rất nhiều đường dẫn cuối cùng bị bỏ qua, chủ yếu là trong xử lý lỗi và điều kiện biên.

Có, các bài kiểm tra đầu cuối (hoặc kiểm tra tích hợp) có rất nhiều ý nghĩa, nhưng các bài kiểm tra đơn vị cũng vậy. Lý tưởng nhất là bạn có cả hai, vì cả hai thường bắt được các loại lỗi khác nhau. Vì vậy, có các bài kiểm tra đầu cuối không bao giờ là lý do cho việc không có bài kiểm tra đơn vị.

Sau một vài năm mã hóa và làm việc trên các dự án, tôi sẽ đưa ra câu trả lời cho câu hỏi của riêng mình.

Có, bạn nên viết bài kiểm tra đơn vị. Các bài kiểm tra từ đầu đến cuối khó viết và dễ vỡ hơn, đặc biệt nếu chúng dựa vào các thành phần UI.

Nếu bạn đang sử dụng một khung như Django hoặc Rails (hoặc các lớp tùy chỉnh của riêng bạn), bạn nên có một lớp biểu mẫu sẽ xử lý xác thực biểu mẫu. Bạn cũng sẽ có các lớp xem hiển thị các mẫu được hiển thị và biểu mẫu và xử lý các yêu cầu GET và POST.

Trong một kết thúc để kiểm tra, bạn sẽ:

1. lấy url
2. điền vào mẫu với dữ liệu hợp lệ
3. gửi mẫu vào url
4. kiểm tra để đảm bảo cơ sở dữ liệu đã được cập nhật hoặc một số hành động đã được thực hiện do kết quả của biểu mẫu hợp lệ

Bạn đang kiểm tra rất nhiều mã và phạm vi bảo hiểm của bạn sẽ khá tốt nhưng bạn chỉ kiểm tra đường dẫn hạnh phúc khi mọi thứ đều ổn. Làm thế nào để bạn đảm bảo rằng biểu mẫu có xác nhận đúng trong đó? Điều gì nếu hình thức đó được sử dụng trên nhiều trang? Bạn có viết một kết thúc khác để kết thúc bài kiểm tra?

Hãy thử lại lần nữa với các bài kiểm tra đơn vị:

1. kiểm tra xem phương thức GET
2. kiểm tra phương thức POST với dạng giả / giả
3. kiểm tra biểu mẫu với dữ liệu hợp lệ
4. kiểm tra biểu mẫu với dữ liệu không hợp lệ
5. kiểm tra tác dụng phụ của mẫu

Bằng cách sử dụng các bài kiểm tra đơn vị, bạn đang kiểm tra các đoạn mã nhỏ hơn và các bài kiểm tra cụ thể và dễ viết hơn. Khi bạn kết hợp điều này với TDD (Phát triển dựa trên thử nghiệm), bạn sẽ có được mã chất lượng cao hơn.

Không nên bỏ qua các bài kiểm tra đơn vị dễ dàng vì khi bạn tham gia một dự án không có kiểm tra tự động, bạn phải bắt đầu ở đâu đó. Bắt đầu với các bài kiểm tra đơn vị dễ dàng hơn và nhanh hơn và cho phép bạn ngay lập tức bắt đầu kiểm tra các lỗi thay vì chỉ cho đường dẫn hạnh phúc.

Trên thực tế các bài kiểm tra đầu cuối, hoặc kiểm tra tích hợp quan trọng hơn các bài kiểm tra đơn vị vì chúng đảm bảo rằng bạn có một hệ thống hoạt động đầy đủ. Các thử nghiệm đơn vị không bao gồm phần tích hợp của một hệ thống, đây là một nhiệm vụ phức tạp, đặc biệt là trong các dự án lớn.

Tuy nhiên, như đã nói, bạn cũng nên thực hiện kiểm thử đơn vị, vì việc bắt các trường hợp biên trong kiểm thử tích hợp sẽ phức tạp hơn.

Nó xác minh hành vi hệ thống, trong khi kiểm tra đơn vị xác minh hành vi đơn vị. Lợi ích và chi phí cho mỗi loại là khác nhau. Bạn có thể làm một hoặc một hoặc cả hai.

Trong công việc của mình, chúng tôi thực hiện Phát triển theo hướng chấp nhận thử nghiệm mà không cần kiểm tra đơn vị nghe có vẻ giống với những gì bạn đã mô tả. Chúng tôi bắt đầu thực hiện cả hai và theo thời gian, cuối cùng đã loại bỏ thử nghiệm đơn vị làm với chi phí vượt quá lợi ích cho chúng tôi.

Điều đó đang được nói tôi nghĩ rằng chi phí / lợi ích cho miền và vấn đề môi trường của bạn sẽ thúc đẩy các quyết định tham gia vào bất kỳ thực tiễn phát triển nào, bao gồm các thực tiễn kiểm tra tự động khác nhau. Thay vì đức tin, tôi thích tất cả các thực hành để có bằng chứng thực nghiệm trong bối cảnh sử dụng để sao lưu chúng.