Thử nghiệm đơn vị có thể được thêm thành công vào một dự án sản xuất hiện có? Nếu vậy, làm thế nào và nó có đáng không?

Tôi mạnh mẽ xem xét việc thêm thử nghiệm đơn vị vào một dự án hiện có đang được sản xuất. Nó đã được bắt đầu từ 18 tháng trước khi tôi thực sự có thể thấy bất kỳ lợi ích nào của TDD (cọ mặt) , vì vậy bây giờ nó là một giải pháp khá lớn với một số dự án và tôi không biết nên bắt đầu thử nghiệm đơn vị ở đâu. Điều khiến tôi cân nhắc điều này là đôi khi một lỗi cũ dường như xuất hiện trở lại hoặc một lỗi được kiểm tra là đã sửa mà không thực sự được sửa. Kiểm tra đơn vị sẽ làm giảm hoặc ngăn chặn những vấn đề này xảy ra.

Bằng cách đọc các câu hỏi tương tự trên SO, tôi đã thấy các đề xuất như bắt đầu từ trình theo dõi lỗi và viết trường hợp kiểm tra cho từng lỗi để ngăn hồi quy. Tuy nhiên, tôi lo ngại rằng cuối cùng tôi sẽ bỏ lỡ bức tranh lớn và cuối cùng lại bỏ lỡ các bài kiểm tra cơ bản sẽ được đưa vào nếu tôi sử dụng TDD ngay từ đầu.

Có bất kỳ quy trình / bước nào cần được tuân thủ để đảm bảo rằng một giải pháp hiện có được kiểm tra đúng đơn vị và không chỉ được đưa vào? Làm cách nào tôi có thể đảm bảo rằng các bài kiểm tra có chất lượng tốt và không chỉ là trường hợp của bất kỳ bài kiểm tra nào tốt hơn không có bài kiểm tra nào .

Vì vậy, tôi đoán những gì tôi cũng đang hỏi là;

• Có đáng nỗ lực cho một giải pháp hiện có trong sản xuất không?
• Nó sẽ tốt hơn để bỏ qua thử nghiệm cho dự án này và thêm nó trong một lần viết lại có thể trong tương lai?
• Điều gì sẽ có lợi hơn; dành một vài tuần để thêm các bài kiểm tra hoặc một vài tuần thêm chức năng?

(Rõ ràng câu trả lời cho điểm thứ ba hoàn toàn phụ thuộc vào việc bạn đang nói chuyện với quản lý hay nhà phát triển)

Lý do cho tiền thưởng

Thêm một tiền thưởng để thử và thu hút một loạt các câu trả lời rộng hơn không chỉ xác nhận sự nghi ngờ hiện tại của tôi rằng đó là một điều tốt để làm, mà còn một số lý do tốt để chống lại.

Tôi đang đặt mục tiêu viết câu hỏi này sau này với những ưu và nhược điểm để thử và cho quản lý thấy rằng đáng để dành hàng giờ đồng hồ để chuyển sự phát triển của sản phẩm trong tương lai sang TDD. Tôi muốn tiếp cận thử thách này và phát triển lý luận của mình mà không có quan điểm thiên vị của riêng tôi.

Tôi đã giới thiệu các bài kiểm tra đơn vị cho các cơ sở mã mà trước đây không có. Dự án lớn cuối cùng tôi tham gia với nơi tôi đã thực hiện sản phẩm này đã được sản xuất với các bài kiểm tra đơn vị bằng không khi tôi đến nhóm. Khi tôi rời đi - 2 năm sau - chúng tôi đã có hơn 4500 bài kiểm tra đạt năng suất bảo hiểm khoảng 33% trong cơ sở mã với 230 000 + LỘC sản xuất (ứng dụng Win-Forms tài chính theo thời gian thực). Điều đó nghe có vẻ thấp, nhưng kết quả là một sự cải thiện đáng kể về chất lượng mã và tỷ lệ lỗi - cộng với tinh thần và lợi nhuận được cải thiện.

Nó có thể được thực hiện khi bạn có cả sự hiểu biết và cam kết chính xác từ các bên liên quan.

Trước hết, điều quan trọng là phải hiểu rằng kiểm tra đơn vị là một kỹ năng trong chính nó. Bạn có thể là một lập trình viên rất năng suất theo tiêu chuẩn "thông thường" và vẫn phải vật lộn để viết các bài kiểm tra đơn vị theo cách mở rộng trong một dự án lớn hơn.

Ngoài ra, và đặc biệt cho trường hợp của bạn, thêm các bài kiểm tra đơn vị vào cơ sở mã hiện có mà không có bài kiểm tra nào cũng là một kỹ năng chuyên biệt. Trừ khi bạn hoặc ai đó trong nhóm của bạn có kinh nghiệm thành công trong việc giới thiệu các bài kiểm tra đơn vị cho cơ sở mã hiện có, tôi sẽ nói rằng việc đọc sách của Feather là một yêu cầu (không phải là tùy chọn hoặc khuyến nghị mạnh mẽ).

Thực hiện chuyển đổi để kiểm tra đơn vị mã của bạn là một sự đầu tư vào con người và kỹ năng cũng giống như chất lượng của cơ sở mã. Hiểu điều này là rất quan trọng về tư duy và quản lý kỳ vọng.

Bây giờ, cho ý kiến ​​và câu hỏi của bạn:

Tuy nhiên, tôi lo ngại rằng cuối cùng tôi sẽ bỏ lỡ bức tranh lớn và cuối cùng lại bỏ lỡ các bài kiểm tra cơ bản sẽ được đưa vào nếu tôi sử dụng TDD ngay từ đầu.

Câu trả lời ngắn: Có, bạn sẽ bỏ lỡ các bài kiểm tra và vâng, ban đầu chúng có thể không giống như những gì chúng sẽ có trong tình huống trường xanh.

Câu trả lời sâu hơn là đây: Không thành vấn đề. Bạn bắt đầu không có bài kiểm tra. Bắt đầu thêm các bài kiểm tra và tái cấu trúc khi bạn đi. Khi mức độ kỹ năng trở nên tốt hơn, hãy bắt đầu nâng cao thanh cho tất cả các mã mới được viết vào dự án của bạn. Tiếp tục cải thiện vv ...

Bây giờ, đọc ở giữa các dòng ở đây tôi có ấn tượng rằng điều này xuất phát từ suy nghĩ "sự hoàn hảo như một cái cớ để không hành động". Một suy nghĩ tốt hơn là tập trung vào sự tự tin. Vì vậy, vì bạn có thể không biết làm thế nào để làm điều đó, bạn sẽ tìm ra làm thế nào để bạn đi và điền vào chỗ trống. Do đó, không có lý do để lo lắng.

