Phương pháp: Viết bài kiểm tra đơn vị cho nhà phát triển khác

Tôi đã suy nghĩ về phát triển phần mềm và viết bài kiểm tra đơn vị. Tôi có ý tưởng sau đây:

Giả sử chúng ta có các cặp nhà phát triển. Mỗi cặp chịu trách nhiệm cho một phần của mã. Một từ cặp thực hiện một tính năng (viết mã) và thứ hai viết một bài kiểm tra đơn vị cho nó. Các xét nghiệm được viết sau khi mã. Trong ý tưởng của tôi họ giúp đỡ lẫn nhau, nhưng làm việc khá riêng biệt. Lý tưởng nhất là họ sẽ làm việc trên hai tính năng có kích thước tương tự và sau đó trao đổi để chuẩn bị thử nghiệm.

Tôi nghĩ rằng ý tưởng này có một số mặt tích cực:

• bài kiểm tra được viết bởi ai đó, người có thể xem thêm về việc thực hiện,
• công việc nên được thực hiện nhanh hơn một chút so với lập trình cặp (hai tính năng cùng một lúc),
• cả kiểm tra và mã đều có người chịu trách nhiệm cho nó,
• mã được kiểm tra bởi ít nhất hai người và
• có thể tìm kiếm lỗi trong mã được viết bởi người đang kiểm tra mã của bạn sẽ tạo động lực đặc biệt để viết mã tốt hơn và tránh bị cắt góc.

Có lẽ cũng nên thêm một nhà phát triển khác để xem xét mã giữa phát triển mã và kiểm tra.

Nhược điểm của ý tưởng này là gì? Có phải nó đã được mô tả như một phương pháp không xác định và được sử dụng trong phát triển phần mềm?

Tái bút Tôi không phải là người quản lý dự án chuyên nghiệp, nhưng tôi biết vài điều về quy trình phát triển dự án và biết một vài phương pháp phổ biến nhất - nhưng ý tưởng này không quen thuộc với tôi.

Cách tiếp cận chung của việc sử dụng các cặp để phân chia nỗ lực viết mã sản xuất và viết các bài kiểm tra đơn vị liên quan của nó là không phổ biến. Tôi thậm chí đã từng ghép đôi theo cách này trước đây với thành công tốt đẹp. Tuy nhiên, một ranh giới nghiêm ngặt giữa người viết mã sản xuất và người viết mã kiểm tra có thể không nhất thiết mang lại kết quả.

Khi tôi sử dụng một cách tiếp cận tương tự, cặp đôi bắt đầu bằng cách nói chuyện và nhận được sự hiểu biết chung về vấn đề. Nếu bạn đang sử dụng TDD, trước tiên bạn có thể bắt đầu với một số thử nghiệm cơ bản. Nếu bạn không sử dụng TDD, có lẽ bạn sẽ bắt đầu với định nghĩa phương thức. Từ đây, cả hai thành viên của cặp đều làm việc trên cả mã sản xuất và mã thử nghiệm, với một người tập trung vào từng khía cạnh, nhưng nói về các cách để cải thiện mã sản xuất cũng như mã thử nghiệm đằng sau nó.

Tôi không thấy lợi thế của việc cung cấp cho mỗi cặp hai tính năng. Những gì bạn kết thúc là một cái gì đó tương tự TDD cho một số tính năng và một cái gì đó không dành cho các tính năng khác. Bạn mất tập trung. Bạn không nhận được lợi ích của đánh giá ngang hàng theo thời gian thực. Bạn không nhận được bất kỳ lợi ích chính nào của việc ghép đôi.

Việc thực hành lập trình cặp không phải là về tốc độ, mà là chất lượng. Vì vậy, cố gắng sử dụng một kỹ thuật sửa đổi được thúc đẩy bằng cách đi nhanh hơn đi ngược lại với bản chất. Bằng cách xây dựng phần mềm chất lượng cao hơn thông qua đánh giá mã song song và phát triển thử nghiệm, bạn sẽ tiết kiệm được thời gian xuôi dòng vì có ít nhất hai người có kiến ​​thức về từng thay đổi và bạn đang loại bỏ (hoặc giảm) các chu kỳ chờ để xem xét và kiểm tra ngang hàng.

