Làm thế nào để chúng tôi làm cho bài kiểm tra đơn vị chạy nhanh?

Chúng tôi đã đạt đến điểm trong dự án của chúng tôi, nơi chúng tôi có gần một ngàn bài kiểm tra và mọi người đã ngừng làm phiền với việc chạy chúng trước khi thực hiện kiểm tra vì mất quá nhiều thời gian. Tốt nhất là họ chạy các thử nghiệm có liên quan đến đoạn mã mà họ đã thay đổi và tệ nhất là họ chỉ cần kiểm tra nó mà không cần thử nghiệm.

Tôi tin rằng vấn đề này là do giải pháp đã tăng lên 120 dự án (chúng tôi thường thực hiện các dự án nhỏ hơn nhiều và đây chỉ là lần thứ hai chúng tôi thực hiện TDD đúng cách) và thời gian xây dựng + thử nghiệm đã tăng lên khoảng hai ba phút trên các máy ít hơn.

Làm thế nào để chúng tôi giảm thời gian chạy của các bài kiểm tra? Có kỹ thuật không? Làm giả nhiều hơn? Làm giả ít hơn? Có lẽ các bài kiểm tra tích hợp lớn hơn không nên chạy tự động khi chạy tất cả các bài kiểm tra?

Chỉnh sửa: như một phản hồi cho một số câu trả lời, chúng tôi đã sử dụng CI và máy chủ xây dựng, đây là cách tôi biết các bài kiểm tra thất bại. Vấn đề (thực sự là một triệu chứng) là chúng tôi liên tục nhận được thông báo về các bản dựng không thành công. Chạy thử nghiệm một phần là điều mà hầu hết mọi người làm nhưng không phải tất cả. và liên quan đến các bài kiểm tra, chúng thực sự được thực hiện khá tốt, chúng sử dụng hàng giả cho mọi thứ và không có IO nào cả.

Một giải pháp khả thi sẽ là chuyển phần thử nghiệm từ các máy phát triển sang thiết lập tích hợp liên tục ( ví dụ Jenkins ) bằng phần mềm kiểm soát phiên bản của một số hương vị ( git , svn , v.v.).

Khi mã mới phải được viết, nhà phát triển đã cho sẽ tạo một nhánh cho bất cứ điều gì họ đang làm trong kho lưu trữ. Tất cả công việc sẽ được thực hiện trong nhánh này và họ có thể cam kết thay đổi của mình với chi nhánh bất cứ lúc nào mà không làm hỏng dòng mã chính.

Khi tính năng đã cho, sửa lỗi hoặc bất cứ thứ gì họ đang làm việc đã được hoàn thành, nhánh đó có thể được hợp nhất trở lại vào thân cây (hoặc tuy nhiên bạn thích làm điều đó hơn) khi tất cả các bài kiểm tra đơn vị được chạy. Nếu thử nghiệm thất bại, việc hợp nhất bị từ chối và nhà phát triển được thông báo để họ có thể sửa lỗi.

Bạn cũng có thể yêu cầu máy chủ CI của mình chạy thử nghiệm đơn vị trên mỗi nhánh tính năng khi các cam kết được thực hiện. Bằng cách này, nhà phát triển có thể thực hiện một số thay đổi, cam kết mã và để máy chủ chạy thử nghiệm trong nền trong khi họ tiếp tục làm việc với các thay đổi bổ sung hoặc các dự án khác.

Một hướng dẫn tuyệt vời cho một cách thực hiện thiết lập như vậy có thể được tìm thấy ở đây (git cụ thể nhưng nên hoạt động cho các hệ thống kiểm soát phiên bản khác): http://nvie.com/posts/a-successful-git-branching-model/

Phần lớn các bài kiểm tra đơn vị nên mất dưới 10 mili giây mỗi lần. Có 'gần một ngàn bài kiểm tra' là không có gì và có thể mất vài giây để chạy.