Một lần nữa, nó là một kỹ năng. Bạn không thể đi từ các bài kiểm tra 0 đến hoàn hảo TDD trong một "quy trình" hoặc "từng bước" cách tiếp cận sách nấu ăn theo kiểu tuyến tính. Nó sẽ là một quá trình. Kỳ vọng của bạn phải được thực hiện dần dần và tăng dần và cải thiện. Không có viên thuốc kỳ diệu.

Tin tốt là khi nhiều tháng (và thậm chí nhiều năm) trôi qua, mã của bạn sẽ dần bắt đầu trở thành mã "được kiểm tra tốt" và được kiểm tra tốt.

Như một lưu ý phụ. Bạn sẽ thấy rằng trở ngại chính trong việc giới thiệu các bài kiểm tra đơn vị trong một cơ sở mã cũ là thiếu sự gắn kết và phụ thuộc quá mức. Do đó, bạn có thể sẽ thấy rằng kỹ năng quan trọng nhất sẽ trở thành cách phá vỡ các phụ thuộc hiện có và mã tách riêng, thay vì tự viết các bài kiểm tra đơn vị thực tế.

Có bất kỳ quy trình / bước nào cần được tuân thủ để đảm bảo rằng một giải pháp hiện có được kiểm tra đúng đơn vị và không chỉ được đưa vào?

Trừ khi bạn đã có nó, hãy thiết lập một máy chủ xây dựng và thiết lập một bản dựng tích hợp liên tục chạy trên mọi đăng ký bao gồm tất cả các bài kiểm tra đơn vị có độ bao phủ mã.

Huấn luyện người của bạn.

Bắt đầu ở đâu đó và bắt đầu thêm các bài kiểm tra trong khi bạn tiến bộ từ quan điểm của khách hàng (xem bên dưới).

Sử dụng phạm vi bảo hiểm mã làm tài liệu tham khảo hướng dẫn về số lượng cơ sở mã sản xuất của bạn đang được thử nghiệm.

Thời gian xây dựng phải luôn NHANH CHÓNG. Nếu thời gian xây dựng của bạn chậm, kỹ năng kiểm tra đơn vị của bạn sẽ bị chậm trễ. Tìm các thử nghiệm chậm và cải thiện chúng (tách mã sản xuất và thử nghiệm riêng rẽ). Được viết tốt, bạn nên dễ dàng có thể có hàng ngàn bài kiểm tra đơn vị và vẫn hoàn thành bản dựng trong vòng dưới 10 phút (~ 1 vài ms / bài kiểm tra là một hướng dẫn tốt nhưng rất thô sơ, một số trường hợp ngoại lệ có thể áp dụng như mã sử dụng phản xạ, v.v. ).

Kiểm tra và thích nghi.

Làm cách nào tôi có thể đảm bảo rằng các bài kiểm tra có chất lượng tốt và không chỉ là trường hợp của bất kỳ bài kiểm tra nào tốt hơn không có bài kiểm tra nào.

Đánh giá của riêng bạn phải là nguồn thực tế chính của bạn. Không có số liệu có thể thay thế kỹ năng.

Nếu bạn không có kinh nghiệm hoặc phán xét đó, hãy xem xét ký hợp đồng với ai đó.

Hai chỉ số phụ thô là tổng độ bao phủ mã và tốc độ xây dựng.

Có đáng nỗ lực cho một giải pháp hiện có trong sản xuất không?

Đúng. Phần lớn số tiền chi cho một hệ thống hoặc giải pháp được xây dựng tùy chỉnh được chi sau khi nó được đưa vào sản xuất. Và đầu tư vào chất lượng, con người và kỹ năng không bao giờ nên lỗi thời.

Nó sẽ tốt hơn để bỏ qua thử nghiệm cho dự án này và thêm nó trong một lần viết lại có thể trong tương lai?

Bạn sẽ phải cân nhắc, không chỉ đầu tư vào con người và kỹ năng, mà quan trọng nhất là tổng chi phí sở hữu và thời gian sống dự kiến ​​của hệ thống.

Câu trả lời cá nhân của tôi sẽ là "có tất nhiên" trong phần lớn các trường hợp bởi vì tôi biết nó tốt hơn rất nhiều, nhưng tôi nhận ra rằng có thể có ngoại lệ.

Điều gì sẽ có lợi hơn; dành một vài tuần để thêm các bài kiểm tra hoặc một vài tuần thêm chức năng?

Cũng không. Cách tiếp cận của bạn nên là thêm các bài kiểm tra vào cơ sở mã của bạn KHI bạn đang tiến bộ về chức năng.

Một lần nữa, đó là một sự đầu tư vào con người, kỹ năng VÀ chất lượng của cơ sở mã và do đó nó sẽ đòi hỏi thời gian. Các thành viên trong nhóm cần học cách phá vỡ sự phụ thuộc, viết bài kiểm tra đơn vị, tìm hiểu thói quen mới, nâng cao kỷ luật và nhận thức về chất lượng, cách thiết kế phần mềm tốt hơn, v.v. Điều quan trọng là phải hiểu rằng khi bạn bắt đầu thêm bài kiểm tra, các thành viên trong nhóm của bạn có thể không có những kỹ năng này ở mức độ cần thiết để phương pháp đó thành công, vì vậy, dừng tiến độ để dành toàn bộ thời gian để thêm nhiều bài kiểm tra đơn giản là sẽ không hiệu quả.

Ngoài ra, việc thêm các thử nghiệm đơn vị vào một cơ sở mã hiện có của bất kỳ quy mô dự án lớn nào là một công việc LỚN đòi hỏi sự cam kết và kiên trì. Bạn không thể thay đổi một cái gì đó cơ bản, mong đợi rất nhiều học hỏi trên đường và yêu cầu nhà tài trợ của bạn không mong đợi bất kỳ ROI nào bằng cách tạm dừng dòng giá trị doanh nghiệp. Điều đó sẽ không bay, và thẳng thắn là không nên.

Thứ ba, bạn muốn thấm nhuần các giá trị tập trung kinh doanh trong nhóm của bạn. Chất lượng không bao giờ đến với chi phí của khách hàng và bạn không thể đi nhanh mà không có chất lượng. Ngoài ra, khách hàng đang sống trong một thế giới đang thay đổi, và công việc của bạn là giúp anh ta dễ dàng thích nghi hơn. Liên kết khách hàng đòi hỏi cả chất lượng và dòng chảy của giá trị kinh doanh.

