Bạn có đặt thử nghiệm đơn vị trong cùng một dự án hoặc dự án khác?

Bạn có đặt các bài kiểm tra đơn vị trong cùng một dự án để thuận tiện hoặc bạn đặt chúng trong một hội đồng riêng biệt?

Nếu bạn đặt chúng trong một hội đồng riêng biệt như chúng tôi, chúng tôi sẽ kết thúc với một số dự án bổ sung trong giải pháp. Thật tuyệt vời khi thử nghiệm đơn vị trong khi mã hóa nhưng làm thế nào để bạn phát hành ứng dụng mà không cần tất cả các hội đồng bổ sung này?

Theo tôi, các bài kiểm tra đơn vị nên được đặt trong một tổ hợp riêng biệt từ mã sản xuất. Đây chỉ là một vài nhược điểm của việc đặt các thử nghiệm đơn vị trong cùng một tổ hợp hoặc lắp ráp như mã sản xuất là:

1. Kiểm tra đơn vị được vận chuyển với mã sản xuất. Điều duy nhất được vận chuyển với mã sản phẩm là mã sản xuất.
2. Các hội đồng sẽ bị cồng kềnh một cách không cần thiết bằng các bài kiểm tra đơn vị.
3. Kiểm tra đơn vị có thể ảnh hưởng đến quá trình xây dựng như xây dựng tự động hoặc liên tục.

Tôi không thực sự biết bất kỳ ưu. Có một dự án bổ sung (hoặc 10) không phải là một con.

Chỉnh sửa: Thông tin thêm về Xây dựng và Vận chuyển

Tôi sẽ khuyến nghị thêm rằng bất kỳ quá trình xây dựng tự động nào sản xuất và kiểm tra đơn vị vào các vị trí khác nhau. Lý tưởng nhất là quá trình xây dựng thử nghiệm đơn vị chỉ chạy nếu mã sản xuất xây dựng và sao chép các tệp sản phẩm vào thư mục thử nghiệm đơn vị. Làm theo cách này sẽ dẫn đến việc các bit thực tế được tách ra để vận chuyển, v.v. Ngoài ra, việc chạy thử nghiệm đơn vị tự động tại thời điểm này trên tất cả các thử nghiệm trong một thư mục cụ thể là khá đơn giản.

Tóm lại, đây là ý tưởng chung cho việc xây dựng và kiểm tra hàng ngày và vận chuyển các bit và các tệp khác:

1. Xây dựng sản xuất chạy, đặt các tệp sản xuất vào một thư mục "sản xuất" cụ thể.
   1. Chỉ xây dựng dự án sản xuất.
   2. Sao chép các bit đã biên dịch và các tệp khác vào thư mục "sản xuất".
   3. Sao chép bit và các tệp khác vào thư mục ứng viên phát hành, còn gọi là thư mục phát hành Giáng sinh sẽ là "Release20081225".
2. Nếu sản xuất xây dựng thành công, xây dựng thử nghiệm đơn vị chạy.
   1. Sao chép mã sản xuất vào thư mục "tests".
   2. Xây dựng các bài kiểm tra đơn vị vào thư mục "tests".
   3. Chạy thử nghiệm đơn vị.
3. Gửi thông báo xây dựng và kết quả kiểm tra đơn vị cho các nhà phát triển.
4. Khi một ứng cử viên phát hành (như Release20081225) được chấp nhận, hãy gửi các bit này.

Dự án riêng biệt, nhưng trong cùng một giải pháp. (Tôi đã làm việc trên các sản phẩm với các giải pháp riêng biệt cho mã thử nghiệm và mã sản xuất - thật kinh khủng. Bạn luôn luôn chuyển đổi giữa hai sản phẩm.)

Những lý do cho các dự án riêng biệt như được nêu bởi những người khác. Lưu ý rằng nếu bạn đang sử dụng các thử nghiệm dựa trên dữ liệu, bạn có thể sẽ có một số lượng khá lớn nếu bạn bao gồm các thử nghiệm trong cụm sản xuất.

Nếu bạn cần quyền truy cập vào các thành viên nội bộ của mã sản xuất, hãy sử dụng InternalsVisibleTo .