Nếu họ không phải, thì bạn nên dừng viết các bài kiểm tra tích hợp được kết hợp cao (trừ khi đó là những gì mã cần) và bắt đầu viết các bài kiểm tra đơn vị tốt (bắt đầu bằng mã được tách riêng và sử dụng đúng giả / giả / cùi / v.v.). Sự ghép nối đó sẽ ảnh hưởng đến chất lượng thử nghiệm và thời gian viết chúng - vì vậy đây không chỉ là vấn đề giảm thời gian chạy thử nghiệm.

Có một số cách tiếp cận tôi đã sử dụng để giải quyết vấn đề tương tự:

1. Kiểm tra thời gian thực hiện và tìm tất cả các thử nghiệm chậm nhất và sau đó phân tích lý do tại sao chúng mất quá nhiều thời gian để thực hiện .
2. Bạn có 100 dự án, có thể bạn không cần phải xây dựng và kiểm tra chúng mỗi lần? Bạn có thể chạy tất cả các chỉ trong một đêm xây dựng? Tạo một số cấu hình xây dựng 'nhanh' để sử dụng hàng ngày . Máy chủ CI sẽ chỉ thực hiện tập hợp giới hạn các dự án không liên quan đến các phần 'nóng' trong quy trình phát triển hiện tại của bạn .
3. Giả lập và cô lập mọi thứ bạn có thể , tránh I / O đĩa / mạng bất cứ khi nào có thể
4. Khi không thể cách ly các hoạt động đó, bạn có thể có các bài kiểm tra tích hợp không? Có thể bạn chỉ có thể lên lịch kiểm tra tích hợp để xây dựng ban đêm ?
5. Kiểm tra tất cả các singletons thỉnh thoảng, giữ các tham chiếu đến các thể hiện / tài nguyên và tiêu thụ bộ nhớ, điều này có thể dẫn đến suy giảm hiệu suất trong khi chạy tất cả các bài kiểm tra.

Ngoài ra, bạn có thể sử dụng các công cụ sau để giúp cả cuộc sống của bạn dễ dàng và các bài kiểm tra chạy nhanh hơn

1. Gated cam kết một số máy chủ CI có thể được cấu hình để thực hiện xây dựng và kiểm tra trước khi cam kết mã vào kho lưu trữ nguồn. Nếu ai đó cam kết mã mà không chạy tất cả các thử nghiệm trước đó, cũng chứa các thử nghiệm thất bại, nó sẽ bị từ chối và trả lại cho tác giả.
2. Cấu hình máy chủ CI để thực hiện kiểm tra song song : sử dụng một số máy hoặc quy trình. Ví dụ là pnunitvà cấu hình CI với một số nút.
3. Trình cắm thử nghiệm liên tục cho các nhà phát triển, sẽ tự động chạy tất cả các thử nghiệm trong khi viết mã.

0. Lắng nghe lập trình viên của bạn.

Nếu họ không chạy thử nghiệm, điều đó có nghĩa là họ nhận thấy chi phí (đang chờ các thử nghiệm chạy, xử lý các lỗi sai) lớn hơn giá trị (bắt lỗi ngay lập tức). Giảm chi phí, tăng giá trị và mọi người sẽ chạy thử nghiệm mọi lúc.

1. Làm cho bài kiểm tra của bạn đáng tin cậy 100%.

Nếu bạn từng có bài kiểm tra thất bại với âm tính giả, hãy giải quyết ngay lập tức. Sửa chữa chúng, thay đổi chúng, loại bỏ chúng, bất cứ điều gì cần thiết để đảm bảo độ tin cậy 100%. (Bạn có thể có một bộ các bài kiểm tra không đáng tin cậy nhưng vẫn hữu ích để bạn có thể chạy riêng, nhưng phần chính của các bài kiểm tra phải đáng tin cậy.)

2. Thay đổi hệ thống của bạn để đảm bảo rằng tất cả các bài kiểm tra đều vượt qua mọi lúc.

