Có đủ để sử dụng các bài kiểm tra chấp nhận và tích hợp thay vì kiểm tra đơn vị không?

Giới thiệu ngắn về câu hỏi này. Tôi đã sử dụng TDD và gần đây là BDD trong hơn một năm nay. Tôi sử dụng các kỹ thuật như chế giễu để làm cho bài kiểm tra của mình hiệu quả hơn. Gần đây tôi đã bắt đầu một dự án cá nhân để viết một chương trình quản lý tiền nhỏ cho mình. Vì tôi không có mã kế thừa nên đây là dự án hoàn hảo để bắt đầu với TDD. Thật không may, tôi đã không trải nghiệm niềm vui của TDD rất nhiều. Nó thậm chí còn làm hỏng niềm vui của tôi đến nỗi tôi đã từ bỏ dự án.

Có vấn đề gì thế? Vâng, tôi đã sử dụng phương pháp như TDD để cho phép các bài kiểm tra / yêu cầu phát triển thiết kế chương trình. Vấn đề là hơn một nửa thời gian phát triển như đối với các bài kiểm tra viết / tái cấu trúc. Vì vậy, cuối cùng tôi không muốn thực hiện thêm bất kỳ tính năng nào vì tôi sẽ cần phải cấu trúc lại và viết cho nhiều bài kiểm tra.

Trong công việc tôi có rất nhiều mã di sản. Ở đây tôi viết ngày càng nhiều bài kiểm tra tích hợp và chấp nhận và bài kiểm tra đơn vị ít hơn. Đây dường như không phải là một cách tiếp cận tồi vì các lỗi chủ yếu được phát hiện bởi các bài kiểm tra chấp nhận và tích hợp.

Ý tưởng của tôi là, cuối cùng tôi có thể viết nhiều bài kiểm tra tích hợp và chấp nhận hơn bài kiểm tra đơn vị. Giống như tôi đã nói để phát hiện lỗi, các bài kiểm tra đơn vị không tốt hơn các bài kiểm tra tích hợp / chấp nhận. Kiểm tra đơn vị cũng tốt cho thiết kế. Vì tôi thường viết rất nhiều trong số chúng, các lớp của tôi luôn được thiết kế để có thể kiểm tra tốt. Ngoài ra, cách tiếp cận để cho các thử nghiệm / yêu cầu hướng dẫn thiết kế dẫn trong hầu hết các trường hợp để thiết kế tốt hơn. Ưu điểm cuối cùng của bài kiểm tra đơn vị là chúng nhanh hơn. Tôi đã viết đủ các bài kiểm tra tích hợp để biết, rằng chúng có thể nhanh gần như các bài kiểm tra đơn vị.

Sau khi tôi xem qua web tôi phát hiện ra rằng có những ý tưởng rất giống với tôi được đề cập ở đây và ở đó . Bạn nghĩ gì về ý tưởng này?

Biên tập

Trả lời các câu hỏi một ví dụ về thiết kế tốt, nhưng tôi cần một cấu trúc lại rất lớn cho yêu cầu tiếp theo:

Lúc đầu, có một số yêu cầu để thực hiện các lệnh nhất định. Tôi đã viết một trình phân tích cú pháp lệnh có thể mở rộng - trong đó phân tích cú pháp các lệnh từ một số loại dấu nhắc lệnh và gọi đúng lệnh trên mô hình. Kết quả được biểu diễn trong lớp mô hình khung nhìn:

Không có gì sai ở đây. Tất cả các lớp là độc lập với nhau và tôi có thể dễ dàng thêm các lệnh mới, hiển thị dữ liệu mới.

Yêu cầu tiếp theo là, mỗi lệnh nên có biểu diễn khung nhìn riêng - một số loại xem trước kết quả của lệnh. Tôi đã thiết kế lại chương trình để đạt được một thiết kế tốt hơn cho yêu cầu mới:

Điều này cũng tốt vì bây giờ mỗi lệnh có mô hình khung nhìn riêng và do đó xem trước riêng.

Vấn đề là, trình phân tích cú pháp lệnh đã được thay đổi để sử dụng phân tích cú pháp dựa trên mã thông báo của các lệnh và bị tước khỏi khả năng thực thi các lệnh của nó. Mỗi lệnh có mô hình khung nhìn riêng và mô hình khung nhìn dữ liệu chỉ biết mô hình khung nhìn lệnh hiện tại, hơn là biết dữ liệu phải được hiển thị.

