Điểm chạy thử nghiệm đơn vị trên máy chủ CI là gì?

Tại sao bạn lại chạy thử nghiệm đơn vị trên máy chủ CI?

Chắc chắn, vào thời điểm một cái gì đó được cam kết thành thạo, một nhà phát triển đã chạy tất cả các thử nghiệm đơn vị trước đó và sửa bất kỳ lỗi nào có thể xảy ra với mã mới của họ. Không phải đó là điểm của bài kiểm tra đơn vị sao? Nếu không, họ vừa phạm mã bị hỏng.

Chắc chắn, vào thời điểm một cái gì đó được cam kết thành thạo, một nhà phát triển đã chạy tất cả các thử nghiệm đơn vị trước đó và sửa bất kỳ lỗi nào có thể xảy ra với mã mới của họ.

Hay không. Có thể có nhiều lý do tại sao điều này có thể xảy ra:

• Nhà phát triển không có kỷ luật để làm điều đó
• Họ đã quên
• Họ đã không cam kết tất cả mọi thứ và đẩy một bộ cam kết không hoàn chỉnh (cảm ơn Matthieu M.
• Họ chỉ chạy một số thử nghiệm, nhưng không phải toàn bộ bộ (cảm ơn nhgrif )
• Họ đã thử nghiệm trên chi nhánh của mình trước khi sáp nhập (cảm ơn nhgrif * 2)

Nhưng quan điểm thực sự là chạy thử nghiệm trên một máy không phải là máy của nhà phát triển. Một cái được cấu hình khác nhau.

Điều này giúp nắm bắt các vấn đề trong đó các bài kiểm tra và / hoặc mã phụ thuộc vào thứ gì đó cụ thể cho hộp nhà phát triển (cấu hình, dữ liệu, múi giờ, miền địa phương, bất cứ điều gì).

Các lý do tốt khác để xây dựng CI để chạy thử nghiệm:

• Thử nghiệm trên các nền tảng khác nhau ngoài các nền tảng phát triển chính, điều mà nhà phát triển có thể khó thực hiện. (cảm ơn TZHX )
• Chấp nhận / Tích hợp / Kết thúc để kết thúc / Các thử nghiệm chạy thực sự dài có thể được chạy trên máy chủ CI thường không được chạy trên hộp dành cho nhà phát triển. (cảm ơn Ixrec )
• Nhà phát triển có thể thực hiện một thay đổi nhỏ trước khi đẩy / cam kết (nghĩ rằng đây là thay đổi an toàn và do đó không chạy thử nghiệm). (cảm ơn Ixrec * 2)
• Cấu hình máy chủ CI thường không bao gồm tất cả các công cụ và cấu hình dành cho nhà phát triển và do đó gần với hệ thống sản xuất hơn
• Các hệ thống CI xây dựng dự án từ đầu mỗi lần, nghĩa là các bản dựng được lặp lại
• Thay đổi thư viện có thể gây ra sự cố xuôi dòng - máy chủ CI có thể được cấu hình để xây dựng tất cả các cơ sở mã phụ thuộc, không chỉ thư viện

Là một nhà phát triển không chạy tất cả các thử nghiệm tích hợp và đơn vị trước khi đưa ra cam kết kiểm soát nguồn, tôi sẽ đưa ra biện pháp bảo vệ của mình ở đây.

Tôi sẽ phải xây dựng, kiểm tra và xác minh rằng một ứng dụng chạy chính xác trên:

• Microsoft Windows XP và Vista với trình biên dịch Visual Studio 2008.
• Microsoft Windows 7 với trình biên dịch Visual Studio 2010.
  • Oh, và MSI xây dựng cho từng người.
• RHEL 5 và 6 với 4,1 và 4,4 tương ứng (tương tự CentOS)
  • 7 sớm. Woop-de-woop.
• Fedora Workstation với GCC cho ba phiên bản gần đây.
• Debian (và các dẫn xuất như Ubuntu) cho ba phiên bản gần đây.
• Mac OSX trong ba phiên bản gần đây.
  • Và các gói (vòng / phút, dmg, v.v.)

Thêm vào Fortran (với cả trình biên dịch Intel và GNU), Python (và đó là các phiên bản khác nhau tùy thuộc vào HĐH) và các thành phần tập lệnh bash / bat và, tôi nghĩ bạn có thể thấy mọi thứ xoắn ốc

Vì vậy, đó là mười sáu máy tôi phải có, chỉ để chạy một vài thử nghiệm một vài lần một ngày. Nó sẽ gần như là một công việc toàn thời gian chỉ để quản lý cơ sở hạ tầng cho điều đó. Tôi nghĩ rằng hầu hết mọi người sẽ đồng ý rằng điều đó không hợp lý, đặc biệt là nhân nó với số lượng người trong dự án. Vì vậy, chúng tôi để cho các máy chủ CI của chúng tôi làm việc.

Các bài kiểm tra đơn vị không ngăn bạn phạm mã bị hỏng, họ nói với bạn nếu họ biết bạn đã làm gì đó. Mọi người có thể nói "kiểm tra đơn vị nên nhanh" và tiếp tục về các nguyên tắc và thiết kế mẫu và phương pháp, nhưng thực tế đôi khi tốt hơn là để các máy tính chúng tôi thiết kế cho các nhiệm vụ lặp đi lặp lại, đơn điệu làm những việc đó và chỉ tham gia nếu chúng nói với chúng tôi rằng họ đã tìm thấy một cái gì đó.

Ngoài câu trả lời Oded xuất sắc:

• Bạn kiểm tra mã từ kho lưu trữ . Nó có thể hoạt động trên máy của bạn với các tệp của bạn ... mà bạn quên cam kết. Nó có thể phụ thuộc vào một bảng mới không có tập lệnh tạo (ví dụ: trong Liquidibase), một số tệp dữ liệu cấu hình hoặc thuộc tính.
• Bạn tránh các vấn đề tích hợp mã. Một nhà phát triển tải xuống phiên bản cuối cùng, tạo thử nghiệm đơn vị và tích hợp, thêm mã, vượt qua tất cả thử nghiệm trong máy của anh ta, cam kết và đẩy. Một nhà phát triển khác vừa làm điều tương tự. Cả hai thay đổi đều đúng nhưng khi hợp nhất sẽ gây ra lỗi. Đây có thể là sự hợp nhất kho lưu trữ hoặc chỉ là nó không bị phát hiện là xung đột. Ví dụ: Dev 1 xóa tập tin hoàn toàn không được sử dụng. Dev 2 mã chống lại tệp này và kiểm tra mà không thay đổi Dev 1.
• Bạn phát triển một tập lệnh để triển khai tự động từ kho lưu trữ. Có một tòa nhà phổ quát và triển khai kịch bản giải quyết rất nhiều vấn đề. Một số nhà phát triển có thể đã thêm một tùy chọn lib hoặc biên dịch không được chia sẻ bởi mọi người. Điều này không chỉ giúp bạn tiết kiệm thời gian, mà quan trọng hơn, nó làm cho việc triển khai an toàn và có thể dự đoán được. Hơn nữa, bạn có thể quay lại kho lưu trữ của mình về phiên bản 2.3.1 và triển khai phiên bản này với một tập lệnh hoạt động với phiên bản này. Nó bao gồm các đối tượng cơ sở dữ liệu như khung nhìn, thủ tục được lưu trữ, khung nhìn và kích hoạt nên được phiên bản. (Hoặc bạn sẽ không thể quay lại phiên bản hoàn toàn khả thi).
• Các thử nghiệm khác : Giống như tích hợp, hiệu suất và thử nghiệm từ đầu đến cuối. Điều này có thể chậm và có thể bao gồm các công cụ kiểm tra như Selenium. Bạn có thể cần một bộ dữ liệu đầy đủ với cơ sở dữ liệu thực tế thay vì các đối tượng giả hoặc HSQL.

Tôi đã từng làm việc cho một công ty có nhiều lỗi khi triển khai do quá trình hợp nhất và triển khai. Điều này được gây ra bởi một khung công tác kỳ lạ khiến cho việc kiểm tra và CI trở nên khó khăn. Đó không phải là một kinh nghiệm hạnh phúc khi thấy rằng mã hoạt động hoàn hảo trong quá trình phát triển đã không được đưa vào sản xuất.

Bạn sẽ nghĩ như vậy phải không - nhưng các nhà phát triển là con người và đôi khi họ quên mất.

Ngoài ra, các nhà phát triển thường không rút được mã mới nhất. Các thử nghiệm mới nhất của họ có thể chạy tốt sau đó tại thời điểm nhận phòng, một người khác cam kết thay đổi đột phá.

Các xét nghiệm của bạn cũng có thể dựa vào tài nguyên cục bộ (chưa được kiểm tra). Một cái gì đó mà bài kiểm tra đơn vị địa phương của bạn sẽ không nhận.

Nếu bạn nghĩ rằng tất cả những điều trên là huyền ảo, thì có một mức trên CI (ít nhất là trên TFS) được gọi là Gated nơi các bản dựng bị lỗi thử nghiệm bị gác lại và không được cam kết với cơ sở mã.

đến lúc một cái gì đó được cam kết để làm chủ

Tôi thường thiết lập CI của mình để chạy trên mỗi lần xác nhận. Các chi nhánh không được sáp nhập vào chủ cho đến khi chi nhánh đã được thử nghiệm. Nếu bạn đang dựa vào việc chạy thử nghiệm trên bản gốc, thì điều đó sẽ mở ra một cửa sổ cho bản dựng bị phá vỡ.

Chạy thử nghiệm trên máy CI là về kết quả có thể lặp lại. Vì máy chủ CI có môi trường sạch đã biết được lấy từ VCS của bạn, bạn biết rằng kết quả kiểm tra là chính xác. Khi chạy cục bộ, bạn có thể quên cam kết một số mã cần thiết để họ vượt qua hoặc có mã không được cam kết khiến họ vượt qua khi họ thất bại.

Nó cũng có thể tiết kiệm thời gian của các nhà phát triển bằng cách chạy song song các bộ khác nhau, đặc biệt nếu một số thử nghiệm chậm, nhiều phút không có khả năng chạy cục bộ sau mỗi thay đổi.

Trong công việc hiện tại của tôi, việc triển khai sản xuất của chúng tôi được kiểm soát trên CI vượt qua tất cả các bài kiểm tra. Các kịch bản triển khai sẽ ngăn triển khai trừ khi chúng đi qua. Điều này làm cho nó không thể vô tình quên để chạy chúng.

CI là một phần của quy trình làm việc cũng giảm gánh nặng cho các nhà phát triển. Là một nhà phát triển, bạn có thường chạy một kẻ nói dối, phân tích tĩnh, kiểm tra đơn vị, bảo hiểm mã và kiểm tra tích hợp cho mỗi thay đổi không? CI có thể, hoàn toàn tự động và không cần phải suy nghĩ về nó - giảm mệt mỏi quyết định.

Vào thời điểm một cái gì đó được cam kết thành thạo, một nhà phát triển nên đã chạy tất cả các bài kiểm tra đơn vị ... nhưng nếu họ không có thì sao? Nếu bạn không chạy thử nghiệm đơn vị trên máy chủ CI, bạn sẽ không biết cho đến khi có người khác thực hiện các thay đổi cho máy của họ và phát hiện ra các thử nghiệm đã phá vỡ chúng.

Ngoài ra, nhà phát triển có thể đã mắc lỗi và tham chiếu tài nguyên cục bộ cụ thể cho máy của họ. Khi họ kiểm tra mã và CI chạy không thành công, vấn đề được xác định ngay lập tức và có thể được sửa chữa.

Giả sử (trái với các câu trả lời khác) rằng các nhà phát triển khá kỷ luật và thực hiện kiểm tra đơn vị trước khi cam kết, có thể có một số lý do:

• chạy thử nghiệm đơn vị có thể mất nhiều thời gian cho một số thiết lập đặc biệt. Ví dụ, chạy thử nghiệm đơn vị với trình kiểm tra bộ nhớ (như valgrind) có thể mất nhiều thời gian hơn. Mặc dù tất cả các bài kiểm tra đơn vị đều vượt qua, kiểm tra bộ nhớ có thể thất bại.
• kết quả không quan trọng đối với một số cài đặt đặc biệt - ví dụ: chạy thử nghiệm đơn vị để kiểm tra phạm vi bảo hiểm mã yêu cầu các cờ biên dịch đặc biệt. Đối với các nhà phát triển bình thường, phạm vi bảo hiểm mã không quan trọng - điều quan trọng hơn là mọi người quan tâm rằng mã duy trì chất lượng nhất định, như lãnh đạo nhóm.

Có thể tưởng tượng các trường hợp khi thay đổi A không phá vỡ thử nghiệm và thay đổi B không phá vỡ thử nghiệm, nhưng A và B cùng làm. Nếu A và B được tạo bởi các nhà phát triển khác nhau, chỉ có máy chủ CI sẽ phát hiện ra lỗi mới. A và B thậm chí có thể là hai phần của cùng một câu dài hơn.

Hãy tưởng tượng một chuyến tàu được điều khiển bởi hai đầu máy A và B. Có thể một là quá đủ và đây là cách khắc phục để áp dụng. Tuy nhiên, nếu hai "cách khắc phục" được áp dụng loại bỏ cả hai, tàu sẽ không di chuyển.

Ngoài ra, không phải tất cả các nhà phát triển đều chạy tất cả các bài kiểm tra Đơn vị, trong khi hầu hết các nhà phát triển giỏi đều làm.

Hãy hỏi một câu hỏi tương đương:

Tại sao bạn sẽ xây dựng mã trên máy chủ CI?

Chắc chắn, vào thời điểm một cái gì đó được cam kết thành thạo, một nhà phát triển đã xây dựng mã trước đó và sửa bất kỳ lỗi nào có thể xảy ra với mã mới của họ. Đó không phải là điểm của mã xây dựng sao? Nếu không, họ vừa phạm mã bị hỏng.

Có một số lý do để thực hiện CI, nhưng điểm chính của CI là để có được ý tưởng về trạng thái của mã theo thời gian. Lợi ích chính (trong số một số) điều này mang lại, là chúng ta có thể tìm ra khi nào bản dựng bị hỏng, tìm ra cái gì đã phá vỡ nó, và sau đó sửa nó.

Nếu mã không bao giờ bị hỏng, tại sao chúng ta thậm chí sử dụng CI? Để cung cấp các bản dựng để thử nghiệm, các bản dựng hàng đêm sẽ đủ tốt.