Những gì bạn đang làm là trả hết nợ kỹ thuật. Và bạn đang làm như vậy trong khi vẫn phục vụ khách hàng của bạn luôn thay đổi nhu cầu. Dần dần khi nợ được trả, tình hình được cải thiện, và dễ dàng phục vụ khách hàng tốt hơn và mang lại nhiều giá trị hơn. V.v. Động lực tích cực này là những gì bạn nên hướng tới vì nó nhấn mạnh các nguyên tắc của tốc độ bền vững và sẽ duy trì và cải thiện đạo đức - cho cả nhóm phát triển, khách hàng và các bên liên quan của bạn.

Mong rằng sẽ giúp

• Có đáng nỗ lực cho một giải pháp hiện có trong sản xuất không?

Đúng!

• Nó sẽ tốt hơn để bỏ qua thử nghiệm cho dự án này và thêm nó trong một lần viết lại có thể trong tương lai?

Không!

• Điều gì sẽ có lợi hơn; dành một vài tuần để thêm các bài kiểm tra hoặc một vài tuần thêm chức năng?

Thêm thử nghiệm (đặc biệt là thử nghiệm tự động) giúp dự án hoạt động trong tương lai dễ dàng hơn nhiều và điều đó giúp giảm thiểu đáng kể việc bạn sẽ gửi các vấn đề ngu ngốc cho người dùng.

Các thử nghiệm để đưa vào một ưu tiên là những thử nghiệm kiểm tra xem những gì bạn tin rằng giao diện công khai với mã của bạn (và mỗi mô-đun trong đó) có hoạt động theo cách bạn nghĩ hay không. Nếu bạn có thể, hãy cố gắng tạo ra từng chế độ thất bại bị cô lập mà các mô-đun mã của bạn nên có (lưu ý rằng điều này có thể không tầm thường và bạn nên cẩn thận không kiểm tra quá cẩn thận cách mọi thứ thất bại, ví dụ: bạn không thực sự muốn để làm những việc như đếm số lượng thông điệp tường trình được tạo ra khi thất bại, vì xác minh rằng nó được ghi lại là đủ).

Sau đó, kiểm tra từng lỗi hiện tại trong cơ sở dữ liệu lỗi của bạn để tạo ra chính xác lỗi và sẽ vượt qua khi lỗi được khắc phục. Sau đó sửa những lỗi đó! :-)

Sẽ mất thời gian trước để thêm các bài kiểm tra, nhưng bạn được trả lại nhiều lần ở phần cuối vì mã của bạn có chất lượng cao hơn nhiều. Điều đó rất quan trọng khi bạn đang cố gắng gửi một phiên bản mới hoặc tiến hành bảo trì.

Vấn đề với các bài kiểm tra đơn vị trang bị thêm là bạn sẽ nhận ra rằng bạn đã không nghĩ đến việc tiêm một phụ thuộc ở đây hoặc sử dụng một giao diện ở đó, và không lâu sau bạn sẽ viết lại toàn bộ thành phần. Nếu bạn có thời gian để làm điều này, bạn sẽ xây dựng cho mình một mạng lưới an toàn tốt đẹp, nhưng bạn có thể đã đưa ra các lỗi tinh vi trên đường đi.

Tôi đã tham gia vào nhiều dự án thực sự cần kiểm tra đơn vị từ ngày đầu tiên, và không có cách nào dễ dàng để đưa chúng vào đó, viết lại hoàn toàn, thường không thể được chứng minh khi mã đang hoạt động và đã kiếm được tiền. Gần đây, tôi đã sử dụng để viết các tập lệnh powershell thực thi mã theo cách tái tạo một khiếm khuyết ngay khi nó được nâng lên và sau đó giữ các tập lệnh này như một bộ các bài kiểm tra hồi quy để thay đổi tiếp theo. Bằng cách đó, ít nhất bạn có thể bắt đầu xây dựng một số thử nghiệm cho ứng dụng mà không thay đổi quá nhiều, tuy nhiên, đây giống như các thử nghiệm hồi quy từ đầu đến cuối so với thử nghiệm đơn vị thích hợp.

Tôi đồng ý với những gì hầu hết mọi người khác đã nói. Thêm các bài kiểm tra vào mã hiện tại là có giá trị. Tôi sẽ không bao giờ không đồng ý với quan điểm đó, nhưng tôi muốn thêm một lời cảnh báo.

Mặc dù việc thêm các bài kiểm tra vào mã hiện tại là có giá trị, nhưng nó có chi phí. Nó đi kèm với chi phí không xây dựng các tính năng mới. Làm thế nào hai điều này cân bằng hoàn toàn phụ thuộc vào dự án, và có một số biến.

• Bạn sẽ mất bao lâu để đặt tất cả mã đó vào thử nghiệm? Ngày nào? Tuần nào? Tháng? Năm nào?
• Bạn đang viết mã này cho ai? Trả tiền cho khách hàng? Một giáo sư? Một dự án nguồn mở?
• Thời khóa biểu của bạn như thế nào? Bạn có thời hạn khó khăn bạn phải đáp ứng? Bạn có bất kỳ thời hạn nào không?

Một lần nữa, hãy để tôi nhấn mạnh, các bài kiểm tra có giá trị và bạn nên làm việc để kiểm tra mã cũ của mình. Đây thực sự là một vấn đề về cách bạn tiếp cận nó. Nếu bạn có thể đủ khả năng để bỏ mọi thứ và kiểm tra tất cả mã cũ của bạn, hãy làm điều đó. Nếu điều đó không thực tế, thì đây là những gì bạn nên làm ít nhất

• Bất kỳ mã mới nào bạn viết phải hoàn toàn được kiểm tra đơn vị
• Bất kỳ mã cũ nào bạn chạm vào (sửa lỗi, mở rộng, v.v.) nên được đặt trong bài kiểm tra đơn vị

Ngoài ra, đây không phải là một đề xuất tất cả hoặc không có gì. Nếu bạn có một nhóm gồm bốn người và bạn có thể đáp ứng thời hạn của mình bằng cách đưa một hoặc hai người vào làm nhiệm vụ kiểm tra di sản, bằng mọi cách hãy làm điều đó.

Biên tập:

Tôi đang đặt mục tiêu viết câu hỏi này sau này với những ưu và nhược điểm để thử và cho quản lý thấy rằng đáng để dành hàng giờ đồng hồ để chuyển sự phát triển của sản phẩm trong tương lai sang TDD.

Điều này giống như hỏi "Những ưu và nhược điểm của việc sử dụng kiểm soát nguồn là gì?" hoặc "Những ưu và nhược điểm khi phỏng vấn mọi người trước khi thuê họ là gì?" hoặc "những ưu và nhược điểm của hơi thở là gì?"

