Bất kỳ công cụ / đề xuất nào về cách bác bỏ đối số chất lượng bảo hiểm mã

Bây giờ tôi biết mọi người có thể xem xét câu hỏi này trùng lặp hoặc hỏi nhiều lần, trong trường hợp đó tôi sẽ đánh giá cao một liên kết đến các câu hỏi có liên quan với câu trả lời cho câu hỏi của tôi.

Gần đây tôi đã bất đồng với một số người về bảo hiểm mã. Tôi có một nhóm người muốn nhóm của chúng tôi bỏ qua việc xem xét phạm vi bảo hiểm mã hoàn toàn dựa trên lập luận rằng phạm vi bảo hiểm 100% không có nghĩa là kiểm tra chất lượng tốt và do đó mã chất lượng tốt.

Tôi đã có thể đẩy lùi bằng cách bán lập luận rằng Bảo hiểm Mã cho tôi biết những gì chưa được kiểm tra chắc chắn và giúp chúng tôi tập trung vào các lĩnh vực đó.

(Phần trên đã được thảo luận theo cách tương tự trong các câu hỏi SO khác như câu hỏi này - /programming/695811/pit thác -of- code - coverage )

Lập luận từ những người này là - sau đó nhóm sẽ phản ứng bằng cách nhanh chóng tạo ra các bài kiểm tra chất lượng thấp và do đó lãng phí thời gian trong khi không thêm chất lượng đáng kể.