Tất cả những gì tôi muốn biết vào thời điểm này là, nếu thiết kế mới không phá vỡ bất kỳ yêu cầu hiện có nào. Tôi không phải thay đổi BẤT K of bài kiểm tra chấp nhận nào của mình. Tôi đã phải cấu trúc lại hoặc xóa gần MỌI bài kiểm tra đơn vị, đó là một đống công việc khổng lồ.

Những gì tôi muốn thể hiện ở đây là một tình huống phổ biến thường xảy ra trong quá trình phát triển. Không có vấn đề gì với các thiết kế cũ hay mới, chúng chỉ thay đổi tự nhiên với các yêu cầu - tôi hiểu nó như thế nào, đây là một lợi thế của TDD, rằng thiết kế phát triển.

Phần kết luận

Cảm ơn tất cả các câu trả lời và thảo luận. Tóm lại cuộc thảo luận này tôi đã nghĩ đến một cách tiếp cận mà tôi sẽ thử nghiệm với dự án tiếp theo của mình.

• Trước hết tôi viết tất cả các bài kiểm tra trước khi thực hiện bất cứ điều gì như tôi luôn làm.
• Đối với các yêu cầu đầu tiên tôi viết một số bài kiểm tra chấp nhận kiểm tra toàn bộ chương trình. Sau đó, tôi viết một số thử nghiệm tích hợp cho các thành phần mà tôi cần thực hiện yêu cầu. Nếu có một thành phần phối hợp chặt chẽ với một thành phần khác để thực hiện yêu cầu này, tôi cũng sẽ viết một số thử nghiệm tích hợp trong đó cả hai thành phần được thử nghiệm cùng nhau. Cuối cùng nhưng không kém phần quan trọng nếu tôi phải viết một thuật toán hoặc bất kỳ lớp nào khác có độ hoán vị cao - ví dụ: trình tuần tự hóa - tôi sẽ viết các bài kiểm tra đơn vị cho các lớp cụ thể này. Tất cả các lớp khác không được kiểm tra nhưng bất kỳ bài kiểm tra đơn vị.
• Đối với lỗi quá trình có thể được đơn giản hóa. Thông thường một lỗi được gây ra bởi một hoặc hai thành phần. Trong trường hợp này tôi sẽ viết một bài kiểm tra tích hợp cho các thành phần kiểm tra lỗi. Nếu nó liên quan đến một thuật toán, tôi sẽ chỉ viết một bài kiểm tra đơn vị. Nếu không dễ dàng phát hiện thành phần xảy ra lỗi, tôi sẽ viết một bài kiểm tra chấp nhận để xác định vị trí lỗi - đây phải là một ngoại lệ.

Đó là so sánh cam và táo.

Kiểm tra tích hợp, kiểm tra chấp nhận, kiểm tra đơn vị, kiểm tra hành vi - tất cả chúng đều là kiểm tra và tất cả chúng sẽ giúp bạn cải thiện mã của mình nhưng chúng cũng khá khác nhau.

Theo quan điểm của tôi, tôi sẽ xem xét từng thử nghiệm khác nhau và hy vọng giải thích lý do tại sao bạn cần một sự pha trộn của tất cả chúng:

Kiểm tra tích hợp:

Đơn giản, hãy kiểm tra xem các phần thành phần khác nhau trong hệ thống của bạn có tích hợp chính xác không - ví dụ - có thể bạn mô phỏng yêu cầu dịch vụ web và kiểm tra xem kết quả có quay lại không. Tôi thường sẽ sử dụng dữ liệu tĩnh thực (ish) và các phụ thuộc bị chế giễu để đảm bảo rằng nó có thể được xác minh một cách nhất quán.

Các bài kiểm tra chấp nhận:

Một thử nghiệm chấp nhận nên tương quan trực tiếp đến một trường hợp sử dụng kinh doanh. Nó có thể rất lớn ("giao dịch được gửi chính xác") hoặc nhỏ ("bộ lọc thành công lọc danh sách") - không thành vấn đề; Vấn đề là nó phải được liên kết rõ ràng với một yêu cầu người dùng cụ thể. Tôi thích tập trung vào những thứ này để phát triển dựa trên thử nghiệm bởi vì điều đó có nghĩa là chúng tôi có một hướng dẫn tham khảo tốt về các thử nghiệm cho các câu chuyện của người dùng cho dev và qa để xác minh.

Bài kiểm tra đơn vị:

Đối với các đơn vị chức năng riêng biệt nhỏ có thể tạo ra hoặc không tạo nên một câu chuyện người dùng riêng lẻ - ví dụ: câu chuyện người dùng nói rằng chúng tôi truy xuất tất cả khách hàng khi chúng tôi truy cập một trang web cụ thể có thể là một thử nghiệm chấp nhận (mô phỏng đánh vào web trang và kiểm tra phản hồi) nhưng cũng có thể chứa một số kiểm tra đơn vị (xác minh rằng các quyền bảo mật đã được kiểm tra, xác minh rằng các truy vấn kết nối cơ sở dữ liệu chính xác, xác minh rằng bất kỳ mã nào giới hạn số lượng kết quả được thực thi chính xác) - đây đều là "kiểm tra đơn vị" đó không phải là một bài kiểm tra chấp nhận hoàn chỉnh.

Kiểm tra hành vi:

Xác định luồng nào sẽ là một ứng dụng trong trường hợp đầu vào cụ thể. Ví dụ: "khi kết nối không thể được thiết lập, hãy xác minh rằng hệ thống thử lại kết nối." Một lần nữa, đây không chắc là một thử nghiệm chấp nhận hoàn toàn nhưng nó vẫn cho phép bạn xác minh một cái gì đó hữu ích.

Đây là tất cả theo ý kiến ​​của tôi thông qua nhiều kinh nghiệm viết bài kiểm tra; Tôi không muốn tập trung vào các cách tiếp cận sách giáo khoa - thay vào đó, tập trung vào những gì mang lại giá trị bài kiểm tra của bạn.

TL; DR: Miễn là nó đáp ứng nhu cầu của bạn, vâng.

Tôi đã thực hiện phát triển Chấp nhận thử nghiệm (ATDD) trong nhiều năm nay. Nó có thể rất thành công. Có một vài điều cần chú ý.

• Các bài kiểm tra đơn vị thực sự giúp thực thi IOC. Nếu không có kiểm tra đơn vị, trách nhiệm thuộc về các nhà phát triển để đảm bảo rằng họ đáp ứng các yêu cầu của mã được viết tốt (trong chừng mực các thử nghiệm đơn vị điều khiển mã được viết tốt)
• Chúng có thể chậm hơn và có lỗi sai nếu bạn thực sự sử dụng các tài nguyên thường bị chế giễu.
• Bài kiểm tra không xác định chính xác vấn đề cụ thể như bài kiểm tra đơn vị sẽ làm. Bạn cần phải điều tra thêm để sửa lỗi thất bại.

Bây giờ là lợi ích

• Bảo hiểm thử nghiệm tốt hơn nhiều, bao gồm các điểm tích hợp.
• Đảm bảo toàn bộ hệ thống đáp ứng các tiêu chí chấp nhận, đó là toàn bộ quan điểm phát triển phần mềm.
• Làm cho các nhà tái cấu trúc lớn dễ dàng hơn nhiều, nhanh hơn và rẻ hơn.

Như mọi khi, bạn phải phân tích và tìm hiểu xem cách thực hành này có phù hợp với tình huống của bạn không. Không giống như nhiều người, tôi không nghĩ rằng có một câu trả lời đúng lý tưởng hóa. Nó sẽ phụ thuộc vào nhu cầu và yêu cầu của bạn.

Vâng, tôi đã sử dụng phương pháp như TDD để cho phép các bài kiểm tra / yêu cầu phát triển thiết kế chương trình. Vấn đề là hơn một nửa thời gian phát triển đối với các bài kiểm tra viết / tái cấu trúc

Kiểm tra đơn vị hoạt động tốt nhất khi giao diện chung của các thành phần mà chúng được sử dụng không thay đổi quá thường xuyên. Điều này có nghĩa là, khi các thành phần đã được thiết kế tốt (ví dụ, tuân theo các nguyên tắc RẮN).