Sử dụng các hệ thống tích hợp liên tục để đảm bảo rằng chỉ các cam kết chuyển qua được sáp nhập vào nhánh chính / chính thức / phát hành / bất cứ chi nhánh nào.

3. Thay đổi văn hóa của bạn để đánh giá 100% vượt qua các bài kiểm tra.

Dạy cho bài học rằng một nhiệm vụ không "hoàn thành" cho đến khi 100% bài kiểm tra vượt qua và nó đã được hợp nhất vào nhánh chính / chính thức / phát hành / bất cứ chi nhánh nào.

4. Làm các bài kiểm tra nhanh.

Tôi đã làm việc trong các dự án trong đó các bài kiểm tra mất một giây và các dự án mà chúng mất cả ngày. Có một mối tương quan mạnh mẽ giữa thời gian cần thiết để chạy thử nghiệm và năng suất của tôi.

Các bài kiểm tra càng kéo dài, bạn càng ít chạy chúng. Điều đó có nghĩa là bạn sẽ đi lâu hơn mà không nhận được phản hồi về những thay đổi bạn đang thực hiện. Nó cũng có nghĩa là bạn sẽ đi lâu hơn giữa các lần cam kết. Cam kết thường xuyên hơn có nghĩa là các bước nhỏ hơn dễ hợp nhất; lịch sử cam kết dễ theo dõi hơn; tìm một lỗi trong lịch sử dễ dàng hơn; quay trở lại là dễ dàng hơn, quá.

Hãy tưởng tượng các bài kiểm tra chạy nhanh đến mức bạn không tự động chạy chúng mỗi khi bạn biên dịch.

Làm các bài kiểm tra nhanh có thể khó (đó là những gì OP yêu cầu, phải không!). Decoupling là chìa khóa. Giả / giả là OK, nhưng tôi nghĩ bạn có thể làm tốt hơn bằng cách tái cấu trúc để làm cho giả / giả không cần thiết. Xem blog của Arlo Belshee, bắt đầu với http://arlobelshee.com/post/the-no-mocks-book .

5. Làm các bài kiểm tra hữu ích.

Nếu các bài kiểm tra không thất bại khi bạn làm hỏng, thì vấn đề là gì? Dạy bản thân viết các bài kiểm tra sẽ bắt được các lỗi mà bạn có khả năng tạo ra. Đây là một kỹ năng tự nó, và sẽ được chú ý nhiều.

Một vài phút là OK cho các bài kiểm tra đơn vị. Tuy nhiên, hãy nhớ rằng có 3 loại xét nghiệm chính:

1. Kiểm thử đơn vị - kiểm tra từng "đơn vị" (lớp hoặc phương thức) độc lập với phần còn lại của dự án
2. Kiểm thử tích hợp - kiểm tra toàn bộ dự án, thường bằng cách thực hiện các cuộc gọi vào chương trình. Một số dự án tôi đã thấy kết hợp điều này với các bài kiểm tra hồi quy. Có sự chế nhạo ít hơn đáng kể ở đây so với các bài kiểm tra đơn vị
3. Kiểm tra hồi quy - kiểm tra toàn bộ dự án đã hoàn thành, vì bộ kiểm thử là người dùng cuối. Nếu bạn có một ứng dụng giao diện điều khiển, bạn sẽ sử dụng bàn điều khiển để chạy và kiểm tra chương trình. Bạn không bao giờ để lộ nội bộ cho các thử nghiệm này và bất kỳ người dùng cuối nào trong chương trình của bạn sẽ (về lý thuyết) có thể chạy bộ kiểm tra hồi quy của bạn (mặc dù chúng sẽ không bao giờ)

Chúng được liệt kê theo thứ tự tốc độ. Kiểm tra đơn vị nên được nhanh chóng. Họ sẽ không bắt được mọi lỗi, nhưng họ xác định rằng chương trình này rất lành mạnh. Kiểm tra đơn vị nên chạy trong 3 phút hoặc ít hơn hoặc phần cứng khá. Bạn nói rằng bạn chỉ có 1000 bài kiểm tra đơn vị, và họ mất 2-3 phút? Chà, có lẽ là ổn.

