Nếu kiểm tra đơn vị chỉ bao gồm phần mềm 'chức năng'


9

Chúng tôi đang sử dụng StructMap trong một dự án phát triển phần mềm mới. Một trong các thành viên trong nhóm đã thực hiện một bài kiểm tra đơn vị về cơ bản kiểm tra cấu hình bộ chứa StructMap. Nó làm điều này bằng cách làm như sau;

  • Đếm số lượng phiên bản của các cụm được cấu hình cho các lớp trong không gian tên ứng dụng của chúng tôi.
  • Xác định các trường hợp dự kiến ​​ở cấp lớp
  • Xác nhận rằng các trường hợp dự kiến ​​phù hợp với tổng số trường hợp tìm thấy.
  • Các xác nhận rằng các trường hợp dự kiến ​​khớp với các trường hợp được xác định trong thử nghiệm

Một ví dụ về điều này là;

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

Chúng tôi cũng có 'bài kiểm tra đơn vị' cho lớp sau;

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

Trong các thử nghiệm này, chúng tôi giả định IEn Môi trường lưu trữ, do đó sẽ không tiêm nó từ container như trong hệ thống trực tiếp.

Một đồng nghiệp đã bỏ qua kiểm tra đơn vị trên cấu hình structuremap với một nhận xét dọc theo dòng "Kiểm tra đơn vị chỉ kiểm tra cấu hình của chính nó". Đây rõ ràng là mục đích của bài kiểm tra và theo tôi là hoàn toàn hợp lệ. Tôi đã yêu cầu anh chàng bỏ qua bài kiểm tra để loại bỏ cấu hình structuremap cho IEnvironmentRepository(với bài kiểm tra vẫn bị bỏ qua) và chạy bộ kiểm tra đơn vị đầy đủ, tất cả đều vượt qua. Sau đó chúng tôi đã chạy ứng dụng và nó bị đổ vì cấu hình container hiện không hợp lệ. Theo tôi, điều này đã chứng minh giá trị của bài kiểm tra, đồng nghiệp của tôi vẫn không đồng ý. Ông chỉ đơn giản tuyên bố rằng chúng ta không nên kiểm tra cấu hình, nhưng tôi cho rằng điều này sẽ tốt trong bài kiểm tra đơn vị.

Vì vậy, một số câu hỏi;

  • Đây có phải là thử nghiệm đơn vị hợp lệ không - Chúng tôi đang kiểm tra cấu hình của bộ chứa của chúng tôi, không phải là structuremap hoạt động (nhưng tôi có thể thấy sự chồng chéo)
  • Nếu không, làm thế nào bạn có thể xác nhận cấu hình mà không cần kiểm tra nó. Làm thế nào bạn có thể ngăn ai đó vô tình xóa một dòng mã cần thiết và kiểm tra nó?
  • MyClassKiểm tra đơn vị có nên giải quyết trường hợp IEnvironmentRepositorytừ container và vượt qua điều này không?

10
9 trên 10 bất đồng về các bài kiểm tra phát sinh từ thực tế là các khung hỗ trợ kiểm tra tự động dưới mọi hình thức và mọi người muốn tìm hiểu về ngữ nghĩa của một bài kiểm tra tự động cụ thể có phải là bài kiểm tra đơn vị tốt và phù hợp hay không. Bài kiểm tra mà bạn mô tả nghe có vẻ giống như bài kiểm tra kiểm tra đơn vị không hoàn toàn có thể rất hữu ích để có và tự động hóa (và chạy khi đăng ký) - đừng gọi đó là bài kiểm tra đơn vị. Hỏi xem đồng nghiệp của bạn có ngủ ngon hơn vào ban đêm không nếu bài kiểm tra sống trong tính năng / thư mục riêng được phân tách rõ ràng.
Jeroen Mostert

2
Đó cũng là ý kiến ​​của tôi, có lẽ hữu ích, và mặc dù không hoàn toàn là một bài kiểm tra đơn vị, nhưng nó có giá trị gia tăng và điều này đã được chứng minh. Phản ứng của anh ta là các bài kiểm tra đơn vị khác sẽ chọn ra điều này, nhưng theo tôi, nếu chúng được viết dưới dạng kiểm tra đơn vị nghiêm ngặt, bạn sẽ bị chế giễu các phụ thuộc và do đó sẽ không bao giờ biết liệu cấu hình có hợp lệ cho đến khi bạn sử dụng nó không.
ChrisBint