Đôi khi chỉ có một mặt để tranh luận. Bạn cần phải có các bài kiểm tra tự động của một số hình thức cho bất kỳ dự án nào về bất kỳ sự phức tạp nào. Không, các bài kiểm tra không tự viết, và, vâng, sẽ mất thêm một chút thời gian để đưa mọi thứ ra khỏi cửa. Nhưng về lâu dài sẽ mất nhiều thời gian hơn và tốn nhiều tiền hơn để sửa lỗi sau khi thực tế hơn là viết các bài kiểm tra trước. Giai đoạn = Stage. Thats tất cả để có nó.

Khi chúng tôi bắt đầu thêm các bài kiểm tra, đó là một cơ sở mã mười tuổi, xấp xỉ hàng triệu dòng, với quá nhiều logic trong giao diện người dùng và trong mã báo cáo.

Một trong những điều đầu tiên chúng tôi đã làm (sau khi thiết lập máy chủ xây dựng liên tục) là thêm các bài kiểm tra hồi quy. Đây là những bài kiểm tra đầu cuối.

• Mỗi bộ kiểm tra bắt đầu bằng cách khởi tạo cơ sở dữ liệu đến trạng thái đã biết. Chúng tôi thực sự có hàng tá bộ dữ liệu hồi quy mà chúng tôi giữ trong Subversion (trong một kho lưu trữ riêng biệt từ mã của chúng tôi, vì kích thước tuyệt đối). FixtureSetUp của mỗi bài kiểm tra sao chép một trong các bộ dữ liệu hồi quy này vào cơ sở dữ liệu tạm thời, rồi chạy từ đó.
• Thiết lập lịch thi đấu sau đó chạy một số quy trình có kết quả mà chúng tôi quan tâm. (Bước này là tùy chọn - một số kiểm tra hồi quy chỉ tồn tại để kiểm tra các báo cáo.)
• Sau đó, mỗi bài kiểm tra chạy một báo cáo, xuất báo cáo thành tệp .csv và so sánh nội dung của .csv đó với một ảnh chụp nhanh đã lưu. Các .csv chụp nhanh này được lưu trữ trong Subversion bên cạnh mỗi tập dữ liệu hồi quy. Nếu đầu ra báo cáo không khớp với ảnh chụp nhanh đã lưu, thử nghiệm thất bại.

Mục đích của kiểm tra hồi quy là cho bạn biết nếu có gì đó thay đổi. Điều đó có nghĩa là họ thất bại nếu bạn phá vỡ một cái gì đó, nhưng họ cũng thất bại nếu bạn thay đổi mục đích (trong trường hợp đó là sửa lỗi để cập nhật tệp ảnh chụp nhanh). Bạn không biết rằng các tệp ảnh chụp nhanh thậm chí còn chính xác - có thể có lỗi trong hệ thống (và sau đó khi bạn sửa các lỗi đó, các bài kiểm tra hồi quy sẽ thất bại).

Tuy nhiên, kiểm tra hồi quy là một chiến thắng lớn đối với chúng tôi. Tất cả mọi thứ trong hệ thống của chúng tôi đều có báo cáo, vì vậy, bằng cách dành vài tuần để khai thác thử nghiệm xung quanh các báo cáo, chúng tôi đã có thể nhận được một mức độ bảo hiểm trên một phần lớn cơ sở mã của chúng tôi. Viết các bài kiểm tra đơn vị tương đương sẽ mất nhiều tháng hoặc nhiều năm. (Các bài kiểm tra đơn vị sẽ cung cấp cho chúng tôi phạm vi bảo hiểm tốt hơn nhiều, và sẽ ít mong manh hơn; nhưng tôi muốn có một cái gì đó ngay bây giờ, thay vì chờ đợi sự hoàn hảo trong nhiều năm.)

Sau đó, chúng tôi đã quay lại và bắt đầu thêm các bài kiểm tra đơn vị khi chúng tôi sửa lỗi, hoặc thêm các cải tiến hoặc cần thiết để hiểu một số mã. Kiểm tra hồi quy không có cách nào loại bỏ sự cần thiết của các bài kiểm tra đơn vị; chúng chỉ là một mạng lưới an toàn cấp một, để bạn nhanh chóng nhận được một số mức độ bao phủ thử nghiệm. Sau đó, bạn có thể bắt đầu tái cấu trúc để phá vỡ các phụ thuộc, vì vậy bạn có thể thêm các bài kiểm tra đơn vị; và các bài kiểm tra hồi quy cung cấp cho bạn một mức độ tin cậy rằng tái cấu trúc của bạn không phá vỡ bất cứ điều gì.

Kiểm tra hồi quy có vấn đề: chúng chậm và có quá nhiều lý do khiến chúng có thể bị hỏng. Nhưng ít nhất đối với chúng tôi, họ rất xứng đáng. Họ đã bắt được vô số lỗi trong năm năm qua và họ bắt được chúng trong vòng vài giờ, thay vì chờ đợi một chu kỳ QA. Chúng tôi vẫn có các thử nghiệm hồi quy ban đầu, trải rộng trên bảy máy xây dựng liên tục khác nhau (tách biệt với máy chạy thử nghiệm đơn vị nhanh) và đôi khi chúng tôi còn thêm vào chúng, bởi vì chúng tôi vẫn có rất nhiều mã đến mức 6.000 + kiểm tra đơn vị không bao gồm.

Nó hoàn toàn xứng đáng. Ứng dụng của chúng tôi có các quy tắc xác thực chéo phức tạp và gần đây chúng tôi đã phải thực hiện các thay đổi quan trọng đối với các quy tắc kinh doanh. Chúng tôi đã kết thúc với những xung đột khiến người dùng không thể lưu. Tôi nhận ra rằng sẽ mất nhiều thời gian để sắp xếp nó trong phần vỗ tay (phải mất vài phút chỉ để đi đến điểm có vấn đề). Tôi muốn giới thiệu các thử nghiệm đơn vị tự động và đã cài đặt khung, nhưng tôi đã không làm bất cứ điều gì ngoài một vài thử nghiệm giả để đảm bảo mọi thứ đang hoạt động. Với các quy tắc kinh doanh mới trong tay, tôi bắt đầu viết bài kiểm tra. Các thử nghiệm nhanh chóng xác định các điều kiện gây ra xung đột và chúng tôi có thể làm rõ các quy tắc.

Nếu bạn viết các bài kiểm tra bao gồm các chức năng bạn thêm hoặc sửa đổi, bạn sẽ nhận được lợi ích ngay lập tức. Nếu bạn chờ viết lại, bạn có thể không bao giờ có bài kiểm tra tự động.