Những điều cần kiểm tra:

• Hãy chắc chắn để đảm bảo rằng các bài kiểm tra đơn vị và kiểm tra tích hợp của bạn là riêng biệt mặc dù. Kiểm tra tích hợp sẽ luôn luôn chậm hơn.

• Đảm bảo rằng các bài kiểm tra đơn vị của bạn đang chạy song song. Không có lý do gì để họ không làm nếu họ là các bài kiểm tra đơn vị thực sự

• Đảm bảo kiểm tra đơn vị của bạn là "phụ thuộc miễn phí". Họ không bao giờ nên truy cập cơ sở dữ liệu hoặc hệ thống tập tin

Ngoài ra, các bài kiểm tra của bạn không quá tệ ngay bây giờ. Tuy nhiên, để tham khảo, một trong những người bạn của tôi trong nhóm Microsoft có 4.000 bài kiểm tra đơn vị chạy dưới 2 phút trên phần cứng tốt (và đó là một dự án phức tạp). Có thể có các bài kiểm tra đơn vị nhanh. Loại bỏ sự phụ thuộc (và giả chỉ càng nhiều càng tốt) là điều chính để có được tốc độ.

Huấn luyện các nhà phát triển của bạn về Quy trình phần mềm cá nhân (PSP) giúp họ hiểu và cải thiện hiệu suất của họ bằng cách sử dụng nhiều kỷ luật hơn. Viết mã không liên quan gì đến việc đập ngón tay trên bàn phím và sau đó nhấn nút biên dịch và kiểm tra.

PSP đã từng rất phổ biến trong quá khứ khi biên dịch mã là một quá trình mất rất nhiều thời gian (giờ / ngày trên máy tính lớn nên mọi người phải chia sẻ trình biên dịch). Nhưng khi các máy trạm cá nhân trở nên mạnh mẽ hơn, tất cả chúng ta đều chấp nhận quy trình:

1. gõ một số mã mà không cần suy nghĩ
2. nhấn xây dựng / biên dịch
3. sửa lỗi cú pháp của bạn để làm cho nó biên dịch
4. chạy thử nghiệm để xem những gì bạn viết thực sự có ý nghĩa

Nếu bạn suy nghĩ trước khi nhập, và sau khi bạn nhập, hãy xem lại những gì bạn đã viết, bạn có thể giảm số lỗi trước khi chạy bộ xây dựng và kiểm tra. Học cách không nhấn build 50 lần một ngày, nhưng có thể một hoặc hai lần, sau đó vấn đề ít hơn là thời gian xây dựng và thử nghiệm của bạn mất thêm vài phút.

Một cách có thể: chia giải pháp của bạn. Nếu một giải pháp có 100 dự án, thì nó không thể quản lý được. Chỉ vì hai dự án (giả sử A và B) sử dụng một số mã chung từ dự án khác (giả sử Lib) không có nghĩa là chúng phải nằm trong cùng một giải pháp.

Thay vào đó, bạn có thể tạo giải pháp A với các dự án A và Lib và cả giải pháp B với các dự án B và Lib.

Tôi đang ở trong một tình huống tương tự. Tôi có bài kiểm tra đơn vị kiểm tra giao tiếp với máy chủ. Họ đang kiểm tra hành vi với thời gian chờ, hủy kết nối, v.v ... Toàn bộ bộ kiểm tra chạy 7 phút.

7 phút là một khoảng thời gian tương đối ngắn nhưng đó không phải là điều bạn sẽ làm trước mỗi lần cam kết.

Chúng tôi cũng có một bộ kiểm tra giao diện người dùng tự động, thời gian chạy của họ là 2 giờ. Đó không phải là thứ bạn muốn chạy mỗi ngày trên máy tính.