Vấn đề chính với ý tưởng của bạn là bạn không thể viết bài kiểm tra cho bất kỳ mã nào. Các mã phải được kiểm tra.

Tức là bạn cần có khả năng tiêm giả, tách ra bit bạn muốn kiểm tra, trạng thái truy cập được thay đổi và cần xác nhận, v.v.

Trừ khi bạn gặp may mắn hoặc viết bài kiểm tra trước, nhiều khả năng là viết bài kiểm tra có nghĩa là viết lại mã một chút. Mà, nếu bạn không phải là người viết mã ở nơi đầu tiên, sẽ có nghĩa là trì hoãn, các cuộc họp, tái cấu trúc, v.v.

Vấn đề chính tôi thấy ở đây, ở cấp độ đơn vị, khi tôi viết mã, tôi muốn biên dịch nó, chạy nó và loại bỏ các lỗi rõ ràng nhất ngay lập tức - ngay cả khi mã không đầy đủ và tôi biết đơn vị, tính năng hoặc chức năng là chỉ thực hiện một phần. Và để chạy mã của một đơn vị, tôi cần một số chương trình gọi thực hiện, thường là kiểm tra đơn vị hoặc ít nhất là kiểm tra đơn vị một phần. Đây không nhất thiết là "phong cách TDD của cuốn sách", một bài kiểm tra như vậy có thể được viết sau hoặc trước mã được kiểm tra.

Khi một phiên bản của đơn vị của tôi "hoàn thành tính năng" và không có lỗi, tôi có thể tự mình tìm cách này, thì việc giao nó cho người thứ hai và để cô ấy / anh ấy viết bài kiểm tra đơn vị bổ sung hoặc xem lại mã của tôi . Nhưng đối với tôi, không có ý nghĩa gì khi bàn giao nó ngay khi trình biên dịch không có cảnh báo, điều đó chắc chắn là quá sớm trong trường hợp tôi biết tôi phải giải thích chi tiết về người kiểm tra những thứ không hoạt động "chưa", hoặc sẽ hoạt động khác nhau trong hai giờ kể từ khi tôi vẫn làm việc với đoạn mã đó. Chi phí liên lạc cần thiết cho việc này ở mức độ chi tiết đó sẽ IMHO không được cân bằng bởi các lợi ích.

Vì vậy, có, có một nhà phát triển thứ hai viết bài kiểm tra đơn vị bổ sung có ý nghĩa, nhưng không phải để viết bài kiểm tra đơn vị độc quyền .

Dường như có khả năng xảy ra bất kỳ tình huống nào sau đây - tất cả đều không mong muốn:

Sự nhầm lẫn

Như Ewan đã phác thảo, CUT có thể cần thay đổi để có thể kiểm tra được. Lý do cho sự thay đổi không phải lúc nào cũng rõ ràng đối với nhà phát triển (và có thể gây ra sự bất đồng), đó chính xác là lý do tại sao các bài kiểm tra được viết trước.

Ganh đua

Nhà phát triển A có thể đã hoàn thành mã của họ và muốn thử nghiệm nó. Nhà phát triển B cũng có thể đang phát triển và do đó có thể sẽ giữ lại mã của họ để tham dự các bài kiểm tra đơn vị.

Chuyển ngữ cảnh

Ngay cả khi nhà phát triển B sẵn sàng tạm gác sự phát triển của họ để kiểm tra mã được viết bởi nhà phát triển A - sự thay đổi trong hoạt động phải trả giá.

Nó đã được chấp nhận trong nhiều thập kỷ rằng việc nhân đôi sức mạnh của con người không làm giảm một nửa thời gian phát triển. Xem xét các yếu tố tôi đã nêu ở trên, thật khó để thấy sự sắp xếp này sẽ cải thiện mọi thứ như thế nào.

Khi được sử dụng kết hợp với lập trình cặp và TDD, đây được gọi là Mô hình Ping Pong :