4
Đồng nghiệp của bạn có quan điểm khi anh ta nói không kiểm tra cấu hình, vì cấu hình chính hãng thực sự có thể thay đổi theo từng triển khai không thể / không nên thử nghiệm - ai nói "đỏ" là sai và "xanh" không? Bài kiểm tra sẽ được kết hợp chặt chẽ với một thiết lập. Nhưng cấu hình được gắn với các tạo phẩm mã là một ngoại lệ, bởi vì nó không thay đổi và rõ ràng có nhiều cách để làm cho nó sai. Lý tưởng nhất là bạn có cấu hình như vậy được tạo tại thời điểm xây dựng từ siêu dữ liệu DRY, nhưng trong trường hợp này không khả thi thì một thử nghiệm như thế này sẽ tăng thêm giá trị. Tốt hơn là một lỗi triển khai có thể tránh được.
Jeroen Mostert

2
Những gì bạn mô tả không kiểm tra một đơn vị, nó kiểm tra cấu hình của một phần mềm bên thứ ba. Thật hữu ích khi có các bài kiểm tra kiểm tra những điều này, nhưng chúng là kiểm tra tích hợp, không phải kiểm tra đơn vị và việc ngắt kết nối có thể là gốc rễ của sự bất đồng.
Phoshi

3
@ChrisBint Trời ơi, tôi đã tự mình viết một loạt các bài kiểm tra container. Chúng có rất nhiều giá trị, chúng không phải là bài kiểm tra đơn vị. Điều đó tốt, các bài kiểm tra tích hợp là cực kỳ có giá trị để nắm bắt những điều mà bài kiểm tra đơn vị không thể .
Phoshi

Câu trả lời:


13

Đây là một thử nghiệm tự động hoàn toàn hợp lệ để có. Tôi gọi chúng là "kiểm tra kiến ​​trúc" khi chúng xác minh tính đúng đắn của các bộ phận cơ sở mã của bạn.

IoC container có thể phân giải và soạn thảo tất cả các cây đối tượng trong ứng dụng không? Bản đồ tự động có thể ánh xạ giữa tất cả các đối tượng đã đăng ký mà không bị lỗi không? Có phải lớp trung tâm trong Kiến trúc Onion không tham chiếu bất cứ thứ gì bên ngoài?

Các thử nghiệm này có thể giúp bạn tiết kiệm rất nhiều thời gian khi một lỗi cấu hình lẻn vào, bằng cách chỉ ra thủ phạm chính xác. Các khung công tác tốt sẽ cung cấp cho bạn các thông báo lỗi rất chính xác về những gì sai và bạn nhận được chúng ngay khi bạn chạy thử nghiệm (lý tưởng, liên tục) thay vì chôn sâu xuống dấu vết ngăn xếp thời gian chạy nếu bạn may mắn.

Cho dù chúng là các bài kiểm tra đơn vị ... có thể là không, nhưng phần lớn chúng vẫn hoạt động trong bộ nhớ và chạy khá nhanh. Sau đó, một lần nữa, tôi không biết, nó không giống như có một định nghĩa được chấp nhận phổ biến về kiểm tra đơn vị.


Trớ trêu thay, đây là cách tôi giải thích nó với đồng nghiệp của mình và ngay cả khi xác thực (xóa một trong các trường hợp chứa và chạy ứng dụng), anh ta vẫn không thấy bất kỳ giá trị nào. Tôi hiểu mọi người đều có ý kiến ​​riêng của họ, và tôi lên tiếng của tôi;) Tôi thích thuật ngữ "thử nghiệm kiến ​​trúc", tôi sẽ đánh cắp điều đó!
ChrisBint

6

Vấn đề với một bài kiểm tra như thế này kiểm tra các phần bên trong của chương trình, chứ không phải là một yêu cầu của nó. Là thử nghiệm có thể thất bại ngay cả khi chương trình hoạt động theo yêu cầu.