Vậy lam gi?

1. Thay đổi các bài kiểm tra thường không hiệu quả lắm.
2. Chỉ chạy các bài kiểm tra có liên quan trước khi cam kết của bạn.
3. Chạy tất cả các bài kiểm tra của bạn mỗi ngày (hoặc nhiều lần trong ngày) trên máy chủ xây dựng. Điều này cũng sẽ cung cấp cho bạn khả năng tạo báo cáo phân tích mã & bảo hiểm mã đẹp.

Điều quan trọng là: tất cả các bài kiểm tra của bạn nên được chạy thường xuyên vì điều quan trọng là tìm ra lỗi. Tuy nhiên, không nhất thiết phải tìm thấy chúng trước khi cam kết.

Mặc dù mô tả của bạn về vấn đề không cung cấp cái nhìn sâu sắc về codebase, tôi nghĩ rằng tôi có thể nói rằng vấn đề của bạn là hai lần một cách an toàn.

Học cách viết các bài kiểm tra đúng.

Bạn nói rằng bạn có gần một ngàn bài kiểm tra, và bạn có 120 dự án. Giả sử rằng hầu hết một nửa trong số các dự án đó là các dự án thử nghiệm, bạn có 1000 thử nghiệm đến 60 dự án mã sản xuất. Điều đó cung cấp cho bạn khoảng 16-17 bài kiểm tra pr. dự án!!!

Đó có lẽ là số lượng bài kiểm tra mà tôi sẽ phải trải qua khoảng 1-2 lớp trong một hệ thống sản xuất. Vì vậy, trừ khi bạn chỉ có 1-2 lớp trong mỗi dự án (trong trường hợp đó cấu trúc dự án của bạn quá mịn), các bài kiểm tra của bạn quá lớn, chúng bao phủ quá nhiều nền tảng. Bạn nói đây là dự án đầu tiên mà bạn đang làm TDD đúng cách. Có thể nói, những con số mà bạn trình bày chỉ ra rằng đây không phải là trường hợp, bạn không làm tài sản TDD.

Bạn cần học cách viết các bài kiểm tra phù hợp, điều đó có thể có nghĩa là bạn cần học cách làm cho mã có thể kiểm tra được ngay từ đầu. Nếu bạn không thể tìm thấy kinh nghiệm trong nhóm để làm điều đó, tôi sẽ đề nghị thuê trợ giúp từ bên ngoài, ví dụ như dưới dạng một hoặc hai chuyên gia tư vấn giúp nhóm của bạn trong thời gian 2-3 tháng để học viết mã có thể kiểm tra và nhỏ kiểm tra đơn vị tối thiểu.

Để so sánh, trong dự án .NET mà tôi hiện đang làm việc, chúng tôi có thể chạy khoảng 500 bài kiểm tra đơn vị trong vòng chưa đầy 10 giây (và điều đó thậm chí không được đo trên một máy có thông số kỹ thuật cao). Nếu đó là những số liệu của bạn, bạn sẽ không ngại chạy những thứ này thường xuyên.

Học cách quản lý cấu trúc dự án.

Bạn đã chia giải pháp thành 120 dự án. Đó là theo tiêu chuẩn của tôi một lượng dự án đáng kinh ngạc.

Vì vậy, nếu thực sự có số lượng dự án đó (mà tôi có cảm giác là không hợp lý - nhưng câu hỏi của bạn không cung cấp đủ thông tin để đưa ra phán quyết đủ điều kiện về vấn đề này), bạn cần chia các dự án thành các thành phần nhỏ hơn có thể được xây dựng, phiên bản và triển khai riêng. Vì vậy, khi một nhà phát triển chạy đơn vị bộ thử nghiệm, anh ấy / cô ấy chỉ cần chạy các thử nghiệm liên quan đến thành phần mà anh ấy / cô ấy đang làm việc hiện tại. Máy chủ xây dựng cần quan tâm đến việc xác minh rằng mọi thứ tích hợp chính xác.

