Theo quy tắc của các bài kiểm tra đơn vị TDD được viết trước mã sản xuất, nhưng còn các bài kiểm tra Tích hợp thực hiện tương tác giữa các vật thể có dây (không giả)?
Chúng nên được viết trước khi kiểm tra đơn vị hoặc sau mã sản xuất chỉ để kiểm tra "hệ thống dây điện"?
Lưu ý rằng tôi không nói về Chấp nhận hoặc kiểm tra chức năng mà là kiểm tra tích hợp cấp thấp hơn.
Câu trả lời:
Sách Rspec , trong số các tài nguyên BDD khác, đề xuất một chu trình như thế này:
Về bản chất, quá trình này là:
While behaviour required
Write an integration test for a specific behaviour
While integration test failing
Write a unit test to fulfil partial behavior
While unit test failing
Write code to make unit test pass
Commit
While refactoring can be done
Refactor
While unit test failing
Write code to make unit test pass
Commit
Push
Tuyên bố miễn trừ trách nhiệm: Không có nghi ngờ gì trong đầu tôi rằng điều này dẫn đến mã và sản phẩm tốt nhất, nhưng nó có thể tốn thời gian. Có tất cả các loại khó khăn xung quanh dữ liệu và tính xác định, khi nói rằng các bài kiểm tra tích hợp phải luôn vượt qua. Nó không thích hợp trong mọi hoàn cảnh; đôi khi bạn chỉ cần lấy đồ ra khỏi cửa.
Điều đó nói rằng, có một quá trình lý tưởng trong tâm trí là tuyệt vời. Nó cho bạn một điểm để thỏa hiệp.
Dự án thực tế cho tôi thấy rằng không thể viết các bài kiểm tra đơn vị và sau đó tích hợp và thậm chí ngược lại là sai :-) Vì vậy, tôi thường viết các bài kiểm tra đơn vị cùng với các bài kiểm tra tích hợp.
Tại sao? Hãy để tôi viết làm thế nào tôi thấy cả hai loại thử nghiệm:
Kiểm tra đơn vị - Ngoài Wikipedia và tất cả các thông tin đều biết, kiểm tra đơn vị giúp bạn thu hẹp thiết kế , cải thiện mô hình, quan hệ của bạn. Luồng rất đơn giản: một khi bạn bắt đầu nhập dự án mới / thành phần mới, phần lớn thời gian bạn đang thực hiện một số loại PoC . Khi bạn hoàn thành, bạn luôn có các phương thức dài, các lớp dài, các phương thức và các lớp không kết hợp, v.v.
Kiểm thử đơn vị giúp bạn loại bỏ các vấn đề này vì khi bạn thực hiện kiểm tra đơn vị thực sự bằng cách sử dụng các giả định (phụ thuộc w / o vào thành phần khác) được mô tả ở trên là không thể kiểm tra được. Dấu hiệu cơ bản của mã không thể kiểm chứng là một phần lớn các thử nghiệm vì bạn buộc phải chế giễu nhiều phụ thuộc (hoặc tình huống)
Kiểm tra tích hợp - kiểm tra chính xác và hoạt động nói với bạn rằng thành phần mới (hoặc thành phần) của bạn hoạt động cùng nhau hoặc với các thành phần khác - đây là định nghĩa thông thường. Tôi đã thấy rằng các thử nghiệm tích hợp chủ yếu giúp bạn xác định luồng cách sử dụng thành phần của bạn từ phía người tiêu dùng .
Điều này thực sự quan trọng vì đôi khi nó nói với bạn rằng API của bạn không có ý nghĩa từ bên ngoài.
Vâng, điều gì xảy ra khi tôi viết bài kiểm tra đơn vị và kiểm tra tích hợp sau này?
Tôi đã nhận được các lớp đẹp, thiết kế rõ ràng, trình xây dựng tốt, các phương thức ngắn gọn và mạch lạc, sẵn sàng IoC, v.v. , kỳ dị. Anh chỉ bối rối. Vì vậy, tôi đã sửa chữa API theo quan điểm của anh ấy nhưng nó cũng yêu cầu viết lại nhiều bài kiểm tra vì tôi bị buộc phải thay đổi phương thức và đôi khi cả cách sử dụng API.
Vâng, điều gì xảy ra khi tôi viết bài kiểm tra tích hợp và bài kiểm tra đơn vị sau này?
Tôi có lưu lượng chính xác, khả năng sử dụng tốt. Những gì tôi cũng có là các lớp lớn, mã không mạch lạc, không đăng nhập, phương thức dài. Mã Spaghetti
Lời khuyên của tôi là gì?
Tôi đã học được dòng chảy sau đây:
Lưu ý rằng tôi đã trình bày nhỏ về thử nghiệm đơn vị / tích hợp, xem slide # 21 nơi mô tả bộ xương.
Kiểm thử đơn vị được sử dụng để kiểm tra bit phần mềm có thể kiểm tra nhỏ nhất có thể có trong một ứng dụng và để kiểm tra chức năng của nó. Mỗi đơn vị được kiểm tra riêng trước khi hợp nhất chúng thành các phần hoặc các thành phần lớn hơn của ứng dụng.
Đó là nơi các Kiểm thử Tích hợp xuất hiện:
Họ kiểm tra các bộ phận mới được tạo này bao gồm các đơn vị được kiểm tra trước đó trong khi lắp các bộ phận này lại với nhau. Trường hợp tốt nhất sẽ là viết các bài kiểm tra tại thời điểm này trong khi viết ứng dụng.
Tôi có xu hướng xem các bài kiểm tra tích hợp rất giống với bài kiểm tra đơn vị. Trong đó tôi đang coi một tập hợp con của mã là một hộp đen. Vì vậy, kiểm tra tích hợp chỉ là một hộp lớn hơn.
Tôi thích viết chúng trước khi mã sản xuất. Điều này có lợi thế là giúp tôi nhớ những phần tôi chưa nối dây hoặc tôi đã thay đổi một chi tiết trong tương tác đối tượng một chút.
Ngoài các bài kiểm tra chấp nhận, tôi có xu hướng chỉ viết các bài kiểm tra tích hợp ở ranh giới của một ứng dụng, để xác minh rằng nó tích hợp tốt với các hệ thống hoặc thành phần của bên thứ ba.
Ý tưởng là tạo các đối tượng bộ chuyển đổi dịch từ cách bên thứ ba nói với những gì ứng dụng của bạn cần và kiểm tra các trình dịch này dựa trên hệ thống bên ngoài thực sự. Cho dù bạn làm bài kiểm tra đó trước hay kiểm tra lần cuối thì tôi nghĩ ít quan trọng hơn so với kiểm tra đơn vị thông thường của bạn bởi vì
Cái nhìn sâu sắc về thiết kế do TDD cung cấp không quan trọng bằng ở đây vì thiết kế được biết đến khá nhiều và thường không có gì phức tạp khủng khiếp, bạn chỉ cần ánh xạ mọi thứ từ hệ thống này sang hệ thống khác.
Tùy thuộc vào mô-đun / hệ thống mà bạn muốn giải quyết, nó có thể đòi hỏi nhiều sự khám phá, mày mò cấu hình, chuẩn bị dữ liệu mẫu, mất nhiều thời gian và không thực sự phù hợp trong một vòng phản hồi TDD ngắn.
Tuy nhiên, nếu bạn thực sự cảm thấy thoải mái hơn khi xây dựng bộ điều hợp của mình dần dần trong các bước an toàn nhỏ, tôi chắc chắn khuyên bạn nên thử nghiệm trước, điều đó không thể làm tổn thương.
Bạn có thể tìm thấy các ví dụ về phương pháp này tại đây: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (đoạn 6) http://blog.8thlight.com/eric- smith / 2011/10/27 / thats-not-mine.html
Vì vậy, tôi sẽ chấp nhận câu trả lời đầu tiên nhưng nó đã bị xóa.
Để tổng hợp nó
trong một lần lặp nhất định:
Hãy ghi nhớ kiểm tra tích hợp trong khi 1 và 2 để đảm bảo khả năng kiểm tra ở cấp độ tích hợp.
Các thử nghiệm tích hợp không nhất thiết phải được viết từ đầu đến cuối ở bước 3, chúng có thể được viết một phần giữa bước 1 và 2.
Đơn vị kiểm tra kiểm tra các khối mã riêng biệt trong dự án của bạn.
Kiểm thử tích hợp kiểm tra cách mã của bạn giao tiếp với mã khác: nói cách khác, họ kiểm tra giao diện mã của bạn.
Viết kiểm tra đơn vị khi phát triển mã phía sau một giao diện.
Viết kiểm tra tích hợp khi phát triển giao diện hoặc bất kỳ mã nào thực hiện giao diện.
Điều này có nghĩa là đôi khi bạn sẽ viết các bài kiểm tra tích hợp rất muộn trong một dự án, bởi vì phần lớn công việc nằm sau giao diện: ví dụ: trình biên dịch, một dịch vụ web cụ thể thực hiện một số lớp logic hoặc .. một cái gì đó liên quan đến rất nhiều logic bên trong.
Tuy nhiên, nếu bạn đang triển khai một bộ dịch vụ REST hoặc tái cấu trúc mô hình dữ liệu và thêm hỗ trợ cho các giao dịch XA, thì bạn sẽ bắt đầu phát triển các thử nghiệm tích hợp gần như ngay lập tức, bởi vì hầu hết công việc của bạn tập trung vào giao diện, cho dù đó là công việc API REST hoặc cách chương trình sử dụng mô hình dữ liệu.