Tôi không hiểu sự phản đối thường xuyên đối với việc triển khai các thử nghiệm với mã sản xuất. Tôi đã lãnh đạo một nhóm tại một microcap nhỏ (tăng từ 14 đến 130 người). Chúng tôi đã có một nửa tá ứng dụng Java và chúng tôi thấy nó TUYỆT VỜI có giá trị để triển khai các thử nghiệm vào trường để thực hiện chúng trên một cách cụ thểMáy đã thể hiện hành vi bất thường. Các sự cố ngẫu nhiên xảy ra trong lĩnh vực này và có thể đưa ra một vài nghìn bài kiểm tra đơn vị với chi phí bằng 0 là vô giá và thường được chẩn đoán là các sự cố trong vài phút ... bao gồm các sự cố cài đặt, sự cố RAM không ổn định, sự cố mạng cụ thể, sự cố mạng không ổn định, vv, tôi nghĩ rằng nó là vô cùng có giá trị để đưa các bài kiểm tra vào lĩnh vực này. Ngoài ra, các vấn đề ngẫu nhiên xuất hiện vào các thời điểm ngẫu nhiên và thật tuyệt khi có các bài kiểm tra đơn vị đang chờ đợi để được thực hiện tại một thông báo khoảnh khắc. Dung lượng ổ cứng rẻ. Giống như chúng ta cố gắng giữ dữ liệu và chức năng cùng nhau (thiết kế OO), tôi nghĩ rằng có một cái gì đó có giá trị cơ bản trong việc giữ mã và kiểm tra cùng nhau (chức năng + kiểm tra xác nhận các chức năng).

Tôi muốn đặt các thử nghiệm của mình trong cùng một dự án trong C # /. NET / Visual Studio 2008, nhưng tôi vẫn chưa điều tra đủ điều này để đạt được nó.

Một lợi ích lớn của việc giữ Foo.cs trong cùng một dự án với FooTest.cs là các nhà phát triển liên tục được nhắc nhở khi một lớp bị thiếu bài kiểm tra anh chị em! Điều này khuyến khích thực hành mã hóa dựa trên thử nghiệm tốt hơn ... lỗ hổng rõ ràng hơn.

Đặt các bài kiểm tra Đơn vị trong cùng một dự án với mã để đạt được đóng gói tốt hơn.

Bạn có thể dễ dàng kiểm tra các phương thức nội bộ, điều đó có nghĩa là bạn sẽ không công khai các phương thức nên là nội bộ.

Ngoài ra, thật tuyệt khi có các bài kiểm tra đơn vị gần với mã bạn đang viết. Khi bạn viết một phương thức, bạn có thể dễ dàng tìm thấy các bài kiểm tra đơn vị tương ứng vì nó nằm trong cùng một dự án. Khi bạn xây dựng một hội đồng bao gồm unitTests, bất kỳ lỗi nào trong unitTest sẽ cung cấp cho bạn một trình biên dịch, vì vậy bạn phải luôn cập nhật thông tin mới nhất của mình, chỉ để xây dựng. Có một số ít nhất trong một dự án riêng biệt, có thể khiến một số nhà phát triển quên xây dựng dự án không đáng tin cậy nhất và bỏ lỡ các thử nghiệm bị hỏng trong một thời gian.