Nhưng việc tách một dự án trong nhiều thành phần xây dựng, phiên bản và triển khai riêng biệt đòi hỏi theo kinh nghiệm của tôi một nhóm phát triển rất trưởng thành, một nhóm trưởng thành hơn tôi có cảm giác rằng nhóm của bạn.

Nhưng với bất kỳ giá nào, bạn cần phải làm gì đó về cấu trúc dự án. Hoặc chia các dự án thành các thành phần riêng biệt, hoặc bắt đầu hợp nhất các dự án.

Hãy tự hỏi nếu bạn thực sự cần 120 dự án?

ps Bạn có thể muốn kiểm tra NCrunch. Đó là một trình cắm Visual Studio tự động chạy thử nghiệm của bạn trong nền.

Kiểm tra JUnit thường là nhanh chóng, nhưng một số trong số họ chỉ đơn giản là phải mất một thời gian để thực hiện.

Ví dụ, kiểm tra cơ sở dữ liệu thường mất một ít thời gian để khởi tạo và kết thúc.

Nếu bạn có hàng trăm bài kiểm tra, ngay cả khi chúng nhanh, chúng đòi hỏi nhiều thời gian để chạy vì số lượng của chúng.

Những gì có thể được thực hiện là:

1) Xác định các bài kiểm tra quan trọng. Những phần dành cho những phần quan trọng nhất của thư viện và những phần có khả năng bị lỗi sau khi thay đổi. Chỉ những bài kiểm tra nên được chạy luôn trong quá trình biên dịch. Nếu một số mã thường bị hỏng, các kiểm tra của nó phải là bắt buộc ngay cả khi chúng mất nhiều thời gian để thực thi, mặt khác, nếu một phần của phần mềm không bao giờ gây ra sự cố, bạn có thể bỏ qua các kiểm tra trên mỗi bản dựng một cách an toàn.

2) Chuẩn bị máy chủ tích hợp liên tục, sẽ chạy tất cả các thử nghiệm trong nền. Tùy thuộc vào bạn nếu bạn quyết định xây dựng mỗi giờ hoặc xây dựng sau mỗi lần xác nhận (lần thứ hai chỉ có ý nghĩa nếu bạn muốn tự động phát hiện cam kết của mình đã gây ra sự cố).

Các vấn đề tôi đã thấy:

a) Sử dụng IOC để xây dựng các yếu tố thử nghiệm. 70 giây -> 7 giây bằng cách loại bỏ Container.

b) Không chế nhạo tất cả các lớp. Giữ các bài kiểm tra đơn vị của bạn đến một yếu tố duy nhất. Tôi đã thấy các bài kiểm tra lan man qua một vài lớp. Đây không phải là bài kiểm tra đơn vị và nhiều khả năng phá vỡ.

c) Hồ sơ họ để tìm hiểu những gì đang xảy ra. Tôi thấy nhà xây dựng đang xây dựng những thứ tôi không cần nên tôi đã bản địa hóa nó và giảm thời gian chạy.

d) Hồ sơ. có lẽ mã không tốt và bạn có thể đạt được hiệu quả từ đánh giá.

e) Loại bỏ sự phụ thuộc. Giữ cho bạn kiểm tra thực thi nhỏ sẽ giảm thời gian tải. Sử dụng thư viện giao diện và các thùng chứa IOC để chạy giải pháp cuối cùng của bạn nhưng các dự án thử nghiệm chính của bạn chỉ nên xác định thư viện giao diện. Điều này đảm bảo tách biệt, đảm bảo dễ kiểm tra hơn và cũng làm cho bản in chân thử nghiệm của bạn nhỏ hơn.