Trong khi tôi hiểu quan điểm của họ, tôi đang tìm cách tạo ra một trường hợp mạnh mẽ hơn cho phạm vi bảo hiểm mã bằng cách giới thiệu các công cụ / khung mạnh mẽ hơn, đảm nhiệm các tiêu chí bảo hiểm hơn (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .

Những gì tôi đang tìm kiếm là đề xuất kết hợp các công cụ và quy trình / quy trình bảo hiểm mã như vậy để đi cùng với chúng , điều này có thể giúp tôi chống lại những tranh luận như vậy trong khi cảm thấy thoải mái về đề xuất của mình.

Tôi cũng hoan nghênh mọi bình luận / đề xuất đi kèm dựa trên kinh nghiệm / kiến ​​thức của bạn về cách chống lại lập luận như vậy, bởi vì trong khi chủ quan, phạm vi bảo hiểm mã đã giúp nhóm của tôi có ý thức hơn về chất lượng mã và giá trị của thử nghiệm.

Chỉnh sửa: Để giảm bất kỳ sự nhầm lẫn nào về sự hiểu biết của tôi về điểm yếu của phạm vi bảo hiểm mã điển hình, tôi muốn chỉ ra rằng tôi không đề cập đến Statement Coverage (hoặc các dòng mã được thực thi) (có rất nhiều). Trên thực tế đây là một bài viết hay về mọi thứ sai với nó: http://www.bullseye.com/statementCoverage.html

Tôi đã tìm kiếm nhiều hơn là chỉ tuyên bố hoặc bảo hiểm dòng, đi sâu hơn vào nhiều tiêu chí và cấp độ bảo hiểm.

Xem: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria

Ý tưởng là nếu một công cụ có thể cho chúng tôi biết phạm vi bảo hiểm của chúng tôi dựa trên nhiều tiêu chí thì điều đó sẽ trở thành một đánh giá tự động hợp lý về chất lượng kiểm tra. Tôi không có ý định nói rằng phạm vi bảo hiểm là một đánh giá tốt. Trong thực tế đó là tiền đề của câu hỏi của tôi.

Chỉnh sửa:
Ok, có thể tôi đã chiếu nó một chút quá đột ngột, nhưng bạn có được điểm. Vấn đề là về việc thiết lập các quy trình / chính sách nói chung trên tất cả các nhóm theo cách đồng nhất / nhất quán. Và nỗi sợ nói chung là làm thế nào để bạn đảm bảo chất lượng xét nghiệm, làm thế nào để bạn phân bổ thời gian được đảm bảo mà không có bất kỳ biện pháp nào cho nó. Do đó, tôi thích có một tính năng có thể đo lường được khi sao lưu các quy trình phù hợp và các công cụ phù hợp sẽ cho phép chúng tôi cải thiện chất lượng mã trong khi biết rằng thời gian không bị ép buộc trong các quy trình lãng phí.

EDIT: Cho đến nay những gì tôi có từ các câu trả lời:

• Đánh giá mã phải bao gồm các bài kiểm tra để đảm bảo chất lượng bài kiểm tra
• Chiến lược thử nghiệm đầu tiên giúp tránh các thử nghiệm được viết sau thực tế để tăng tỷ lệ bao phủ%
• Khám phá các công cụ thay thế bao gồm các tiêu chí kiểm tra khác ngoài Tuyên bố / Dòng đơn giản
• Phân tích mã được bảo hiểm / số lỗi được tìm thấy sẽ giúp đánh giá cao tầm quan trọng của bảo hiểm và làm cho một trường hợp tốt hơn
• Quan trọng nhất là tin tưởng đầu vào của Đội để làm điều đúng đắn và đấu tranh cho niềm tin của họ
• Các khối được bảo hiểm / # các bài kiểm tra - Có thể tranh cãi nhưng giữ một số giá trị

Cảm ơn cho câu trả lời tuyệt vời cho đến nay. Tôi thực sự đánh giá cao họ. Chủ đề này là tốt hơn so với giờ động não với sức mạnh đó.

Theo kinh nghiệm của tôi, bảo hiểm mã cũng hữu ích như bạn thực hiện . Nếu bạn viết các bài kiểm tra tốt bao gồm tất cả các trường hợp của bạn, thì việc vượt qua các bài kiểm tra đó có nghĩa là bạn đã đáp ứng yêu cầu của mình. Trên thực tế, đó là ý tưởng chính xác mà Test Driven Development sử dụng. Bạn viết các bài kiểm tra trước mã mà không biết gì về việc thực hiện (Đôi khi điều này có nghĩa là một nhóm khác hoàn toàn viết các bài kiểm tra). Các thử nghiệm này được thiết lập để xác minh rằng sản phẩm cuối cùng thực hiện mọi thứ mà thông số kỹ thuật của bạn đã thực hiện và THÌ bạn viết mã tối thiểu để vượt qua các thử nghiệm đó.

Rõ ràng, vấn đề ở đây là nếu các thử nghiệm của bạn không đủ mạnh, bạn sẽ bỏ lỡ các trường hợp cạnh hoặc các vấn đề không lường trước và viết mã không thực sự đáp ứng các thông số kỹ thuật của bạn. Nếu bạn thực sự bắt đầu sử dụng các bài kiểm tra để xác minh mã của mình, thì viết bài kiểm tra tốt là một điều cần thiết tuyệt đối hoặc bạn thực sự lãng phí thời gian của mình.

Tôi muốn chỉnh sửa câu trả lời ở đây vì tôi nhận ra rằng nó không thực sự trả lời câu hỏi của bạn. Tôi sẽ xem bài viết wiki đó để thấy một số lợi ích đã nêu của TDD. Nó thực sự phụ thuộc vào cách tổ chức của bạn hoạt động tốt nhất, nhưng TDD chắc chắn là thứ được sử dụng trong ngành.

Off đầu tiên, người ta làm người bênh vực bảo hiểm 100%:

Hầu hết các nhà phát triển xem ... "Bảo hiểm tuyên bố 100%" là đầy đủ. Đây là một khởi đầu tốt, nhưng hầu như không đủ. Id tiêu chuẩn bảo hiểm tốt hơn để đáp ứng cái được gọi là "Bảo hiểm chi nhánh 100%", ...

Steve McConnell, Code Complete , Chương 22: Kiểm thử nhà phát triển.

Như bạn và những người khác đã đề cập, bảo hiểm mã chỉ vì mục đích bảo hiểm không có khả năng thực hiện được nhiều. Nhưng nếu bạn không thể thực hiện một dòng mã, tại sao nó được viết?

Tôi khuyên bạn nên giải quyết tranh luận bằng cách thu thập và phân tích dữ liệu về các dự án của riêng bạn.

Để thu thập dữ liệu, cá nhân tôi sử dụng các công cụ sau:

• JaCoCo và Eclipse liên quan Plugin EclEmma để đo mã số bảo hiểm.
• Ant script để xây dựng tự động, thử nghiệm và báo cáo.
• Jenkins cho các bản dựng liên tục - mọi thay đổi trong kiểm soát nguồn sẽ kích hoạt bản dựng tự động
• Plugin JaCoCo cho Jenkins - nắm bắt các số liệu bảo hiểm cho từng bản dựng và xu hướng biểu đồ. Cũng cho phép các định nghĩa về ngưỡng bảo hiểm cho mỗi dự án ảnh hưởng đến sức khỏe của công trình.
• Bugzilla để theo dõi lỗi.

Khi bạn đã có (hoặc một cái gì đó tương tự), bạn có thể bắt đầu xem xét dữ liệu của mình kỹ hơn:

• Có nhiều lỗi được tìm thấy trong các dự án được bảo hiểm kém?
• Có nhiều lỗi được tìm thấy trong các lớp / phương thức được bảo hiểm kém?
• Vân vân.

Tôi hy vọng rằng dữ liệu của bạn sẽ hỗ trợ vị trí của bạn trong phạm vi bảo hiểm mã; đó chắc chắn là kinh nghiệm của tôi Tuy nhiên, nếu không, thì có lẽ tổ chức của bạn có thể thành công với các tiêu chuẩn bảo hiểm mã thấp hơn bạn muốn. Hoặc có thể bài kiểm tra của bạn không tốt lắm. Nhiệm vụ này hy vọng sẽ tập trung nỗ lực vào việc sản xuất phần mềm với ít lỗi hơn, bất kể độ phân giải của sự bất đồng về phạm vi bảo hiểm mã.

Lập luận từ những người này là - nhóm sẽ phản ứng bằng cách nhanh chóng tạo ra các bài kiểm tra chất lượng thấp và do đó lãng phí thời gian trong khi không thêm chất lượng đáng kể.

Đây là một vấn đề của niềm tin , không phải công cụ .

Hỏi họ tại sao, nếu họ thực sự tin vào tuyên bố đó, họ sẽ tin tưởng nhóm viết bất kỳ mã nào?

Ok, có thể tôi đã chiếu nó một chút quá kịch tính, nhưng bạn có được điểm. Vấn đề là về việc thiết lập các quy trình / chính sách nói chung trên tất cả các nhóm theo cách đồng nhất / nhất quán.

Tôi nghĩ đó là vấn đề. Các nhà phát triển không quan tâm (và thường vì lý do tuyệt vời) về các chính sách nhất quán hoặc toàn cầu và muốn tự do thực hiện những gì họ cho là đúng hơn là tuân thủ chính sách của công ty.

Điều này là hợp lý trừ khi bạn chứng minh rằng các quy trình và biện pháp toàn cầu có giá trị và ảnh hưởng tích cực đến chất lượng và tốc độ phát triển.

Dòng thời gian thông thường:

1. dev: hey, nhìn kìa - Tôi đã thêm số liệu bảo hiểm mã vào bảng điều khiển của chúng tôi, điều đó có tuyệt không?
2. quản lý: chắc chắn, hãy thêm các mục tiêu bắt buộc và tuân thủ các mục tiêu đó
3. dev: đừng bận tâm, bảo hiểm mã là ngu ngốc và vô dụng, hãy bỏ nó đi

Theo kinh nghiệm của tôi, có một vài điều kết hợp với phạm vi bảo hiểm mã để làm cho số liệu có giá trị:

Nhận xét mã

Nếu bạn có thể đưa các bài kiểm tra xấu trở lại cho nhà phát triển, điều đó có thể giúp hạn chế số lượng các bài kiểm tra tồi đang cung cấp phạm vi bảo hiểm vô nghĩa này.

Theo dõi lỗi

Nếu bạn có một loạt phạm vi bảo hiểm mã trên một mô-đun, nhưng vẫn gặp nhiều lỗi / nghiêm trọng trong khu vực đó, thì nó có thể chỉ ra vấn đề mà nhà phát triển cần cải thiện với các thử nghiệm của họ.

Chủ nghĩa thực dụng

Không ai sẽ đạt được 100% với các bài kiểm tra tốt về mã không tầm thường. Nếu bạn là trưởng nhóm nhìn vào phạm vi bảo hiểm mã, nhưng thay vì nói "chúng tôi cần phải đạt N%!" bạn xác định các khoảng trống và yêu cầu mọi người "cải thiện phạm vi bảo hiểm trong mô-đun X" để đạt được mục tiêu của bạn mà không cung cấp cho mọi người cơ hội để chơi trò chơi hệ thống.

Các khối được bảo hiểm / # các bài kiểm tra

Hầu hết các công cụ bảo hiểm mã liệt kê các khối được bao phủ so với các khối không được bảo hiểm. Kết hợp điều này với số lượng thử nghiệm thực tế cho phép bạn có được một số liệu cho biết các thử nghiệm 'rộng' như thế nào, cho thấy các thử nghiệm xấu hoặc thiết kế được ghép nối. Điều này hữu ích hơn khi một đồng bằng từ lần chạy nước rút này đến lần chạy nước rút khác, nhưng ý tưởng là như nhau - kết hợp phạm vi bảo hiểm mã với các số liệu khác để hiểu rõ hơn.

Đây là 2 xu của tôi.

Có nhiều thực tiễn đã nhận được rất nhiều sự chú ý gần đây bởi vì chúng có thể mang lại lợi ích cho việc phát triển phần mềm. Tuy nhiên, một số nhà phát triển áp dụng những thực tiễn đó một cách mù quáng: họ tin rằng việc áp dụng một phương pháp cũng giống như thực hiện một thuật toán và sau khi thực hiện đúng các bước, người ta sẽ nhận được kết quả mong muốn.

Vài ví dụ:

• Viết bài kiểm tra đơn vị với độ bao phủ mã 100% và bạn sẽ có chất lượng mã tốt hơn.
• Áp dụng TDD một cách có hệ thống và bạn sẽ có được thiết kế tốt hơn.
• Làm lập trình cặp và bạn sẽ cải thiện chất lượng mã và giảm thời gian phát triển.

Tôi nghĩ vấn đề cơ bản với các tuyên bố trên là con người không phải là máy tính và viết phần mềm không giống như thực hiện một thuật toán.

Vì vậy, các tuyên bố trên có chứa một số sự thật nhưng đơn giản hóa mọi thứ quá nhiều, ví dụ:

• Kiểm thử đơn vị bắt được rất nhiều lỗi và phạm vi bảo hiểm mã cho biết phần nào của mã được kiểm tra, nhưng kiểm tra những thứ tầm thường là vô ích. Ví dụ: nếu bằng cách nhấp vào nút, hộp thoại tương ứng sẽ mở ra, toàn bộ logic gửi sự kiện nút đến thành phần mở hộp thoại có thể được kiểm tra bằng một thử nghiệm thủ công đơn giản (nhấp vào nút): nó có trả cho đơn vị không kiểm tra logic này?
• Mặc dù TDD là một công cụ thiết kế tốt, nhưng nó không hoạt động tốt nếu nhà phát triển hiểu biết kém về miền vấn đề (xem ví dụ bài đăng nổi tiếng này ).
• Lập trình cặp có hiệu quả nếu hai nhà phát triển có thể làm việc cùng nhau, nếu không thì đó là một thảm họa. Ngoài ra, các nhà phát triển có kinh nghiệm có thể thích thảo luận ngắn gọn về các vấn đề quan trọng nhất và sau đó viết mã riêng: dành nhiều giờ để thảo luận về nhiều chi tiết mà cả hai đều biết có thể vừa nhàm chán vừa lãng phí thời gian.

Quay trở lại bảo hiểm mã.

Tôi đã có thể đẩy lùi bằng cách bán lập luận rằng Bảo hiểm Mã cho tôi biết những gì chưa được kiểm tra chắc chắn và giúp chúng tôi tập trung vào các lĩnh vực đó.

Tôi nghĩ bạn phải đánh giá theo từng trường hợp nếu nó có giá trị bảo hiểm 100% cho một mô-đun nhất định.

Liệu mô-đun thực hiện một số tính toán rất quan trọng và phức tạp? Sau đó, tôi muốn kiểm tra từng dòng mã nhưng cũng viết các bài kiểm tra đơn vị có ý nghĩa (các bài kiểm tra đơn vị có ý nghĩa trong miền đó).

Mô-đun có thực hiện một số nhiệm vụ quan trọng nhưng đơn giản như mở cửa sổ trợ giúp khi nhấp vào nút không? Một bài kiểm tra thủ công có thể sẽ hiệu quả hơn.

Lập luận từ những người này là - sau đó nhóm sẽ phản ứng bằng cách nhanh chóng tạo ra các bài kiểm tra chất lượng thấp và do đó lãng phí thời gian trong khi không thêm chất lượng đáng kể.

Theo tôi họ đúng: bạn không thể thực thi chất lượng mã bằng cách chỉ yêu cầu bảo hiểm mã 100%. Thêm nhiều công cụ để tính toán phạm vi bảo hiểm và thống kê cũng sẽ không giúp ích. Thay vào đó, bạn nên thảo luận về phần nào của mã nhạy hơn và nên được kiểm tra rộng rãi và phần nào ít bị lỗi hơn (theo nghĩa là lỗi có thể được phát hiện và sửa dễ dàng hơn nhiều mà không cần sử dụng kiểm tra đơn vị).

Nếu bạn đẩy phạm vi bảo hiểm mã 100% lên các nhà phát triển, một số người sẽ bắt đầu viết các bài kiểm tra đơn vị ngớ ngẩn để thực hiện nghĩa vụ của họ thay vì cố gắng viết các bài kiểm tra hợp lý.

Làm thế nào để bạn phân bổ thời gian được đảm bảo mà không có bất kỳ biện pháp nào cho nó

Có thể đó là một ảo ảnh mà bạn có thể đo lường trí thông minh và phán đoán của con người. Nếu bạn có đồng nghiệp giỏi và bạn tin tưởng vào phán đoán của họ, bạn có thể chấp nhận khi họ nói với bạn "đối với mô-đun này, việc tăng phạm vi bảo hiểm sẽ mang lại rất ít lợi ích. Vì vậy, chúng ta đừng dành thời gian cho nó" hoặc "cho mô-đun này mà chúng tôi cần càng nhiều bảo hiểm càng tốt, chúng tôi cần thêm một tuần để thực hiện các bài kiểm tra đơn vị hợp lý. ".

Vì vậy (một lần nữa, đây là 2 xu của tôi): đừng cố tìm quy trình và đặt các tham số như phạm vi bảo hiểm mã phải phù hợp với tất cả các nhóm, cho tất cả các dự án và cho tất cả các mô-đun. Tìm thấy một quá trình chung như vậy là một ảo ảnh và tôi tin rằng khi bạn đã tìm thấy nó, nó sẽ không tối ưu.

"nhóm sẽ phản ứng bằng cách nhanh chóng tạo ra các thử nghiệm chất lượng thấp và do đó lãng phí thời gian trong khi không thêm chất lượng đáng kể"

Đây là một rủi ro thực sự, không chỉ là lý thuyết.

Quá tải mã một mình là một số liệu rối loạn chức năng. Tôi đã học bài học đó một cách khó khăn. Một lần, tôi nhấn mạnh nó mà không có sự cân bằng giữa các số liệu hoặc thực tiễn. Hàng trăm bài kiểm tra bắt và che dấu các ngoại lệ, và không có xác nhận là một điều xấu xí.

"đề xuất kết hợp các công cụ và quy trình / quy trình bảo hiểm mã như vậy để đi cùng với chúng"

Ngoài tất cả các đề xuất khác, có một kỹ thuật tự động hóa có thể đánh giá chất lượng của các bài kiểm tra: kiểm tra đột biến ( http://en.wikipedia.org/wiki/Muting_testing ). Đối với mã Java, PIT ( http://pitest.org/ ) hoạt động và đó là công cụ kiểm tra đột biến đầu tiên tôi gặp phải.

Như bạn lưu ý, việc thiếu bảo hiểm mã có thể dễ dàng được xác định là rủi ro chất lượng phần mềm. Tôi dạy rằng bảo hiểm mã là điều kiện cần, nhưng không đủ, cho chất lượng phần mềm. Chúng ta phải thực hiện một cách tiếp cận cân bằng điểm để quản lý chất lượng phần mềm.

Bảo hiểm mã chắc chắn không phải là bằng chứng của các bài kiểm tra đơn vị tốt, trong đó chúng là chính xác.

Nhưng trừ khi họ có thể cung cấp một cách để chứng minh rằng tất cả các bài kiểm tra đơn vị đều tốt (đối với bất kỳ định nghĩa tốt nào họ có thể đưa ra) thì đây thực sự là một điểm câm.

Tôi luôn thấy rằng phạm vi bảo hiểm mã dễ bị ảnh hưởng bởi Hiệu ứng Hawthorne . Điều này khiến tôi phải hỏi "tại sao chúng ta có bất kỳ số liệu phần mềm nào?" và câu trả lời thường là cung cấp một số hiểu biết cao về tình trạng hiện tại của dự án, đại loại như:

"chúng ta gần đến mức nào?"

"chất lượng của hệ thống này như thế nào?"

"những mô-đun này phức tạp đến mức nào?"

Than ôi, sẽ không bao giờ có một số liệu duy nhất có thể cho bạn biết dự án tốt hay xấu như thế nào và bất kỳ nỗ lực nào để rút ra ý nghĩa đó từ một số duy nhất sẽ nhất thiết phải đơn giản hóa. Mặc dù các số liệu là tất cả về dữ liệu, nhưng việc giải thích ý nghĩa của chúng là một nhiệm vụ tâm lý / cảm xúc nhiều hơn và vì vậy có lẽ không thể được áp dụng chung cho các nhóm có thành phần khác nhau hoặc các vấn đề thuộc các lĩnh vực khác nhau.

Trong trường hợp bảo hiểm tôi nghĩ rằng nó thường được sử dụng như một proxy cho chất lượng mã, mặc dù là một điều thô thiển. Và vấn đề thực sự là nó tập trung vào một chủ đề cực kỳ phức tạp thành một số nguyên duy nhất trong khoảng từ 0 đến 100, tất nhiên sẽ được sử dụng để thúc đẩy công việc có ích trong một nhiệm vụ bất tận để đạt được phạm vi bao phủ 100%. Những người như Bob Martin sẽ nói rằng bảo hiểm 100% là mục tiêu nghiêm túc duy nhất và tôi có thể hiểu tại sao lại như vậy, bởi vì bất cứ điều gì khác chỉ có vẻ độc đoán.

Tất nhiên, có rất nhiều cách để có được phạm vi bảo hiểm mà thực sự không giúp tôi hiểu được về cơ sở mã - ví dụ: có đáng để kiểm tra toString () không? Điều gì về getters và setters cho các đối tượng bất biến? Một nhóm chỉ có rất nhiều nỗ lực để áp dụng trong một thời gian cố định và thời gian đó dường như luôn luôn ít hơn thời gian cần thiết để thực hiện một công việc hoàn hảo, vì vậy, nếu không có lịch trình hoàn hảo, chúng tôi phải thực hiện với xấp xỉ.

Một số liệu tôi thấy hữu ích trong việc tạo ra các xấp xỉ tốt là Crap4J . Hiện tại nó không còn tồn tại nhưng bạn có thể dễ dàng chuyển / thực hiện nó. Crap4J cố gắng liên kết phạm vi bảo hiểm mã với độ phức tạp chu kỳ bằng cách ngụ ý rằng mã phức tạp hơn (ifs, whiles, fors, v.v.) nên có phạm vi kiểm tra cao hơn. Đối với tôi ý tưởng đơn giản này thực sự vang lên. Tôi muốn hiểu nơi nào có rủi ro trong cơ sở mã của mình và một rủi ro thực sự quan trọng là sự phức tạp. Vì vậy, bằng cách sử dụng công cụ này, tôi có thể nhanh chóng đánh giá mức độ rủi ro của cơ sở mã của mình. Nếu nó phức tạp, phạm vi bảo hiểm tốt hơn nên đi lên. Nếu không, tôi không cần lãng phí thời gian để cố gắng bảo vệ mọi dòng mã.

Tất nhiên đây chỉ là một số liệu và YMMV. Bạn phải dành thời gian với nó để hiểu nếu nó sẽ có ý nghĩa với bạn và nếu nó sẽ mang lại cho nhóm của bạn một cảm giác hợp lý có thể mò mẫm về nơi dự án đang ở.

Tôi sẽ không nói rằng quay trở lại và bao gồm mã hiện tại là con đường tốt nhất phía trước. Tôi sẽ lập luận rằng việc viết các bài kiểm tra bao gồm bất kỳ mã mới nào bạn viết và bất kỳ mã nào bạn thay đổi đều có ý nghĩa.

Khi tìm thấy lỗi, hãy viết một bài kiểm tra thất bại vì lỗi đó và sửa lỗi để bài kiểm tra chuyển sang màu xanh. Đưa vào các ý kiến ​​của bài kiểm tra xem nó viết lỗi gì.

Mục tiêu là có đủ tự tin trong các thử nghiệm của bạn để bạn có thể thay đổi mà không cần quan tâm đến các tác dụng phụ không mong muốn. Kiểm tra Làm việc hiệu quả với Mã kế thừa để có bản tóm tắt tốt về các cách tiếp cận để thuần hóa mã chưa được kiểm tra.