Vì vậy, tin rằng một thiết kế tốt chỉ "tiến hóa" từ "ném" rất nhiều bài kiểm tra đơn vị vào một thành phần là sai lầm. TDD không phải là "giáo viên" cho thiết kế tốt, nó chỉ có thể giúp một chút để xác minh rằng các khía cạnh nhất định của thiết kế là tốt (đặc biệt là khả năng kiểm tra).

Khi yêu cầu của bạn thay đổi và bạn phải thay đổi phần bên trong của một thành phần và điều này sẽ phá vỡ 90% bài kiểm tra đơn vị của bạn, vì vậy bạn phải cấu trúc lại chúng rất thường xuyên, khi đó thiết kế có lẽ không tốt lắm.

Vì vậy, lời khuyên của tôi là: suy nghĩ về thiết kế của các thành phần bạn đã tạo và cách bạn có thể làm cho chúng nhiều hơn theo nguyên tắc mở / đóng. Ý tưởng của cái sau là đảm bảo chức năng của các thành phần của bạn có thể được mở rộng sau mà không thay đổi chúng (và do đó không phá vỡ API của thành phần được sử dụng trong các thử nghiệm đơn vị của bạn). Các thành phần như vậy có thể (và nên được) bao phủ bởi các bài kiểm tra đơn vị, và trải nghiệm không nên đau đớn như bạn đã mô tả.

Khi bạn không thể đưa ra một thiết kế như vậy ngay lập tức, các bài kiểm tra chấp nhận và tích hợp có thể thực sự là một khởi đầu tốt hơn.

EDIT: Đôi khi thiết kế của các thành phần của bạn có thể tốt, nhưng thiết kế của các bài kiểm tra đơn vị của bạn có thể gây ra vấn đề . Ví dụ đơn giản: Bạn muốn kiểm tra phương thức "MyMethod" của lớp X và viết

    var x= new X();
    Assert.AreEqual("expected value 1" x.MyMethod("value 1"));
    Assert.AreEqual("expected value 2" x.MyMethod("value 2"));
    // ...
    Assert.AreEqual("expected value 500" x.MyMethod("value 500"));

(giả sử các giá trị có một số loại ý nghĩa).

Giả sử thêm, trong mã sản xuất chỉ có một cuộc gọi đến X.MyMethod. Bây giờ, đối với một yêu cầu mới, phương thức "MyMethod" cần một tham số bổ sung (ví dụ, một cái gì đó giống như context), không thể bỏ qua. Nếu không có kiểm tra đơn vị, người ta sẽ phải cấu trúc lại mã cuộc gọi chỉ ở một nơi. Với các bài kiểm tra đơn vị, người ta phải cấu trúc lại 500 địa điểm.

Nhưng nguyên nhân ở đây không phải là đơn vị tự kiểm tra, đó chỉ là thực tế rằng cùng một lệnh gọi "X.MyMethod" được lặp đi lặp lại nhiều lần, không tuân thủ nghiêm ngặt nguyên tắc "Đừng lặp lại chính mình (DRY). ở đây là đưa dữ liệu thử nghiệm và các giá trị dự kiến ​​có liên quan vào danh sách và chạy các cuộc gọi đến "MyMethod" trong một vòng lặp (hoặc, nếu công cụ kiểm tra hỗ trợ cái gọi là "kiểm tra ổ dữ liệu", để sử dụng tính năng đó). số lượng vị trí cần thay đổi trong đơn vị kiểm tra khi chữ ký phương thức thay đổi thành 1 (trái ngược với 500).

Trong trường hợp thực tế của bạn, tình huống có thể phức tạp hơn, nhưng tôi hy vọng bạn hiểu ý - khi kiểm tra đơn vị của bạn sử dụng API thành phần mà bạn không biết liệu nó có thể thay đổi hay không, hãy đảm bảo bạn giảm số lượng các cuộc gọi đến API đó đến mức tối thiểu.

Vâng, tất nhiên nó được.

Xem xét điều này:

• một bài kiểm tra đơn vị là một phần nhỏ, mục tiêu của bài kiểm tra thực hiện một đoạn mã nhỏ. Bạn viết rất nhiều trong số chúng để đạt được phạm vi bảo hiểm mã tốt, để tất cả (hoặc phần lớn các bit vụng về) được kiểm tra.
• một thử nghiệm tích hợp là một thử nghiệm lớn, rộng, thực hiện một bề mặt lớn của mã của bạn. Bạn viết một vài trong số chúng để đạt được phạm vi bảo hiểm mã tốt, để tất cả (hoặc phần lớn các bit vụng về) được kiểm tra.

Xem sự khác biệt tổng thể ....

Vấn đề là một trong phạm vi bảo hiểm mã, nếu bạn có thể đạt được một bài kiểm tra đầy đủ tất cả mã của mình bằng cách sử dụng thử nghiệm tích hợp / chấp nhận, thì không có vấn đề gì. Mã của bạn đã được kiểm tra. Đó là mục tiêu.

Tôi nghĩ rằng bạn có thể cần kết hợp chúng lại, vì mọi dự án dựa trên TDD sẽ yêu cầu một số thử nghiệm tích hợp chỉ để đảm bảo rằng tất cả các đơn vị thực sự hoạt động tốt với nhau (tôi biết từ kinh nghiệm rằng một cơ sở mã hóa được kiểm tra 100% không nhất thiết phải hoạt động khi bạn đặt tất cả chúng lại với nhau!)

Vấn đề thực sự đến từ việc dễ dàng kiểm tra, gỡ lỗi các lỗi và sửa chúng. Một số người thấy các bài kiểm tra đơn vị của họ rất tốt trong việc này, chúng nhỏ và đơn giản và dễ thất bại, nhưng nhược điểm là bạn phải sắp xếp lại mã của mình cho phù hợp với các công cụ kiểm tra đơn vị và viết rất nhiều trong số chúng. Một bài kiểm tra tích hợp khó viết hơn để bao gồm nhiều mã và bạn có thể sẽ phải sử dụng các kỹ thuật như ghi nhật ký để gỡ lỗi mọi lỗi (mặc dù, tôi muốn nói rằng dù sao bạn cũng phải làm điều này, bạn không thể kiểm tra lỗi đơn vị khi tại chỗ!).

Dù bằng cách nào, bạn vẫn nhận được mã thử nghiệm, bạn chỉ cần quyết định cơ chế nào phù hợp với bạn hơn. (Tôi sẽ kết hợp một chút, thử nghiệm các thuật toán phức tạp và kiểm tra tích hợp phần còn lại).

Tôi nghĩ đó là một ý tưởng khủng khiếp.

Vì các thử nghiệm chấp nhận và thử nghiệm tích hợp chạm vào các phần rộng hơn của mã của bạn để kiểm tra một mục tiêu cụ thể, nên chúng sẽ cần tái cấu trúc nhiều hơn theo thời gian chứ không phải ít hơn. Tệ hơn nữa, vì chúng bao gồm các phần rộng của mã, chúng làm tăng thời gian bạn dành để theo dõi nguyên nhân gốc vì bạn có một khu vực rộng hơn để tìm kiếm.

Không, bạn thường nên viết thêm các bài kiểm tra đơn vị trừ khi bạn có một ứng dụng kỳ lạ có 90% UI hoặc một cái gì đó khác gây khó xử cho bài kiểm tra đơn vị. Nỗi đau mà bạn gặp phải không phải từ các bài kiểm tra đơn vị, mà là kiểm tra sự phát triển đầu tiên. Nói chung, bạn chỉ nên dành 1/3 thời gian của mình cho hầu hết các bài kiểm tra viết. Rốt cuộc, họ ở đó để phục vụ bạn chứ không phải ngược lại.

"Chiến thắng" với TDD, là một khi các bài kiểm tra đã được viết, chúng có thể được tự động hóa. Mặt trái của nó là nó có thể tiêu tốn một đoạn đáng kể của thời gian phát triển. Cho dù điều này thực sự làm chậm toàn bộ quá trình là moot. Đối số là thử nghiệm trả trước làm giảm số lượng lỗi được sửa ở cuối chu kỳ phát triển.

Đây là nơi mà BDD xuất hiện vì các hành vi có thể được bao gồm trong thử nghiệm đơn vị để quá trình này theo định nghĩa ít trừu tượng hơn và hữu hình hơn.