• A viết một bài kiểm tra mới và thấy rằng nó thất bại.
• B thực hiện mã cần thiết để vượt qua bài kiểm tra.
• B viết bài kiểm tra tiếp theo và thấy rằng nó thất bại.
• A thực hiện mã cần thiết để vượt qua bài kiểm tra.

Và như vậy. Tái cấu trúc được thực hiện bất cứ khi nào có nhu cầu bởi bất cứ ai đang lái xe.

Nhưng bạn dường như đề xuất rằng cả hai lập trình viên mã với các máy tính khác nhau. Làm điều đó một cách riêng biệt sẽ đòi hỏi phải có một đặc điểm kỹ thuật mức độ rất thấp. Điều này đi ngược lại các phép đo nhanh. Mọi thay đổi sẽ cần phải được phối hợp. Trong TDD, bạn đang thực hiện cấp độ thấp khi đang di chuyển và nó không phải là vấn đề. Tôi giả định rằng aproach của bạn sẽ cần phải có một số loại bộ xương đã được mã hóa.

Dù sao: Bạn có thể học được rất nhiều bằng cách thử nghiệm các cách làm mới ngay cả khi không hiệu quả 100%. Bạn có thể kiểm tra nó và chia sẻ kinh nghiệm thực tế của bạn

Tôi đến muộn trong bữa tiệc này, nhưng tôi nghĩ rằng tôi có một cái gì đó để thêm.

Có phải nó đã được mô tả như một phương pháp không xác định và được sử dụng trong phát triển phần mềm?

Bạn đang mô tả thử nghiệm ngang hàng .

Giả sử chúng ta có các cặp nhà phát triển.

Ah, lập trình cặp ol 'tốt .

Mỗi cặp chịu trách nhiệm cho một phần của mã. Một từ cặp thực hiện một tính năng (viết mã) và thứ hai viết một bài kiểm tra đơn vị cho nó. Các xét nghiệm được viết sau khi mã. Trong ý tưởng của tôi họ giúp đỡ lẫn nhau, nhưng làm việc khá riêng biệt.

Đó không phải là Lập trình cặp.

Lý tưởng nhất là họ sẽ làm việc trên hai tính năng có kích thước tương tự và sau đó trao đổi để chuẩn bị thử nghiệm.

Đó chắc chắn là thử nghiệm ngang hàng. Đây là một bài báo ACM về nó . Tôi đã làm điều này. Tôi đã từng làm việc khi đó là một phần chính thức của quy trình Đánh giá ngang hàng . Nó hữu ích, nhưng nó chắc chắn không phải là dòng thử nghiệm đầu tiên và chắc chắn nó không phải là Lập trình cặp cổ điển.

Một tên khác cho điều này là Whitebox tests . Mặc dù định nghĩa đó không liên quan đến người thực hiện thử nghiệm nhiều như với thực tế là người thử nghiệm sẽ thấy hoạt động bên trong của thứ họ đang thử nghiệm, trái ngược với thử nghiệm Hộp đen nơi họ chỉ nhìn thấy những gì diễn ra và những gì đi ra ngoài Hộp đen thường là những gì QA làm.

Dòng thử nghiệm đầu tiên nằm chắc chắn trong tay của lập trình viên. Nếu không, bạn không yêu cầu tôi tự kiểm tra mã của mình mà tôi từ chối làm. Tôi đã kiểm tra mã của mình từ khi tôi 10 tuổi. Tôi có thể đã không thử nghiệm với các thử nghiệm đơn vị ưa thích trước đó nhưng mã của tôi đã được thử nghiệm. Nó đã được thử nghiệm mỗi khi tôi chạy nó.

