Cách nhanh nhẹn: Kiểm thử tích hợp vs Kiểm tra chức năng hoặc cả hai?

Question

Tôi làm việc trong một văn phòng làm việc Agile một thời gian. Chúng tôi sử dụng Scrum để quản lý dự án và kết hợp trong các thực hành kỹ thuật của XP. Nó hoạt động tốt và chúng tôi liên tục học các bài học và tinh chỉnh quy trình của chúng tôi.

Tôi muốn cho bạn biết về các hoạt động thông thường của chúng tôi để thử nghiệm và nhận được phản hồi về cách thức này có thể được cải thiện:

TDD: First Line of Defense Chúng tôi khá tôn giáo về kiểm tra đơn vị và tôi sẽ nói các nhà phát triển của chúng tôi cũng đủ kinh nghiệm để viết các bài kiểm tra toàn diện và luôn cô lập SUT với mocks.

Kiểm tra tích hợp Để sử dụng, kiểm tra tích hợp về cơ bản giống như kiểm tra đơn vị mà không cần sử dụng mocks. Điều này có xu hướng bắt một số vấn đề mà trượt qua các bài kiểm tra đơn vị. Những thử nghiệm này có xu hướng khó đọc vì chúng thường liên quan đến rất nhiều hoặc làm việc trong các phần before_each và after_each của khung thông số vì hệ thống phải thường xuyên đạt đến một trạng thái nhất định để các thử nghiệm có ý nghĩa.

Kiểm tra chức năng Chúng tôi thường thực hiện việc này theo cách có cấu trúc nhưng thủ công. Chúng tôi đã chơi với Selenium và Windmill, rất tuyệt, nhưng đối với chúng tôi, ít nhất là không hoàn toàn ở đó.

Tôi muốn nghe mọi người đang làm việc như thế nào. Bạn có nghĩ rằng nếu kiểm tra tích hợp hoặc kiểm tra chức năng đang được thực hiện đủ tốt thì người khác có thể bị bỏ qua không?

Answer 1

Kiểm tra đơn vị, tích hợp và chức năng, mặc dù thực hiện cùng một mã, đang tấn công nó từ các góc độ khác nhau.Đó là những quan điểm tạo nên sự khác biệt, nếu bạn bỏ một loại thử nghiệm thì một cái gì đó có thể hoạt động theo cách đó từ góc độ đó.

Ngoài ra, kiểm tra đơn vị không thực sự là về kiểm tra mã của bạn, đặc biệt nếu bạn đang thực hành TDD. Quá trình của TDD helps you design your code better, bạn chỉ nhận được tiền thưởng thêm của một bộ kiểm tra ở phần cuối của nó.

Bạn chưa đề cập đến việc bạn có máy chủ tích hợp liên tục đang chạy hay chưa. Tôi thực sự khuyên bạn nên thiết lập một (Hudson rất dễ thiết lập). Sau đó, bạn có thể có các bài kiểm tra tích hợp và chức năng của bạn chạy với mọi kiểm tra trong mã.

Answer 2

Kiểm tra đơn vị, thử nghiệm tích hợp và kiểm tra chức năng đều phục vụ các mục đích khác nhau. Bạn không nên loại bỏ một chỉ vì những người khác đang chạy ở mức độ tin cậy cao.

Answer 3

Tôi có thể nói (và đây chỉ là vấn đề ý kiến) rằng các bài kiểm tra chức năng của bạn là các bài kiểm tra đúng thực sự của bạn. Tức là những bài kiểm tra đó thực sự mô phỏng cách sử dụng thực tế của ứng dụng của bạn. Vì lý do này, không bao giờ loại bỏ chúng, không có vấn đề gì.

Có vẻ như bạn có một hệ thống tốt. Giữ tất cả nếu bạn không có gì để mất.

Answer 4

Chúng tôi đã trải nghiệm rằng một bộ thử nghiệm selenium thực sự tổng hợp những gì khách hàng mong đợi về chất lượng thực sự tốt. Vì vậy, về bản chất chúng tôi đã có cuộc thảo luận này: Nếu viết các bài kiểm tra selenium dễ dàng như việc viết các bài kiểm tra đơn vị, chúng ta nên tập trung ít hơn vào các bài kiểm tra đơn vị.

Và nếu có là lỗi ở đâu đó không có bất kỳ hậu quả nào trong ứng dụng, ai thực sự quan tâm? Nhưng luôn có những vấn đề xung quanh sự phức tạp trong cuộc sống thực; bạn có chắc chắn các bài kiểm tra chức năng của bạn đang nắm bắt các kịch bản chính xác không? Có thể có những phức tạp cơ bản do các hệ thống khác không thể nhìn thấy trực tiếp trong hành vi của ứng dụng.

Thực tế, viết kiểm tra selen (sử dụng ngôn ngữ lập trình thích hợp, không phải selen) không thực sự đơn giản và thú vị khi bạn xem qua các vấn đề ban đầu. Nhưng chúng tôi không sẵn sàng từ bỏ các bài kiểm tra đơn vị của mình ...