Bạn không nên dành nhiều thời gian để viết bài kiểm tra cho những thứ hiện có đã hoạt động. Hầu hết thời gian, bạn không có một đặc tả cho mã hiện có, vì vậy điều chính bạn đang thử nghiệm là khả năng kỹ thuật đảo ngược của bạn. Mặt khác, nếu bạn định sửa đổi một cái gì đó, bạn cần bao gồm chức năng đó bằng các thử nghiệm để bạn biết bạn đã thực hiện các thay đổi một cách chính xác. Và tất nhiên, đối với chức năng mới, hãy viết các bài kiểm tra thất bại, sau đó thực hiện chức năng còn thiếu.

Tôi sẽ thêm giọng nói của mình và nói có, nó luôn hữu ích!

Tuy nhiên, có một số điểm khác biệt bạn nên ghi nhớ: hộp đen vs hộp trắng và đơn vị so với chức năng. Vì các định nghĩa khác nhau, đây là những gì tôi muốn nói:

• Hộp đen = các bài kiểm tra được viết mà không có kiến ​​thức đặc biệt về việc triển khai, thường chọc vào các trường hợp cạnh để đảm bảo mọi thứ xảy ra như một người dùng ngây thơ mong đợi.
• White-box = các bài kiểm tra được viết với kiến thức về việc thực hiện, thường cố gắng thực hiện các điểm thất bại nổi tiếng.
• Kiểm tra đơn vị = kiểm tra các đơn vị riêng lẻ (chức năng, mô-đun tách rời, v.v.). Ví dụ: đảm bảo lớp mảng của bạn hoạt động như mong đợi và hàm so sánh chuỗi của bạn trả về kết quả mong đợi cho một loạt các đầu vào.
• Kiểm tra chức năng = kiểm tra toàn bộ hệ thống cùng một lúc. Các thử nghiệm này sẽ thực hiện một khối lớn của hệ thống cùng một lúc. Ví dụ: init, mở một kết nối, thực hiện một số nội dung trong thế giới thực, đóng cửa, chấm dứt. Tôi thích vẽ một sự khác biệt giữa những bài kiểm tra này và bài kiểm tra đơn vị, vì chúng phục vụ một mục đích khác nhau.

Khi tôi thêm các bài kiểm tra vào một sản phẩm vận chuyển vào cuối trò chơi, tôi thấy rằng tôi đã kiếm được nhiều tiền nhất từ các thử nghiệm chức năng và hộp trắng . Nếu có bất kỳ phần nào của mã mà bạn biết là đặc biệt dễ vỡ, hãy viết các bài kiểm tra hộp trắng để bao quát các trường hợp vấn đề để đảm bảo rằng nó không phá vỡ cùng một cách hai lần. Tương tự, các kiểm tra chức năng toàn hệ thống là một kiểm tra vệ sinh hữu ích giúp bạn đảm bảo rằng bạn không bao giờ phá vỡ 10 trường hợp sử dụng phổ biến nhất.

Các thử nghiệm hộp đen và đơn vị của các đơn vị nhỏ cũng hữu ích, nhưng nếu thời gian của bạn bị hạn chế, tốt hơn là thêm chúng sớm. Vào thời điểm bạn giao hàng, bạn thường tìm thấy (một cách khó khăn) phần lớn các trường hợp và vấn đề mà các bài kiểm tra này đã tìm thấy.

Giống như những người khác, tôi cũng sẽ nhắc bạn về hai điều quan trọng nhất về TDD:

1. Tạo các bài kiểm tra là một công việc liên tục. Nó không bao giờ dừng lại. Bạn nên cố gắng thêm các thử nghiệm mới mỗi khi bạn viết mã mới hoặc sửa đổi mã hiện có.
2. Bộ kiểm tra của bạn là không bao giờ sai Đừng để thực tế là bạn có các bài kiểm tra đưa bạn vào cảm giác an toàn sai lầm. Chỉ vì nó vượt qua bộ kiểm tra không có nghĩa là nó hoạt động chính xác hoặc bạn chưa đưa ra hồi quy hiệu suất tinh tế, v.v.

Việc có đáng để thêm các bài kiểm tra đơn vị vào một ứng dụng đang được sản xuất hay không phụ thuộc vào chi phí duy trì ứng dụng. Nếu ứng dụng có một vài lỗi và yêu cầu nâng cao, thì có lẽ nó không đáng để bỏ công sức. OTOH, nếu ứng dụng bị lỗi hoặc thường xuyên sửa đổi thì các bài kiểm tra đơn vị sẽ cực kỳ có lợi.

Tại thời điểm này, hãy nhớ rằng tôi đang nói về việc thêm các bài kiểm tra đơn vị một cách có chọn lọc, không cố gắng tạo ra một bộ các bài kiểm tra tương tự như các bài kiểm tra sẽ tồn tại nếu bạn đã thực hành TDD ngay từ đầu. Do đó, để trả lời cho nửa sau của câu hỏi thứ hai của bạn: hãy đưa ra quan điểm sử dụng TDD cho dự án tiếp theo của bạn, cho dù đó là dự án mới hay viết lại (xin lỗi, nhưng đây là một liên kết đến một cuốn sách khác mà bạn thực sự nên đọc : Phát triển phần mềm hướng đối tượng được hướng dẫn bởi các thử nghiệm )

Câu trả lời của tôi cho câu hỏi thứ ba của bạn giống như câu hỏi thứ nhất: nó phụ thuộc vào bối cảnh dự án của bạn.

Được nhúng trong bài đăng của bạn là một câu hỏi tiếp theo về việc đảm bảo rằng mọi thử nghiệm được trang bị theo kiểu retro đều được thực hiện đúng . Điều quan trọng cần đảm bảo là các thử nghiệm đơn vị thực sự là thử nghiệm đơn vị , và điều này (thường xuyên hơn không) có nghĩa là các thử nghiệm trang bị thêm đòi hỏi phải cấu trúc lại mã hiện có để cho phép tách lớp / thành phần của bạn (xem tiêm phụ thuộc; đảo ngược điều khiển; chế giễu). Nếu bạn không thực thi điều này thì các bài kiểm tra của bạn sẽ trở thành các bài kiểm tra tích hợp, rất hữu ích, nhưng ít nhắm mục tiêu và dễ vỡ hơn các bài kiểm tra đơn vị thực sự.

Bạn không đề cập đến ngôn ngữ triển khai, nhưng nếu trong Java thì bạn có thể thử cách tiếp cận này:

1. Trong một thử nghiệm hồi quy xây dựng cây nguồn riêng biệt hoặc các thử nghiệm 'khói', sử dụng một công cụ để tạo chúng, có thể giúp bạn đạt được mức độ bao phủ gần 80%. Các thử nghiệm này thực thi tất cả các đường dẫn logic mã và xác minh từ thời điểm đó rằng mã vẫn thực hiện chính xác những gì hiện tại (ngay cả khi có lỗi). Điều này cung cấp cho bạn một mạng lưới an toàn chống lại hành vi vô tình thay đổi khi thực hiện tái cấu trúc cần thiết để làm cho mã dễ dàng kiểm tra đơn vị bằng tay.

   • Gợi ý sản phẩm - Tôi đã từng sử dụng sản phẩm dựa trên web miễn phí Junit Factory, nhưng thật đáng buồn là giờ nó đã đóng cửa. Tuy nhiên, sản phẩm vẫn tồn tại trong Máy phát điện AgitarOne JUnit được cấp phép thương mại tại http://www.agitar.com/solutions/products/automated_junit_generation.html

2. Đối với mỗi lỗi bạn sửa hoặc tính năng bạn thêm từ bây giờ, hãy sử dụng phương pháp TDD để đảm bảo mã mới được thiết kế để có thể kiểm tra và đặt các thử nghiệm này trong cây nguồn kiểm tra bình thường.

3. Mã hiện tại cũng có thể sẽ cần phải được thay đổi hoặc tái cấu trúc để làm cho nó có thể kiểm tra được như là một phần của việc thêm các tính năng mới; kiểm tra khói của bạn sẽ cung cấp cho bạn một mạng lưới an toàn chống lại sự hồi quy hoặc những thay đổi tinh vi trong hành vi.

4. Khi thực hiện các thay đổi (sửa lỗi hoặc tính năng) thông qua TDD, khi hoàn tất, có thể thử nghiệm khói đồng hành bị lỗi. Xác minh các lỗi như mong đợi do những thay đổi được thực hiện và loại bỏ thử nghiệm khói ít đọc hơn, vì thử nghiệm đơn vị viết tay của bạn có phạm vi bảo hiểm đầy đủ của thành phần cải tiến đó. Đảm bảo rằng phạm vi kiểm tra của bạn không từ chối chỉ giữ nguyên hoặc tăng.

5. Khi sửa lỗi, hãy viết một bài kiểm tra đơn vị bị lỗi để lộ lỗi trước.

Tôi muốn bắt đầu câu trả lời này bằng cách nói rằng thử nghiệm đơn vị thực sự quan trọng bởi vì nó sẽ giúp bạn bắt lỗi trước khi chúng chui vào sản xuất.

Xác định các dự án / mô-đun khu vực nơi các lỗi đã được giới thiệu lại. bắt đầu với những dự án để viết bài kiểm tra Hoàn toàn có ý nghĩa khi viết các bài kiểm tra cho chức năng mới và sửa lỗi.

Có đáng nỗ lực cho một giải pháp hiện có trong sản xuất không?

Đúng. Bạn sẽ thấy tác động của lỗi xuống và việc bảo trì trở nên dễ dàng hơn

Nó sẽ tốt hơn để bỏ qua thử nghiệm cho dự án này và thêm nó trong một lần viết lại có thể trong tương lai?

Tôi muốn giới thiệu để bắt đầu nếu từ bây giờ.

Điều gì sẽ có lợi hơn; dành một vài tuần để thêm các bài kiểm tra hoặc một vài tuần thêm chức năng?

Bạn đang hỏi sai câu hỏi. Chắc chắn, chức năng là quan trọng hơn bất cứ điều gì khác. Nhưng, thay vào đó, bạn nên hỏi nếu dành một vài tuần để thêm kiểm tra sẽ làm cho hệ thống của tôi ổn định hơn. Điều này sẽ giúp người dùng cuối của tôi? Nó sẽ giúp một nhà phát triển mới trong nhóm hiểu dự án và cũng để đảm bảo rằng anh ấy / cô ấy không đưa ra lỗi do thiếu hiểu biết về tác động chung của thay đổi.

Tôi rất thích Tái cấu trúc Trái cây treo thấp như một câu trả lời cho câu hỏi bắt đầu tái cấu trúc ở đâu. Đó là một cách để dễ dàng thiết kế tốt hơn mà không cần cắn nhiều hơn bạn có thể nhai.

Tôi nghĩ logic tương tự áp dụng cho TDD - hoặc chỉ các bài kiểm tra đơn vị: viết các bài kiểm tra bạn cần, khi bạn cần chúng; viết các bài kiểm tra cho mã mới; viết kiểm tra các lỗi khi chúng xuất hiện. Bạn lo lắng về việc bỏ qua các khu vực khó tiếp cận của cơ sở mã và chắc chắn đó là một rủi ro, nhưng là một cách để bắt đầu: bắt đầu! Dù sao, bạn có thể giảm thiểu rủi ro bằng các công cụ bảo hiểm mã và rủi ro không (theo ý kiến ​​của tôi) là lớn, dù sao đi nữa: nếu bạn che đậy các lỗi, che mã mới, che mã bạn đang xem , sau đó bạn đang bao gồm mã có nhu cầu lớn nhất để kiểm tra.

• Vâng, đúng vậy. Khi bạn bắt đầu thêm chức năng mới, nó có thể gây ra một số sửa đổi mã cũ và kết quả là nó là một nguồn gây ra lỗi.
• (xem cái đầu tiên) trước khi bạn bắt đầu thêm chức năng mới, tất cả (hoặc gần như) mã (lý tưởng) phải được bao phủ bởi các thử nghiệm đơn vị.
• (xem cái thứ nhất và thứ hai) :). một chức năng hoành tráng mới có thể "phá hủy" mã làm việc cũ.

Có nó có thể: Chỉ cần cố gắng đảm bảo tất cả các mã bạn viết từ bây giờ đã có một bài kiểm tra tại chỗ.

Nếu mã đã có sẵn cần phải được sửa đổi và có thể được kiểm tra, thì hãy làm như vậy, nhưng tốt hơn là đừng quá mạnh mẽ trong việc cố gắng kiểm tra tại chỗ để có mã ổn định. Điều đó có xu hướng có tác dụng kích thích và có thể vượt khỏi tầm kiểm soát.

Có đáng nỗ lực cho một giải pháp hiện có trong sản xuất không?

Nó sẽ tốt hơn để bỏ qua thử nghiệm cho dự án này và thêm nó trong một lần viết lại có thể trong tương lai?