Rõ ràng, nếu có sẵn một lượng thời gian vô hạn, bạn sẽ thực hiện càng nhiều thử nghiệm các loại khác nhau càng tốt. Tuy nhiên, thời gian nói chung là hạn chế và thử nghiệm liên tục chỉ có hiệu quả chi phí đến một điểm.

Tất cả điều này dẫn đến kết luận rằng các thử nghiệm cung cấp giá trị cao nhất phải ở phía trước của quá trình. Bản thân điều này không tự động ủng hộ một loại thử nghiệm so với loại thử nghiệm khác - hơn nữa mỗi trường hợp phải được thực hiện dựa trên giá trị của nó.

Nếu bạn đang viết một tiện ích dòng lệnh để sử dụng cá nhân, bạn chủ yếu quan tâm đến các bài kiểm tra đơn vị. Trong khi một dịch vụ web cho biết, sẽ yêu cầu một lượng đáng kể thử nghiệm tích hợp / hành vi.

Trong khi hầu hết các loại thử nghiệm tập trung vào thứ có thể gọi là "đường đua", tức là thử nghiệm những gì được doanh nghiệp yêu cầu hiện nay, thử nghiệm đơn vị là tuyệt vời trong việc loại bỏ các lỗi tinh vi có thể xuất hiện trong các giai đoạn phát triển sau này. Vì đây là một lợi ích không thể đo lường được, nên nó thường bị bỏ qua.

Ưu điểm cuối cùng của bài kiểm tra đơn vị là chúng nhanh hơn. Tôi đã viết đủ các bài kiểm tra tích hợp để biết, rằng chúng có thể nhanh gần như các bài kiểm tra đơn vị.

Đây là điểm mấu chốt và không chỉ là "lợi thế cuối cùng". Khi dự án ngày càng lớn hơn, các bài kiểm tra chấp nhận tích hợp của bạn sẽ ngày càng chậm hơn. Và ở đây, ý tôi là chậm đến mức bạn sẽ ngừng thực thi chúng.

Tất nhiên, các bài kiểm tra đơn vị cũng trở nên chậm hơn, nhưng chúng vẫn nhanh hơn thứ tự cường độ nhanh hơn. Ví dụ, trong dự án trước đây của tôi (c ++, khoảng 600 kLOC, 4000 bài kiểm tra đơn vị và 200 bài kiểm tra tích hợp), mất khoảng một phút để thực hiện tất cả và sau đó 15 phút để thực hiện các bài kiểm tra tích hợp. Để xây dựng và thực hiện các bài kiểm tra đơn vị cho phần được thay đổi, trung bình sẽ mất ít hơn 30 giây. Khi bạn có thể làm điều đó quá nhanh, bạn sẽ muốn làm điều đó mọi lúc.

Chỉ cần làm rõ: Tôi không nói không thêm các bài kiểm tra tích hợp và chấp nhận, nhưng có vẻ như bạn đã làm TDD / BDD sai cách.

Kiểm tra đơn vị cũng tốt cho thiết kế.

Có, thiết kế với khả năng kiểm tra trong tâm trí sẽ làm cho thiết kế tốt hơn.

Vấn đề là hơn một nửa thời gian phát triển như đối với các bài kiểm tra viết / tái cấu trúc. Vì vậy, cuối cùng tôi không muốn thực hiện thêm bất kỳ tính năng nào vì tôi sẽ cần phải cấu trúc lại và viết cho nhiều bài kiểm tra.

Vâng, khi các yêu cầu thay đổi, bạn phải thay đổi mã. Tôi sẽ nói với bạn rằng bạn đã không hoàn thành công việc của mình nếu bạn không viết bài kiểm tra đơn vị. Nhưng điều này không có nghĩa là bạn nên có phạm vi bảo hiểm 100% với các bài kiểm tra đơn vị - đó không phải là mục tiêu. Một số thứ (như GUI hoặc truy cập tệp, ...) thậm chí không có nghĩa là đơn vị được kiểm tra.

Kết quả của điều này là chất lượng mã tốt hơn và một lớp thử nghiệm khác. Tôi sẽ nói rằng nó là giá trị nó.

Chúng tôi cũng đã có vài thử nghiệm chấp nhận 1000 năm và sẽ mất cả tuần để thực hiện tất cả.