Tôi cảm thấy nỗi đau của bạn, và tôi đã chạy đến một số nơi mà tốc độ xây dựng có thể được cải thiện rất nhiều. Tuy nhiên, con số trên điều tôi khuyên dùng là đo ở một chi tiết chi tiết để tìm ra nơi mà bản dựng của bạn mất nhiều thời gian nhất. Ví dụ, tôi có một bản dựng với khoảng 30 dự án chỉ mất hơn một phút để chạy. Tuy nhiên, đó chỉ là một phần của bức tranh. Tôi cũng biết dự án nào mất nhiều thời gian nhất để xây dựng, giúp tập trung nỗ lực của tôi.

Những thứ ăn hết thời gian xây dựng:

• Tải xuống gói (Nuget cho C #, Maven cho Java, Gem cho Ruby, v.v.)
• Sao chép số lượng lớn tệp trên hệ thống tệp (ví dụ: tệp hỗ trợ GDAL)
• Mở kết nối tới cơ sở dữ liệu (một số mất hơn một giây cho mỗi kết nối để đàm phán)
• Mã dựa trên phản ánh
• Mã tự động
• Sử dụng ngoại lệ để kiểm soát luồng chương trình

Các thư viện giả hoặc sử dụng mã phản chiếu hoặc tiêm mã bằng thư viện mã byte để tạo giả cho bạn. Trong khi nó rất thuận tiện, nó ăn hết thời gian thử nghiệm. Nếu bạn đang tạo các giả trong vòng lặp trong thử nghiệm của mình, nó có thể thêm một lượng thời gian có thể đo được vào các thử nghiệm đơn vị.

Có nhiều cách để khắc phục sự cố:

• Di chuyển các kiểm tra liên quan đến cơ sở dữ liệu sang tích hợp (tức là chỉ trên máy chủ xây dựng CI)
• Tránh tạo ra các giả trong các vòng lặp trong các bài kiểm tra của bạn. Trong thực tế, chỉ cần tránh các vòng lặp trong các bài kiểm tra của bạn hoàn toàn. Bạn có thể có được kết quả tương tự bằng cách sử dụng một bài kiểm tra tham số trong trường hợp đó.
• Xem xét chia giải pháp lớn của bạn thành các giải pháp riêng biệt

Khi giải pháp của bạn chứa hơn 100 dự án, bạn có sự kết hợp của mã thư viện, các bài kiểm tra và mã ứng dụng. Mỗi thư viện có thể là giải pháp riêng của nó với các bài kiểm tra liên quan. Jet Brains Team City là một máy chủ xây dựng CI nhân đôi như một máy chủ Nuget - và tôi chắc chắn đó không phải là máy chủ duy nhất. Điều đó cho phép bạn linh hoạt di chuyển những thư viện có thể không được thay đổi thường xuyên sang các giải pháp / dự án của riêng họ và sử dụng Nuget để giải quyết các phụ thuộc cho mã ứng dụng của bạn. Các giải pháp nhỏ hơn có nghĩa là bạn có thể thực hiện các thay đổi của mình đối với thư viện một cách nhanh chóng và không có bất kỳ phiền phức nào, và tận hưởng các lợi ích trong giải pháp chính.

Môi trường thử nghiệm của bạn có thể chạy bất cứ nơi nào? Nếu có thể, hãy sử dụng điện toán đám mây để chạy thử nghiệm. Chia các bài kiểm tra giữa N máy ảo. Nếu thời gian để chạy các bài kiểm tra trên một máy duy nhất là T1 giây, thì thời gian để chạy chúng tách ra, T2, có thể đạt tới mức T2 = T1 / N. (Giả sử mỗi trường hợp kiểm tra mất khoảng thời gian như nhau.) Và bạn chỉ phải trả tiền cho máy ảo khi bạn sử dụng chúng. Vì vậy, bạn không có một loạt các máy kiểm tra ngồi trong phòng thí nghiệm nào đó 24/7. (Tôi rất thích có thể làm điều này ở nơi tôi làm việc, nhưng chúng tôi gắn liền với phần cứng cụ thể. Không có máy ảo nào cho tôi.)