Điều gì sẽ có lợi hơn; dành một vài tuần để thêm các bài kiểm tra hoặc một vài tuần thêm chức năng?

Cập nhật

6 năm sau câu trả lời ban đầu, tôi có một chút khác biệt.

Tôi nghĩ sẽ rất hợp lý khi thêm các bài kiểm tra đơn vị vào tất cả các mã mới mà bạn viết - và sau đó cấu trúc lại các vị trí nơi bạn thực hiện các thay đổi để làm cho chúng có thể kiểm tra được.

Viết thử nghiệm trong một lần cho tất cả mã hiện tại của bạn sẽ không giúp ích gì - nhưng không viết thử nghiệm cho mã mới bạn viết (hoặc các khu vực bạn sửa đổi) cũng không có ý nghĩa. Thêm các thử nghiệm khi bạn tái cấu trúc / thêm các thứ có lẽ là cách tốt nhất để thêm các thử nghiệm và làm cho mã dễ bảo trì hơn trong một dự án hiện có mà không cần thử nghiệm.

Câu trả lời trước đó

Tôi sẽ nâng một vài lông mày ở đây :)

Trước hết, dự án của bạn là gì - nếu đó là trình biên dịch hoặc ngôn ngữ hoặc khung hoặc bất kỳ thứ gì khác sẽ không thay đổi chức năng trong một thời gian dài, thì tôi nghĩ rằng nó hoàn toàn tuyệt vời để thêm các bài kiểm tra đơn vị.

Tuy nhiên, nếu bạn đang làm việc trên một ứng dụng có thể sẽ yêu cầu thay đổi chức năng (vì thay đổi yêu cầu) thì không có lý do gì để phải nỗ lực thêm.

Tại sao?

1. Các thử nghiệm đơn vị chỉ bao gồm các thử nghiệm mã - cho dù mã đó có thực hiện được những gì nó được thiết kế hay không - nó không phải là sự thay thế cho thử nghiệm thủ công mà dù sao cũng phải thực hiện (để phát hiện ra các lỗi chức năng, các vấn đề về khả năng sử dụng và tất cả các loại vấn đề khác)

2. Kiểm tra đơn vị thời gian chi phí! Bây giờ tôi đến từ đâu, đó là một mặt hàng quý giá - và doanh nghiệp thường chọn chức năng tốt hơn trên một bộ thử nghiệm hoàn chỉnh.

3. Nếu ứng dụng của bạn thậm chí còn hữu ích từ xa đối với người dùng, họ sẽ yêu cầu thay đổi - vì vậy bạn sẽ có các phiên bản sẽ làm mọi thứ tốt hơn, nhanh hơn và có thể làm những điều mới - cũng có thể có rất nhiều cấu trúc lại khi mã của bạn phát triển. Duy trì một bộ kiểm tra đơn vị phát triển đầy đủ trong một môi trường năng động là một vấn đề đau đầu.

4. Các thử nghiệm đơn vị sẽ không ảnh hưởng đến chất lượng cảm nhận của sản phẩm của bạn - chất lượng mà người dùng nhìn thấy. Chắc chắn, các phương thức của bạn có thể hoạt động chính xác như đã làm vào ngày 1, giao diện giữa lớp trình bày và lớp nghiệp vụ có thể còn nguyên sơ - nhưng hãy đoán xem? Người dùng không quan tâm! Nhận một số người thử nghiệm thực sự để kiểm tra ứng dụng của bạn. Và thường xuyên hơn không, các phương thức và giao diện đó phải thay đổi dù sao, sớm hay muộn.

Điều gì sẽ có lợi hơn; dành một vài tuần để thêm các bài kiểm tra hoặc một vài tuần thêm chức năng? - Có rất nhiều điều bạn có thể làm tốt hơn là viết bài kiểm tra - Viết chức năng mới, cải thiện hiệu suất, cải thiện khả năng sử dụng, viết hướng dẫn trợ giúp tốt hơn, giải quyết các lỗi đang chờ xử lý, v.v.

Bây giờ đừng hiểu sai ý tôi - Nếu bạn hoàn toàn tích cực rằng mọi thứ sẽ không thay đổi trong 100 năm tới, hãy tiếp tục, loại bỏ bản thân và viết những bài kiểm tra đó. Kiểm tra tự động cũng là một ý tưởng tuyệt vời cho API, nơi bạn hoàn toàn không muốn phá vỡ mã của bên thứ ba. Ở mọi nơi khác, nó chỉ là thứ khiến tôi giao hàng sau này!

Bạn sẽ không bao giờ có phạm vi kiểm tra đáng kể, vì vậy bạn phải có chiến thuật về nơi bạn thêm các bài kiểm tra:

• Như bạn đã đề cập, khi bạn tìm thấy một lỗi, đây là thời điểm tốt để viết một bài kiểm tra (để tái tạo nó), và sau đó sửa lỗi. Nếu bạn thấy thử nghiệm tái tạo lỗi, bạn có thể chắc chắn đó là một thử nghiệm tốt, tốt. Với một phần lớn các lỗi như vậy là hồi quy (50%?), Gần như luôn luôn đáng để viết các bài kiểm tra hồi quy.
• Khi bạn đi sâu vào một vùng mã để sửa đổi nó, đây là thời điểm tốt để viết các bài kiểm tra xung quanh nó. Tùy thuộc vào bản chất của mã, các thử nghiệm khác nhau là phù hợp. Một bộ lời khuyên tốt được tìm thấy ở đây .

OTOH, không đáng để chỉ ngồi viết các bài kiểm tra xung quanh mã mà mọi người hài lòng - đặc biệt là nếu không có ai sẽ sửa đổi nó. Nó chỉ không thêm giá trị (ngoại trừ có thể hiểu hành vi của hệ thống).

Chúc may mắn!

Bạn nói rằng bạn không muốn mua một cuốn sách khác. Vì vậy, chỉ cần đọc bài viết của Michael Feather về làm việc hiệu quả với mã kế thừa . Sau đó mua sách :)

Nếu tôi ở vị trí của bạn, có lẽ tôi sẽ thực hiện một cách tiếp cận từ bên ngoài, bắt đầu với các bài kiểm tra chức năng thực hiện toàn bộ hệ thống. Tôi sẽ cố gắng ghi lại các yêu cầu của hệ thống bằng ngôn ngữ đặc tả BDD như RSpec, sau đó viết các bài kiểm tra để xác minh các yêu cầu đó bằng cách tự động hóa giao diện người dùng.