Và bạn có thể xóa các bài kiểm tra đơn vị khỏi mã sản xuất, bằng cách sử dụng các thẻ biên dịch (IF #Debug).

Kiểm tra tích hợp tự động (được thực hiện i NUnit) phải nằm trong một dự án riêng vì chúng không thuộc về bất kỳ dự án nào.

Sau khi dành một chút thời gian cho các dự án TypeScript, nơi các bài kiểm tra thường được đặt trong một tệp cùng với mã mà chúng đang kiểm tra, tôi đã phát triển để thích cách tiếp cận này hơn là giữ chúng tách biệt:

• Nó nhanh hơn để điều hướng đến các tập tin thử nghiệm.
• Sẽ dễ nhớ hơn khi đổi tên các bài kiểm tra khi bạn đổi tên lớp đang kiểm tra.
• Sẽ dễ nhớ hơn khi di chuyển các bài kiểm tra khi bạn di chuyển lớp đang được kiểm tra.
• Rõ ràng ngay lập tức nếu một lớp bị thiếu các bài kiểm tra.
• Bạn không cần phải quản lý hai cấu trúc tệp trùng lặp, một cho kiểm tra và một cho mã.

Vì vậy, khi tôi bắt đầu một dự án .NET Core mới gần đây, tôi muốn xem liệu có thể bắt chước cấu trúc này trong dự án C # mà không vận chuyển các thử nghiệm hoặc tập hợp thử nghiệm với bản phát hành cuối cùng hay không.

Đặt các dòng sau trong tệp dự án dường như vẫn hoạt động tốt:

  <ItemGroup Condition="'$(Configuration)' == 'Release'">
    <Compile Remove="**\*.Tests.cs" />
  </ItemGroup>
  <ItemGroup Condition="'$(Configuration)' != 'Release'">
    <PackageReference Include="nunit" Version="3.11.0" />
    <PackageReference Include="NUnit3TestAdapter" Version="3.12.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
  </ItemGroup>

Ở trên đảm bảo rằng trong Releasecấu hình, tất cả các tệp có tên *.Tests.csđược loại trừ khỏi quá trình biên dịch và các tham chiếu gói thử nghiệm đơn vị được yêu cầu cũng bị xóa.

Nếu bạn vẫn muốn có thể kiểm tra đơn vị các lớp trong cấu hình phát hành của chúng, bạn chỉ cần tạo một cấu hình mới có nguồn gốc từ Releasecái gọi là ReleaseContainingTests.

Cập nhật: Sau khi sử dụng kỹ thuật này một thời gian, tôi cũng thấy hữu ích khi tùy chỉnh các biểu tượng của mình trong Mã VS để làm cho các thử nghiệm (và những thứ khác) nổi bật hơn một chút trong khung thám hiểm:

Để thực hiện việc này, hãy sử dụng tiện ích mở rộng Chủ đề Biểu tượng Vật liệu và thêm một số thứ như sau vào tùy chọn Mã VS của bạn JSON:

"material-icon-theme.files.associations": {
  "*.Tests.cs": "test-jsx",
  "*.Mocks.cs": "merlin",
  "*.Interface.cs": "yaml",
}

Bài kiểm tra đơn vị của tôi luôn đi trong một dự án riêng biệt. Trong thực tế, đối với mỗi dự án tôi có trong giải pháp của mình, có một dự án thử nghiệm riêng đi cùng với nó. Mã kiểm tra không phải là mã ứng dụng và không nên xen kẽ với mã đó. Một lợi thế để giữ chúng trong các dự án riêng biệt - ít nhất là sử dụng TestDriven.Net - là tôi có thể nhấp chuột phải vào dự án thử nghiệm và chạy tất cả các thử nghiệm trong dự án đó, kiểm tra toàn bộ thư viện mã ứng dụng chỉ bằng một cú nhấp chuột.

Nếu khung NUnit được sử dụng, có một lý do bổ sung để đặt các thử nghiệm trong cùng một dự án. Hãy xem xét ví dụ sau về mã sản xuất trộn với các bài kiểm tra đơn vị:

public static class Ext
{
     [TestCase(1.1, Result = 1)]
     [TestCase(0.9, Result = 1)]
     public static int ToRoundedInt(this double d)
     {
         return (int) Math.Round(d);
     }
}

Các thử nghiệm đơn vị ở đây phục vụ như tài liệu và đặc điểm kỹ thuật cho mã đang được thử nghiệm. Tôi không biết làm thế nào để đạt được hiệu quả này của việc tự viết tài liệu, với các bài kiểm tra nằm trong một dự án riêng biệt. Người sử dụng hàm sẽ phải tìm kiếm các bài kiểm tra để xem các trường hợp kiểm thử đó, điều này khó xảy ra.

Cập nhật : Tôi biết rằng việc sử dụng TestCasethuộc tính như vậy không phải là các nhà phát triển của NUnit có ý định, nhưng tại sao không?

Tôi dao động giữa cùng một dự án và các dự án khác nhau.

Nếu bạn phát hành thư viện phát hành mã kiểm tra với mã sản xuất là một vấn đề, nếu không tôi thấy nó thường không (mặc dù có một rào cản tâm lý mạnh mẽ trước khi bạn thử).

Khi đặt các thử nghiệm trong cùng một dự án, tôi thấy việc chuyển đổi giữa các thử nghiệm và mã mà chúng thử nghiệm dễ dàng hơn và dễ dàng hơn để cấu trúc lại / di chuyển chúng xung quanh.

Tôi đặt chúng trong các dự án riêng biệt. Tên của các gương lắp ráp mà không gian tên, như là một quy tắc chung cho chúng ta. Vì vậy, nếu có một dự án có tên là Company. Productt.Feature.sln, thì nó có một đầu ra (tên lắp ráp) của Company. Productt.Feature.dll. Dự án thử nghiệm là Company. Productt.Feature.Tests.sln, mang lại Công ty. Productt.Feature.Tests.dll.

Tốt nhất bạn nên giữ chúng trong một giải pháp duy nhất và kiểm soát đầu ra thông qua Trình quản lý cấu hình. Chúng tôi có một cấu hình được đặt tên cho từng nhánh chính (Phát triển, Tích hợp, Sản xuất) thay vì sử dụng Gỡ lỗi và Phát hành mặc định. Khi bạn đã thiết lập cấu hình, bạn có thể bao gồm hoặc loại trừ chúng bằng cách nhấp vào hộp kiểm "Xây dựng" trong Trình quản lý cấu hình. (Để có Trình quản lý cấu hình, nhấp chuột phải vào giải pháp và đi đến Trình quản lý cấu hình.) Lưu ý rằng đôi khi tôi thấy CM trong Visual Studio bị lỗi. Một vài lần, tôi đã phải đi vào các tệp dự án và / hoặc giải pháp để dọn sạch các mục tiêu mà nó tạo ra.

Ngoài ra, nếu bạn đang sử dụng Team Build (và tôi chắc chắn rằng các công cụ xây dựng .NET khác đều giống nhau) thì bạn có thể liên kết bản dựng với cấu hình được đặt tên. Điều này có nghĩa là nếu bạn không xây dựng các bài kiểm tra đơn vị cho bản dựng "Sản xuất" của mình, ví dụ, dự án xây dựng cũng có thể nhận biết được cài đặt này và không xây dựng chúng vì chúng được đánh dấu như vậy.

Ngoài ra, chúng tôi đã từng làm XCopy rơi ra khỏi máy dựng. Kịch bản sẽ bỏ qua việc sao chép bất cứ thứ gì có tên * .Tests.Dll khỏi được triển khai. Nó đơn giản, nhưng làm việc.

Tôi sẽ nói giữ chúng tách biệt.

Trên hết các lý do khác được đề cập, có mã và các bài kiểm tra cùng nhau kiểm tra số lượng phạm vi kiểm tra. Khi bạn báo cáo về phạm vi kiểm tra đơn vị - phạm vi bảo hiểm được báo cáo cao hơn vì các kiểm tra được bảo hiểm khi bạn chạy thử nghiệm đơn vị. Khi bạn báo cáo về phạm vi kiểm tra tích hợp, phạm vi bảo hiểm được báo cáo thấp hơn vì các thử nghiệm tích hợp sẽ không chạy thử nghiệm đơn vị.

Tôi thực sự được truyền cảm hứng bởi khung thử nghiệm đơn vị của thư viện Flood NN của Robert Lopez. Nó sử dụng một dự án khác nhau cho mỗi lớp đơn vị được thử nghiệm và có một giải pháp nắm giữ tất cả các dự án này, cũng như một dự án chính biên dịch và chạy tất cả các thử nghiệm.

Điều gọn gàng cũng là cách bố trí của dự án. Các tệp nguồn nằm trong một thư mục, nhưng sau đó thư mục cho dự án VS ở bên dưới. Điều này cho phép bạn tạo các thư mục con khác nhau cho các trình biên dịch khác nhau. Tất cả các dự án VS được vận chuyển với mã, vì vậy mọi người có thể chạy bất kỳ hoặc tất cả các bài kiểm tra đơn vị rất dễ dàng.

Tôi biết đây là một câu hỏi rất cũ, nhưng tôi muốn thêm kinh nghiệm của mình vào đó, gần đây tôi đã thay đổi thói quen thử nghiệm đơn vị từ các dự án riêng biệt sang cùng một dự án.

Tại sao?

Đầu tiên tôi rất có xu hướng giữ cấu trúc thư mục dự án chính giống với dự án thử nghiệm. Vì vậy, nếu tôi có một tệp bên dưới Providers > DataProvider > SqlDataProvider.csthì tôi đang tạo cấu trúc tương tự trong các dự án thử nghiệm đơn vị của mình nhưProviders > DataProvider > SqlDataProvider.Tests.cs

Nhưng sau khi dự án ngày càng lớn hơn, một khi bạn di chuyển các tệp từ thư mục này sang thư mục khác hoặc từ dự án này sang dự án khác, thì việc đồng bộ hóa chúng với các dự án thử nghiệm đơn vị sẽ rất khó khăn.

Thứ hai, không phải lúc nào cũng dễ dàng điều hướng từ lớp để được kiểm tra đến lớp kiểm tra đơn vị. Điều này thậm chí còn khó hơn đối với JavaScript và Python.

Gần đây, tôi bắt đầu thực hành rằng, mỗi tệp tôi tạo (ví dụ SqlDataProvider.cs) tôi đang tạo một tệp khác có hậu tố Test, nhưSqlDataProvider.Tests.cs

Lúc đầu, có vẻ như nó sẽ làm đầy các tệp và tài liệu tham khảo thư viện, nhưng về lâu dài, bạn sẽ loại bỏ hội chứng di chuyển ngay từ cái nhìn đầu tiên, và bạn cũng chắc chắn rằng, mỗi tệp là những ứng cử viên được kiểm tra sẽ có một tệp cặp có .Testshậu tố. Nó cho phép bạn dễ dàng nhảy vào tập tin thử nghiệm (vì nó nằm cạnh nhau) thay vì xem qua dự án riêng biệt.

Bạn thậm chí có thể viết các quy tắc kinh doanh để quét qua dự án và xác định lớp không có tệp .Tests và báo cáo chúng cho chủ sở hữu. Ngoài ra, bạn có thể nói với người chạy thử nghiệm của bạn dễ dàng đến .Testscác lớp mục tiêu .

Đặc biệt đối với Js và Python, bạn sẽ không cần nhập tài liệu tham khảo của mình từ các đường dẫn khác nhau, bạn chỉ cần sử dụng cùng một đường dẫn của tệp mục tiêu đang được thử nghiệm.

Tôi đang sử dụng thực hành này trong một thời gian và tôi nghĩ rằng đó là sự đánh đổi rất hợp lý giữa quy mô dự án so với khả năng duy trì và đường cong học tập cho những người mới tham gia dự án.

Như những người khác đã trả lời - đặt thử nghiệm trong các dự án riêng biệt

Một điều chưa được đề cập là thực tế là bạn thực sự không thể chạy nunit3-console.exevới bất cứ thứ gì ngoại trừ .dllcác tệp.

Nếu bạn dự định chạy thử nghiệm thông qua TeamCity, điều này sẽ gây ra vấn đề.

Giả sử bạn có một dự án ứng dụng giao diện điều khiển. Khi bạn biên dịch, nó trả về một tệp thực thi .exevào binthư mục.

Từ nunit3-console.exebạn sẽ không thể chạy bất kỳ thử nghiệm nào được xác định trong ứng dụng bảng điều khiển đó.

Nói cách khác, một ứng dụng giao diện điều khiển trả về một exetệp và một thư viện lớp trả về dllcác tệp.

Tôi chỉ có một chút bởi điều này ngày hôm nay và nó hút :(

Tôi gần đây đã được triển khai trong docker. Tôi không thấy giá trị khi có một dự án riêng khi Dockerfile có thể dễ dàng sao chép thư mục / src và rời khỏi thư mục / test. Nhưng tôi chưa quen với dotnet và có thể đang thiếu thứ gì đó.

Các dự án riêng biệt, mặc dù tôi tranh luận với bản thân liệu họ có nên chia sẻ cùng một svn không. Hiện tại, tôi đang cung cấp cho họ các kho svn riêng biệt, một kho được gọi là

"MyProject" - cho chính dự án

và một người được gọi là

"MyProjectTests" - cho các thử nghiệm liên quan đến MyProject.

Điều này khá sạch sẽ và có lợi thế là cam kết với dự án và cam kết các thử nghiệm khá riêng biệt. Điều đó cũng có nghĩa là bạn có thể bàn giao svn của dự án nếu cần mà không phải phát hành các thử nghiệm của mình. Điều đó cũng có nghĩa là bạn có thể có các thư mục nhánh / thân / thẻ cho các thử nghiệm và cho dự án của bạn.

Nhưng tôi ngày càng có xu hướng có một cái gì đó như sau, trong một kho svn duy nhất, cho mỗi dự án.

Dự án của tôi
| \ Thân cây
| | \ Mã
| \ Thử nghiệm
| \ Thẻ
| | \ 0,1
| | | \ Mã
| | \ Thử nghiệm
| \ 0,2
| | \ Mã
| \ Thử nghiệm
Chi nhánh
  \ MyFork
   | \ Mã
    \Kiểm tra

Tôi muốn biết người khác nghĩ gì về giải pháp này.