Những gì tôi mong đợi từ một người kiểm tra ngang hàng là các bài kiểm tra thêm vào bài kiểm tra của tôi. Các thử nghiệm làm rõ rất nhiều vấn đề mà đồng nghiệp tìm thấy với mã khi họ xem xét nó. Bằng cách thể hiện những vấn đề này bằng một bài kiểm tra tự động, nó làm cho việc hiểu ý nghĩa của chúng dễ dàng hơn nhiều. Nguyên vẹn, tôi đã có những cuộc trò chuyện kỹ thuật với các đồng nghiệp, những người không thể nhìn thấy điểm tôi đang thực hiện và sau đó nhận ra cách tốt nhất để chỉ cho họ vấn đề là viết bài kiểm tra đơn vị. Đó là thử nghiệm ngang hàng.

Bây giờ nếu bạn muốn cho tôi kiểm tra viết trước khi tôi viết mã của tôi tốt. Không có gì giống như một tài liệu yêu cầu trang trọng đến mức nó biên dịch.

Tôi đã thực hiện DDT (thử nghiệm theo định hướng phát triển, còn gọi là thử nghiệm sau mã), lập trình cặp và TDD tái cấu trúc đỏ-xanh trong vài năm mỗi lần. Để trả lời các xác nhận của bạn từng điểm:

bài kiểm tra được viết bởi ai đó, người có thể xem thêm về việc thực hiện

Người viết bài kiểm tra cần biết thực hiện càng chặt chẽ càng tốt, để viết bài kiểm tra có độ bao phủ tốt mà không cần kiểm tra quá mức. Ví dụ kinh điển về điều này là thử nghiệm với ba đầu vào khi hai đầu vào sẽ chứng minh những gì bạn đang cố gắng thử nghiệm. Mặc dù họ có thể đạt được sự quen thuộc bề mặt với mã khi đọc nó, nhưng họ sẽ không thể hiểu chính xác những gì nhà phát triển ban đầu đã trải qua để đến trạng thái hiện tại. Vì vậy, họ sẽ có sự hiểu biết ít hơn tối ưu về mã.

công việc nên được thực hiện nhanh hơn một chút so với lập trình cặp (hai tính năng cùng một lúc)

Tôi không hiểu tại sao bạn nói vậy. Trong khi ai đó đang viết bài kiểm tra, họ không làm việc trên các tính năng mới. Bạn không thể nhân đôi khả năng làm việc của ai đó bằng cách cho họ hai loại công việc khác nhau. Theo kinh nghiệm của tôi, việc kiểm tra viết thường khó hơn viết mã sản xuất, do đó bạn chắc chắn không thể làm việc hiệu quả và có trách nhiệm trong các thử nghiệm đối với một số mã trong khi viết một tính năng khác.

cả kiểm tra và mã đều có người chịu trách nhiệm cho nó

Đầu tiên, các bài kiểm tra là mã. Đối với mã kiểm tra kinh doanh cũng quan trọng như mã sản xuất, bởi vì nó cho phép doanh nghiệp thay đổi phần mềm mà không sợ hãi. Thứ hai, điều này không khác với một người viết các bài kiểm tra và mã sản xuất, hoặc thậm chí một cặp viết cả hai.

mã được kiểm tra bởi ít nhất hai người

Không, nó chỉ được kiểm tra bởi người viết bài kiểm tra. Trừ khi bạn muốn sử dụng nhiều thời gian hơn để thử nghiệm, trong trường hợp nào tại sao lại dừng ở hai?

có thể tìm kiếm lỗi trong mã được viết bởi người đang kiểm tra mã của bạn sẽ tạo động lực đặc biệt để viết mã tốt hơn và tránh bị cắt góc.

Các nhà phát triển (thậm chí là những người cao cấp) có những ý tưởng rất khác nhau tạo nên mã "tốt". Cắt góc của một người là cách hoàn toàn hợp lệ để nhận mã làm việc càng sớm càng tốt. Đây là một công thức để đổ lỗi và chơi game hệ thống.

TDD tái cấu trúc màu đỏ-xanh ( thực tế là viết một thử nghiệm trước khi viết mã sản xuất, chạy mã, thấy nó thất bại, chỉ sửa đổi mã sản xuất , chạy lại thử nghiệm, nhìn thấy nó thành công, sau đó tái cấu trúc và không bỏ qua hoặc hoán đổi bất kỳ các bước này) và đánh giá mã làm việc.