Answer 5

Tôi có xu hướng không phân tách các hương vị thử nghiệm khác nhau trong TDD. Đối với tôi TDD là phát triển theo hướng thử nghiệm, không phải là phát triển theo hướng thử nghiệm đơn vị. Vì vậy, thực hành TDD của tôi kết hợp các bài kiểm tra đơn vị, các bài kiểm tra tích hợp, các bài kiểm tra chức năng và chấp nhận. Điều này dẫn đến một số thành phần được bao phủ bởi một số loại thử nghiệm nhất định và các thành phần khác được các loại thử nghiệm khác che phủ theo cách rất thực dụng.

Tôi đã hỏi question về mức độ phù hợp của thực tiễn này và câu trả lời ngắn là trong thực tế tách là giữa các thử nghiệm nhanh/đơn giản chạy tự động ở mọi lần xây dựng và kiểm tra chậm/phức tạp chạy ít thường xuyên hơn.

Answer 6

Công ty của tôi thực hiện kiểm tra chức năng nhưng không thử nghiệm đơn vị hoặc tích hợp. Tôi cố gắng khuyến khích chúng tôi áp dụng chúng, tôi thấy chúng như là khuyến khích thiết kế tốt hơn và một dấu hiệu nhanh hơn cho thấy tất cả đều tốt. Bạn có cần thử nghiệm đơn vị nếu bạn làm thử nghiệm chức năng?

Answer 7

Tại khách hàng hiện tại của mình, chúng tôi không thực sự tách biệt giữa các bài kiểm tra đơn vị và kiểm tra tích hợp. Các thực thể nghiệp vụ phụ thuộc vào lớp dữ liệu cơ bản (sử dụng khung ORM trong nhà) mà thực tế chúng ta có rất ít hoặc không có các bài kiểm thử đơn vị thực sự nào. Máy chủ xây dựng được thiết lập với tích hợp liên tục (CI) trong Team Build và để tránh điều này quá nhiều với các bài kiểm tra chậm (bộ kiểm tra đầy đủ mất hơn một giờ để chạy trên máy chủ), chúng tôi đã tách các bài kiểm tra vào các bài kiểm tra "chậm" chạy hai lần một ngày và các bài kiểm tra "nhanh" được chạy như một phần của tích hợp liên tục. Bằng cách thiết lập một thuộc tính trên phương thức thử nghiệm, build-server có thể cho biết sự khác biệt giữa hai phương thức.

Nói chung, các thử nghiệm "chậm" là bất kỳ thử nghiệm nào cần thực hiện truy cập dữ liệu, sử dụng dịch vụ web hoặc tương tự. Đây sẽ được coi là kiểm tra tích hợp hoặc kiểm tra chức năng theo quy ước chung. Ví dụ: Các bài kiểm tra CRUD, kiểm tra quy tắc xác thực kinh doanh cần một tập hợp các đối tượng để làm việc, v.v.

Kiểm tra "nhanh" giống như kiểm tra đơn vị, nơi bạn có thể cô lập một cách hợp lý trạng thái và hành vi của một đối tượng các bài kiểm tra.

Tôi sẽ xem xét bất kỳ thử nghiệm nào chạy bằng phần mười giây hoặc ít hơn để trở thành "nhanh". Bất cứ điều gì khác là chậm và có lẽ không nên chạy như một phần của CI.

Tôi đồng ý rằng bạn không nên quá hung hăng về "hương vị" của thử nghiệm mà bạn sử dụng như là một phần của phát triển (thể hiện tiêu chuẩn chấp nhận như kiểm tra là ngoại lệ của khóa học). Nhà phát triển cá nhân nên sử dụng phán quyết của họ trong việc quyết định loại thử nghiệm nào phù hợp nhất với mã của họ. Nhấn mạnh vào các bài kiểm tra đơn vị cho một thực thể kinh doanh có thể không tiết lộ các lỗi mà một thử nghiệm CRUD sẽ ...

Answer 8

Tôi thực sự thích khái niệm "kiểm tra khuôn mặt" của Gojko Adzic thông qua giao diện người dùng: http://gojko.net/2007/09/25/effective-user-interface-testing/

Answer 9

Bạn nên thực hiện tất cả vì đơn vị, tích hợp và thử nghiệm chức năng đều phục vụ các mục đích khác nhau.
thuộc về tôi một điểm quan trọng là kiểm tra cách viết là rất quan trọng và TDD không phải là enought, BDD (hành vi thúc đẩy phát triển) đưa ra một cách tiếp cận tốt ...

Answer 10

Tôi so sánh kiểm tra đơn vị như đảm bảo các từ trong một đoạn văn được viết đúng chính tả. Kiểm tra chức năng giống như đảm bảo đoạn văn có ý nghĩa, và lưu chuyển tốt trong tài liệu mà nó đang sống bên trong.