Trong trường hợp của bạn, bất cứ khi nào bạn thay đổi thiết lập vùng chứa, có thể bạn có một phụ thuộc mới cần tiêm, bạn sẽ phá vỡ bài kiểm tra của mình.

Ngoài ra, nếu bạn thêm yêu cầu phụ thuộc bổ sung, nhưng quên thêm nó vào vùng chứa và thay đổi thử nghiệm vùng chứa. mọi thứ sẽ qua, nhưng chương trình của bạn sẽ sụp đổ.

Một thử nghiệm tự động tốt hơn sẽ là khởi động chương trình và xem nếu nó gặp sự cố.

Bạn nên nắm bắt các loại lỗi này khi tích hợp hoặc kiểm tra giao diện người dùng ngay cả khi chúng rơi vào các bài kiểm tra đơn vị.

Phải nói rằng, sự phức tạp ngày càng tăng của thiết lập container là một nỗi đau ở mông. Có lẽ một số bài kiểm tra 'xấu' là đáng giá.


1

Đơn vị kiểm tra mã kiểm tra. Bất cứ điều gì bên ngoài này là kiểm tra tự động "khác" - hãy gọi nó là những gì bạn sẽ làm. Bạn dường như đang thử nghiệm cấu hình ở đây. Nếu cấu hình có thể thay đổi tùy thuộc vào môi trường, nó không thuộc về thử nghiệm đơn vị. Xem xét thêm một thuộc tính thử nghiệm để chỉ ra rằng thử nghiệm thuộc loại khác với các thử nghiệm khác.


Cấu hình là tĩnh, nó không được điều khiển bởi môi trường, tất cả các lớp tồn tại trong cấu hình sẽ được sử dụng trên tất cả các môi trường theo cùng một cách. Có, số lượng phiên bản có thể có trong cấu hình phải khớp với số lượng phiên bản trong cấu hình, đó một phần của thử nghiệm. Như ví dụ của tôi cho thấy, việc loại bỏ IEn Môi trường lưu trữ cho phép các bài kiểm tra đơn vị khác vượt qua. Thử nghiệm container cụ thể đã thất bại trên 2 Khẳng định; 1 - Tổng số khai báo thể hiện có thể không khớp và 2 - số lượng bản quyền cụ thể của IEn Môi trường lưu trữ sẽ không khớp.
ChrisBint

1
Tính chính xác của container được xác định bởi bộ mã hóa. Thực tế là cả mã được thử nghiệm và chính thử nghiệm phải thay đổi cho mỗi sửa đổi ngay lập tức đặt chuông báo thức. DI là một phương tiện để kết thúc và không phải là kết thúc trong chính nó. Hoàn toàn có thể viết mã theo kiểu DI mà không cần structuremap ergo, đó không phải là một thử nghiệm đơn vị thực sự theo quan điểm của tôi. Container tất nhiên cần phải được chứng minh nhưng hiệu quả của việc làm như vậy với các bài kiểm tra tự động dường như sẽ hơi khó khăn với thông tin hạn chế được cung cấp ở đây.
Robbie Dee

2
Bài kiểm tra đơn vị mất 10 phút để đánh gục. Triển khai có thể mất hơn một giờ.
ChrisBint

1
Với một phần của bài kiểm tra đơn vị xác nhận cụ thể sự tồn tại của một dòng duy nhất trong cấu hình, không chắc chắn làm thế nào mà nó không thể bị cô lập hơn. Tổng số tôi có thể đồng ý với.
ChrisBint

1
Có thể có một số dặm trong đó - một lời kêu gọi phán xét cho bạn thực sự. Nhưng chúng nên được tách ra khỏi vật lý hoặc thông qua một số thuộc tính.
Robbie Dee

0

Trách nhiệm của container tiêm phụ thuộc là dán các mô-đun khác nhau trong một ứng dụng làm việc .