Tôi nghĩ rằng ý tưởng này có một số mặt tích cực:

Le'ts chạy qua chúng từng cái một.

bài kiểm tra được viết bởi ai đó, người có thể xem thêm về việc thực hiện,

Vì vậy, bạn có nghĩa là nhà phát triển đầu tiên đã dành thời gian để viết một số triển khai, mà anh ta không chắc chắn làm việc. Sau đó, một nhà phát triển khác đến và viết các bài kiểm tra, dựa trên lý lẽ về mã của anh ta, không ai biết liệu nó có đúng hay không, và hy vọng rằng nó mang lại lợi thế chiến thuật so với việc viết các bài kiểm tra chỉ liên quan đến những gì mã phải làm. Nếu việc thực hiện không chính xác, ý kiến ​​của tôi sẽ mang lại sự giúp đỡ bằng không đối với các bài kiểm tra viết.

công việc nên được thực hiện nhanh hơn một chút so với lập trình cặp (hai tính năng cùng một lúc)

Khi cả hai nhà phát triển đã hoàn thành việc phát triển ban đầu của họ, không ai biết liệu mã của họ có đúng hay không. Điều này vẫn còn phải được kiểm tra, không ai có thể đánh dấu bất kỳ ai là xong và không ai có thể dự đoán khi nào chúng sẽ được thực hiện. So sánh điều này với TDD: Bạn viết bài kiểm tra trước, sau đó làm bài kiểm tra thất bại, sau đó chuyển bằng mã. Đó là mã hỗ trợ ngày càng nhiều kịch bản. Đó là chuyển động về phía trước.

Nếu bạn thực hiện chúng song song, mã có thể được sử dụng lại trong cả hai tính năng sẽ được viết hai lần và chi phí cao gấp đôi.

cả kiểm tra và mã đều có người chịu trách nhiệm cho nó,

Nhìn vào quyền sở hữu mã tập thể, như đề xuất của XP. Bạn thậm chí sẽ có nhiều người chịu trách nhiệm về mã. Nếu mục tiêu của bạn là chia sẻ kiến ​​thức giữa các nhà phát triển, tại sao bạn lại cố gắng tách biệt họ?

mã được kiểm tra bởi ít nhất hai người

Với cặp TDD cũng vậy. Khi ghép nối, cả hai người phải đồng ý rằng mã viết là đủ hoặc không viết mã. Nếu điều đó dẫn đến một cuộc chiến, một số người trong đội có vấn đề về bản ngã.

có thể tìm kiếm lỗi trong mã được viết bởi người đang kiểm tra mã của bạn sẽ tạo động lực đặc biệt để viết mã tốt hơn và tránh bị cắt góc.

Tìm kiếm các lỗi ngụ ý rằng tại một số điểm, bạn chấp nhận rằng chúng xâm nhập. Nếu chúng xâm nhập, chúng không được chú ý. Từ chối viết bài kiểm tra trước tiên là cấp giấy phép cho các lỗi để vào.

Góc cắt có thể là vô ý. Đó là những gì lập trình cặp là dành cho. Mỗi thành viên của cặp nên được hướng dẫn với nhiệm vụ không để người kia cắt góc, bởi vì, tất cả chúng ta đều làm điều đó. Điều đó đòi hỏi phải để lại niềm tự hào của bạn trong tủ quần áo và lấy lại khi bạn rời văn phòng. Nếu bạn mong đợi người của bạn sẽ luôn nghiêm khắc, bạn sẽ không xem xét tình huống chung và tự đặt ra thất bại.

XP nói rõ ràng rằng tất cả các thực hành XP được tạo ra để củng cố lẫn nhau bằng cách che đi khuyết điểm của nhau. Bạn không nên lắng nghe những lời chỉ trích về bất kỳ thực hành XP nào tách biệt với những người khác. Không ai thực hành là hoàn hảo, TDD không hoàn hảo, lập trình cặp không hoàn hảo, quyền sở hữu mã tập thể không hoàn hảo, nhưng tất cả đều bao trùm cho nhau.