Sau đó, tôi sẽ thực hiện phát triển theo hướng khiếm khuyết cho các lỗi mới được phát hiện, viết các bài kiểm tra đơn vị để tái tạo các vấn đề và làm việc với các lỗi cho đến khi các bài kiểm tra vượt qua.

Đối với các tính năng mới, tôi sẽ sử dụng phương pháp tiếp cận bên ngoài: Bắt đầu với các tính năng được ghi trong RSpec và được xác minh bằng cách tự động hóa giao diện người dùng (tất nhiên sẽ thất bại ban đầu), sau đó thêm các thử nghiệm đơn vị chi tiết hơn khi quá trình triển khai diễn ra.

Tôi không phải là chuyên gia về quy trình, nhưng từ kinh nghiệm nhỏ bé tôi có thể nói với bạn rằng BDD thông qua kiểm tra giao diện người dùng tự động là không dễ dàng, nhưng tôi nghĩ rằng nó đáng để nỗ lực, và có lẽ sẽ mang lại lợi ích cao nhất trong trường hợp của bạn.

Tôi không phải là một chuyên gia TDD dày dạn bằng mọi cách, nhưng tất nhiên tôi sẽ nói rằng việc kiểm tra đơn vị càng nhiều càng tốt. Vì mã đã có sẵn, tôi sẽ bắt đầu bằng cách thực hiện một số loại tự động kiểm tra đơn vị. Tôi sử dụng TeamCity để thực hiện tất cả các thử nghiệm trong các dự án của mình và nó cung cấp cho bạn một bản tóm tắt hay về cách các thành phần đã làm.

Với điều đó, tôi sẽ chuyển sang những thành phần logic kinh doanh thực sự quan trọng không thể thất bại. Trong trường hợp của tôi, có một số vấn đề hình học cơ bản cần được giải quyết cho các đầu vào khác nhau, vì vậy tôi đã kiểm tra cái quái gì trong số đó. Lý do tôi làm điều này là vì khi tôi đốt dầu nửa đêm, rất dễ lãng phí thời gian để đào sâu xuống độ sâu của mã mà thực sự không cần phải chạm vào, bởi vì bạn biết rằng chúng đã được kiểm tra cho tất cả các đầu vào có thể (trong trường hợp của tôi, có một số lượng đầu vào hữu hạn).

Ok, vì vậy bây giờ bạn hy vọng cảm thấy tốt hơn về những phần quan trọng. Thay vì ngồi xuống và đập vỡ tất cả các bài kiểm tra, tôi sẽ tấn công chúng khi chúng xuất hiện. Nếu bạn gặp phải một lỗi mà Pita thực sự cần khắc phục, hãy viết các bài kiểm tra đơn vị cho nó và tránh chúng.

Có những trường hợp bạn sẽ thấy rằng kiểm tra là khó khăn vì bạn không thể khởi tạo một lớp cụ thể từ bài kiểm tra, vì vậy bạn phải chế giễu nó. Ồ, nhưng có lẽ bạn không thể chế giễu nó một cách dễ dàng vì bạn đã không viết lên một giao diện. Tôi coi những kịch bản "rất tiếc" này là một cơ hội để thực hiện giao diện đã nói, bởi vì, đó là một điều tốt.

Từ đó, tôi sẽ lấy máy chủ xây dựng của bạn hoặc bất kỳ tự động hóa nào bạn có tại chỗ được định cấu hình bằng công cụ bao phủ mã. Họ tạo ra các biểu đồ thanh khó chịu với các vùng màu đỏ lớn nơi bạn có vùng phủ sóng kém. Bây giờ phạm vi bảo hiểm 100% không phải là mục tiêu của bạn, cũng không phải bảo hiểm 100% có nghĩa là mã của bạn có khả năng chống đạn, nhưng thanh màu đỏ chắc chắn thúc đẩy tôi khi tôi có thời gian rảnh. :)

Có rất nhiều câu trả lời hay vì vậy tôi sẽ không lặp lại nội dung của chúng. Tôi đã kiểm tra hồ sơ của bạn và có vẻ như bạn là nhà phát triển C # .NET. Do đó, tôi đang thêm tài liệu tham khảo cho dự án Microsoft PEX và Moles có thể giúp bạn kiểm tra đơn vị tự động cho mã kế thừa. Tôi biết rằng tự sinh không phải là cách tốt nhất nhưng ít nhất nó là cách để bắt đầu. Kiểm tra bài viết rất thú vị này từ tạp chí MSDN về việc sử dụng PEX cho mã kế thừa .

Tôi khuyên bạn nên đọc một bài viết xuất sắc của một Kỹ sư TopTal, giải thích nơi bắt đầu thêm các bài kiểm tra: nó chứa rất nhiều toán học, nhưng ý tưởng cơ bản là:

1) Đo lường Khớp nối liên kết (CA) của mã của bạn (số lượng một lớp được sử dụng bởi các lớp khác, nghĩa là phá vỡ nó sẽ gây ra thiệt hại trên diện rộng)

2) Đo độ phức tạp theo chu kỳ (CC) của mã của bạn (độ phức tạp cao hơn = thay đổi phá vỡ cao hơn)

Bạn cần xác định các lớp có CA và CC cao, tức là có chức năng f (CA, CC) và các lớp có sự khác biệt nhỏ nhất giữa hai số liệu nên được ưu tiên cao nhất cho phạm vi kiểm tra.

Tại sao? Bởi vì một CA cao nhưng các lớp CC rất thấp rất quan trọng nhưng không có khả năng phá vỡ. Mặt khác, CA thấp nhưng CC cao có khả năng bị phá vỡ, nhưng sẽ gây ra ít thiệt hại hơn. Vì vậy, bạn muốn cân bằng.

Nó phụ thuộc ...
Thật tuyệt khi có các bài kiểm tra đơn vị nhưng bạn cần xem xét người dùng của mình là ai và họ sẵn sàng chịu đựng những gì để có được một sản phẩm không có lỗi hơn. Chắc chắn bằng cách cấu trúc lại mã của bạn hiện chưa có kiểm tra đơn vị, bạn sẽ giới thiệu các lỗi và nhiều người dùng sẽ khó hiểu rằng bạn đang làm cho sản phẩm bị lỗi tạm thời để làm cho nó ít bị lỗi hơn trong thời gian dài. Cuối cùng, đó là những người dùng sẽ có tiếng nói cuối cùng ...

Đúng. Không. Thêm bài kiểm tra.

Hướng tới một cách tiếp cận TDD nhiều hơn sẽ thực sự thông báo tốt hơn những nỗ lực của bạn để thêm chức năng mới và làm cho thử nghiệm hồi quy dễ dàng hơn nhiều. Kiểm tra nó ra!