Nếu bạn viết kiểm tra tự động cho ứng dụng của mình - bạn sẽ có một vài thử nghiệm "tích hợp (hoặc chấp nhận) thực hiện các thử nghiệm" từ đầu đến cuối ", sẽ kiểm tra toàn bộ đường ống của ứng dụng của bạn, rằng tất cả các mô-đun liên quan đến trường hợp thử nghiệm cụ thể được dán lại với nhau một cách chính xác .

Vì vậy, các thử nghiệm tích hợp sẽ thất bại nếu thùng chứa phụ thuộc tiêm không được cấu hình đúng. Điều này làm cho các bài kiểm tra đơn vị cho chính container trở nên vô dụng, bởi vì kiểm thử tích hợp sẽ hiển thị các lỗi có thể có trong cấu hình bộ chứa.

Bạn không cần phải bao gồm tất cả các trường hợp thử nghiệm có thể có trong các thử nghiệm tích hợp, chỉ cần một trường hợp thử nghiệm cho mỗi tính năng bao gồm toàn bộ cách từ UI đến cơ sở dữ liệu.

Nếu các trường hợp kiểm thử tích hợp không bao gồm việc khởi tạo một số phụ thuộc cụ thể - bạn chỉ cần thêm trường hợp đó.

Với các bài kiểm tra tích hợp, bạn có thể tự do thay đổi các thùng chứa mà không cần viết lại các bài kiểm tra đơn vị cho cấu hình của chúng.


0

IMO, câu trả lời là:

  1. Đây có phải là thử nghiệm đơn vị hợp lệ không - Chúng tôi đang kiểm tra cấu hình của bộ chứa của chúng tôi, không phải là structuremap hoạt động (nhưng tôi có thể thấy sự chồng chéo)

    • Đó là thử nghiệm đơn vị hợp lệ cho sơ đồ cấu trúc , không phải cho dự án của bạn, bởi vì thử nghiệm đơn nhất kiểm tra một số mã cụ thể, chế nhạo tất cả các phụ thuộc nếu cần thiết để kiểm tra logic được triển khai. Logic cấu hình được triển khai bên trong structuremap, do đó thư viện này phải được kiểm tra tốt và phải chứa các bài kiểm tra đơn vị như bài kiểm tra mà bạn đã đề cập và hơn thế nữa: nó nên chứa hàng trăm bài kiểm tra như thế này, tự động chế tạo một số cấu hình khi chạy và kiểm tra xem container hành xử như nó nên.
  2. Nếu không, làm thế nào bạn có thể xác nhận cấu hình mà không cần kiểm tra nó. Làm thế nào bạn có thể ngăn ai đó vô tình xóa một dòng mã cần thiết và kiểm tra nó?

    • Bạn có thể kiểm tra cấu hình theo cách thủ công trong môi trường cần thiết và bạn cũng có thể tạo tự động hóa cho việc này (kiểm tra tự động), kiểm tra cấu hình cụ thể mà bạn cần (không cần phải giả lập công cụ khi chạy).
  3. Thử nghiệm đơn vị MyClass có nên giải quyết trường hợp của IEnvirRep repository từ vùng chứa và chuyển cái này vào không?

    • Không, đây là một bài kiểm tra đơn vị hoàn hảo, bởi vì bạn chế giễu sự phụ thuộc và kiểm tra logic MyClass theo cách cô lập.

-1

UnitTest xác minh hành vi mong muốn của một đơn vị trong tách .

Điều này có nghĩa bất kỳ loại cấu hìnhkhông trong phạm vi của unittests .

Tuy nhiên bạn nên đã tự động kiểm tra cho các cấu hình của bạn, nhưng đây không phải là unittests ...


Bạn lấy định nghĩa của Đơn vị ở đâu?
ChrisBint

Tôi thích một trong những Roy Osherove trong The Art Of Unittesting : A Unit là bất kỳ đoạn mã (sản xuất- ) nào có cùng lý do để thay đổi. Tôi thế giới của tôi thường dao động từ một lớp duy nhất lên đến ba hoặc năm ...
Timothy Truckle

Đây là mã sản xuất đang được thử nghiệm.
ChrisBint

Chỉ muốn đánh lạc hướng các nitpickers , không hy vọng nó hoạt động theo cách khác xung quanh quá ...; o)
Timothy ròng rọc
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.