Dự án của tôi cần lớn đến mức nào để tôi kiểm tra đơn vị? [đóng cửa]

Tôi giả định rằng dự án của tôi được tách riêng đủ để cho phép thử nghiệm đơn vị. Nhưng lớn như thế nào, chính xác, về mặt phân thân và chức năng, dự án của tôi cần phải làm cho thử nghiệm đơn vị có giá trị?

Tất cả chúng ta đều phạm sai lầm và không ai hoàn hảo, nhưng tôi coi mình là một lập trình viên giỏi để xử lý các lỗi của các dự án nhỏ khi bước qua. Hoặc là thử nghiệm đơn vị là một điều cần thiết khó khăn cho dù dự án của bạn có quy mô như thế nào?

Dự án của bạn đã đủ lớn rồi.

Theo kinh nghiệm của tôi, một lớp và một hàm đã đủ để xem xét nhu cầu kiểm thử đơn vị.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

Tôi chưa bao giờ mua ý tưởng "bạn phải kiểm tra mọi thứ", mặc dù chắc chắn có những người ngoài kia có (xem câu trả lời của gnat !).

Theo tôi thấy, những lợi ích chính của thử nghiệm đơn vị là:

1. Giúp đảm bảo thay đổi không phá vỡ mọi thứ.
2. Giúp bạn thiết kế các giao diện hợp lý cho các lớp của bạn (vì nó buộc bạn phải là khách hàng theo mã của riêng bạn).
3. Giúp tài liệu về cách mã của bạn dự kiến ​​sẽ được sử dụng.

Về cơ bản, bạn cần cân nhắc thời gian cần thiết để viết và duy trì các bài kiểm tra chống lại các yếu tố này.

Số 1 thường là đủ để làm cho nó đáng để viết bài kiểm tra. Theo kinh nghiệm của tôi,> 95% mã được sửa đổi sớm hay muộn.

Thật đơn giản: bạn không cần kiểm tra đơn vị nếu bạn sẽ loại bỏ chương trình sau khi chạy nó một lần.

Nếu điều này có vẻ quá mức đối với bạn, hãy xem xét ý nghĩa của sự thay thế. Nếu có một số kích thước dưới mức mà thử nghiệm đơn vị không trả, bạn sẽ phải tiếp tục phán xét trong đầu: "Tôi đã đạt đến kích thước ma thuật chưa? Tôi có nên bắt đầu viết thử nghiệm không?" Bây giờ, các lập trình viên nổi tiếng là xấu trong việc dự đoán tương lai, và họ nổi tiếng là xấu khi đánh giá kỹ năng của chính họ. Mã trông rõ ràng đối với bạn bây giờ sẽ trở nên khó hiểu, ngay cả với bạn, thậm chí bằng cách chờ đợi một tháng. Một dự án mà bạn chắc chắn, tích cực chắc chắn sẽ không bao giờ được sử dụng nữa và bạn chỉ loanh quanh với cơ hội từ xa rằng bạn có thể muốn tìm kiếm cách bạn đã giải quyết một cái gì đó trước đó, sẽ được yêu cầu lại và sẽ nhận được yêu cầu thay đổi.

Do đó, rất có khả năng bạn sẽ đánh giá sai việc kiểm tra có hữu ích hay không và khi bạn bắt đầu cần kiểm tra, bạn đã không chắc chắn 100% về ngữ nghĩa chính xác để kiểm tra thực sự là gì. Vì tôi tin rằng tất cả ngoại trừ các chương trình một lần tầm thường đều kiếm được lợi nhuận từ các bài kiểm tra đơn vị, tôi coi chi phí cho việc nỗ lực cho các bài kiểm tra không bao giờ được chạy lại là không đáng kể đối với các rủi ro khi mở rộng mã chưa được kiểm tra và hiểu sai.

Cách đây một thời gian tôi đã tìm thấy một bài viết hay: Tại sao thử nghiệm đơn vị tăng tốc độ phát triển . Nó có thể giúp bạn trả lời câu hỏi.

... Điều gì sẽ xảy ra nếu codebase ... được cung cấp một bộ thử nghiệm đơn vị đáng kể. Một tập hợp có thể nói rằng: nếu tất cả các thử nghiệm thành công, tôi đảm bảo rằng mã vẫn thực hiện những gì nó nên làm và nếu một thử nghiệm thất bại, nó sẽ hiển thị chính xác cho bạn biết một số hành vi bị phá vỡ. Điều này thật tuyệt, tôi có thể thay đổi mã để thêm những thứ tôi muốn mà không phải đi lang thang nếu mã vẫn làm những gì cần làm, tôi chỉ cần chạy ... kiểm tra và tôi có niềm tin. Đây là một thế giới tuyệt vời để trở thành một kỹ sư phần mềm. Tôi nhận thấy rằng tôi có thể tiến nhanh hơn ...

Tôi có niềm tin tôn giáo.

Đây có lẽ là lý do quan trọng nhất tại sao các bài kiểm tra đơn vị tăng tốc độ phát triển trong bối cảnh doanh nghiệp.

Tôi có thể tin tưởng rằng mọi thứ vẫn hoạt động nếu tất cả các bài kiểm tra vượt qua. Nếu các bài kiểm tra thất bại, họ sẽ chỉ ra chính xác nơi vấn đề đặt ra ...

... Bạn phải có phạm vi kiểm tra đơn vị cao và kiểm tra đơn vị tốt . Khi các điều kiện này được tôn trọng, bạn sẽ thấy mình trong tình huống nỗ lực thêm chức năng mới gần như không phụ thuộc vào kích thước của ứng dụng và về lâu dài nó sẽ tăng tốc độ phát triển .

Michael Feathers đã giới thiệu trong một trong những cuốn sách của mình hai cách làm việc với những thay đổi trong mã:

• chỉnh sửa và cầu nguyện,
• bao gồm và sửa đổi.

Không quan trọng là cơ sở mã lớn như thế nào.

Theo Kent Beck trong câu trả lời của mình cho câu hỏi Stack Overflow Bài kiểm tra đơn vị của bạn sâu bao nhiêu? , bạn nên kiểm tra mã mà bạn có xu hướng bị sai.

Nếu tôi thường không mắc một loại sai lầm nào (như đặt các biến sai trong hàm tạo), tôi sẽ không kiểm tra nó.

Kiểm tra đơn vị được thực hiện để tiết kiệm thời gian và cải thiện:

• theo dõi lỗi
• tái cấu trúc và / hoặc viết lại mã
• Thử nghiệm hội nhập
• kiểm tra hồi quy, vv

Đó là phải viết bài kiểm tra đơn vị cho các phần tương đối phức tạp của chương trình.

Nếu bạn chắc chắn rằng viết bài kiểm tra đơn vị bây giờ sẽ không tiết kiệm thời gian của bạn trong tương lai, bạn có thể bỏ qua nó. Tuy nhiên, bạn không bao giờ biết, và cá nhân tôi không thể nghĩ đến một trường hợp khi nó rẻ hơn (theo thời gian, tiền bạc và thần kinh) không viết bài kiểm tra đơn vị mà thay vào đó làm tất cả các bài kiểm tra bằng tay.

"Tôi có nên kiểm tra đơn vị này không" thường có thể được trả lời bằng cách trả lời câu hỏi sau: "Điều quan trọng là chức năng này có hoạt động tốt không và điều quan trọng đối với tôi là khi nào nó ngừng hoạt động?"

Tất nhiên, nó phức tạp hơn thế nhiều, nhưng đó là một cách tốt để bắt đầu. Cuối cùng, bạn cũng sẽ cân nhắc xem mã đã được kiểm tra hay chưa nhờ vào việc sử dụng chức năng khác, hoặc liệu thời gian của bạn sẽ được sử dụng tốt hơn trong chức năng khác, v.v.

Trừ khi bạn sẽ viết mã mà không kiểm tra nó, bạn sẽ luôn phải chịu chi phí kiểm tra.

Sự khác biệt giữa việc có các bài kiểm tra đơn vị và không có chúng là sự khác biệt giữa chi phí viết bài kiểm tra và chi phí để chạy nó so với chi phí kiểm tra bằng tay.

Nếu chi phí viết bài kiểm tra đơn vị là 2 phút và chi phí để chạy bài kiểm tra đơn vị thực tế bằng 0, nhưng chi phí kiểm tra mã thủ công là 1 phút, thì bạn sẽ hòa vốn ngay cả khi bạn đã chạy thử nghiệm hai lần.

Trong nhiều năm, tôi đã hiểu sai rằng tôi không có đủ thời gian để viết bài kiểm tra đơn vị cho mã của mình. Khi tôi viết bài kiểm tra, chúng là những thứ nặng nề, nặng nề, điều đó chỉ khuyến khích tôi nghĩ rằng tôi chỉ nên viết bài kiểm tra đơn vị khi tôi biết chúng là cần thiết.

Gần đây tôi đã được khuyến khích sử dụng Phát triển hướng thử nghiệm và tôi thấy đó là một tiết lộ hoàn chỉnh. Bây giờ tôi tin chắc rằng tôi không có thời gian để không viết bài kiểm tra đơn vị .

Theo kinh nghiệm của tôi, bằng cách phát triển với thử nghiệm trong tâm trí, bạn kết thúc với các giao diện sạch hơn, các lớp và mô-đun tập trung hơn và nói chung là RẮN hơn , mã có thể kiểm tra.

Mỗi lần tôi làm việc với mã kế thừa không có kiểm tra đơn vị và tôi phải kiểm tra thủ công một cái gì đó, tôi cứ nghĩ "việc này sẽ nhanh hơn rất nhiều nếu mã này đã có kiểm tra đơn vị". Mỗi lần tôi phải thử và thêm chức năng kiểm tra đơn vị vào mã có độ khớp cao, tôi cứ nghĩ "việc này sẽ dễ dàng hơn nhiều nếu nó được viết theo cách tách rời".

Phiên bản TL; DR :

Viết một bài kiểm tra khi chi phí viết bài kiểm tra, cộng với chi phí để chạy nó nhiều lần bạn cần có khả năng thấp hơn chi phí kiểm tra thủ công nhiều lần bạn cần.

Mặc dù vậy, hãy nhớ rằng nếu bạn sử dụng TDD, chi phí viết bài kiểm tra có thể sẽ giảm khi bạn làm tốt hơn và trừ khi mã hoàn toàn không quan trọng, bạn có thể sẽ chạy các bài kiểm tra của mình thường xuyên hơn bạn mong đợi.

Kiểm tra ngay khi bạn quan sát hồi quy xảy ra hoặc sợ gây ra một số với các chỉnh sửa của bạn và không nhận thấy.

Kindle sợ hãi, hãy để nó phát triển đến một kích thước phù hợp: bạn càng kiểm tra sớm thì càng tốt.

Xin lưu ý: tùy thuộc vào vai trò của bạn trong dự án, bài kiểm tra đơn vị có thể không phải là loại bài kiểm tra duy nhất bạn muốn viết.

Mọi người đều bị ám ảnh một cách chính đáng với các bài kiểm tra đơn vị , bởi vì các thực hành kiểm tra chính thống tồi tệ trong quá khứ; nhưng nếu bạn chưa bao giờ thử nghiệm trước đây, bạn thực sự nên tập trung vào thử nghiệm nói chung , thử nghiệm đơn vị sẽ không giải quyết được các vấn đề của thế giới.

Tôi tin rằng đó không phải là quy mô của dự án mà là loại dự án quyết định có nên sử dụng thử nghiệm hay không.

Nếu bạn đang làm việc trên một bằng chứng về khái niệm, hoặc trên một số dự án khác mà mục tiêu là học từ mã hóa, thì không cần phải thử nghiệm. Nếu dự án có nghĩa là được sử dụng, thậm chí có thể được đưa vào sản xuất, thì nó nên được thử nghiệm.

Một trích dẫn từ "Clean Code" của Robert C. Martin : "Nếu nó tầm thường để viết, thì nó không đáng để kiểm tra", vì vậy không có lý do gì để bỏ qua việc thử nghiệm cho các chương trình ngắn và tầm thường.

Đây thực sự không phải là vấn đề kích thước - đó là những gì bạn làm với nó (và nó bao nhiêu tuổi). Nếu tôi loay hoay tìm hiểu cách thức công nghệ hoạt động và lên kế hoạch loại bỏ mọi thứ (chúng tôi gọi đây là một đột biến trong Scrum), tôi sẽ chỉ viết mã mà không cần thực hiện nhiều thử nghiệm. Nếu bạn đang có kế hoạch phát triển nó hơn nữa (ngay cả khi bạn chỉ đang loay hoay), bạn nên viết các bài kiểm tra xung quanh mã. TDD là một kỹ thuật thiết kế ngay cả trước khi nó là một kỹ thuật thử nghiệm. Bạn muốn có một bức tranh rõ ràng về những gì bạn muốn mã thực hiện trước khi bạn bị ràng buộc trong các chi tiết của việc thực hiện. Tôi cũng sẽ KHÔNGkhuyên bạn nên cố gắng viết các bài kiểm tra đơn vị rộng rãi xung quanh số lượng lớn mã kế thừa. Cố gắng xác định những phần phức tạp (có độ phức tạp chu kỳ / mã spaghetti cao đối với chúng) và những phần bị hỏng thường xuyên (chúng thường sẽ giống nhau). Như những người khác đã đề xuất, tôi sẽ đọc cuốn sách của Kent Beck về TDD và chắc chắn đọc cuốn sách của Michael Feather. Những gì họ không bao gồm rất nhiều là khía cạnh chính trị để viết bài kiểm tra đơn vị xung quanh mã. Rất nhiều nhà phát triển ghét phải thay đổi mã của họ để làm cho nó có thể kiểm tra được và rất nhiều nhà phát triển không cảm thấy cần phải kiểm tra mã. Đó là một cái gì đó chúng ta phải làm việc như một nghề. Mọi kỷ luật kỹ thuật khác được yêu cầu phải chứng minh (thường là về mặt toán học) rằng công việc của họ đáp ứng các đặc điểm kỹ thuật. Chúng ta nên làm như vậy.

Liên kết một Dự án trong giới hạn của các lớp hoặc chức năng và sau đó đánh giá nếu điều này phù hợp với thử nghiệm đơn vị có thể sai. Có rất nhiều lợi ích của việc kiểm thử đơn vị một ứng dụng nhưng vẻ đẹp thực sự bắt đầu khi bạn phải duy trì một ứng dụng hoặc phải làm việc trong môi trường phân tán. Vì vậy, sự lựa chọn đến đây. Ngay cả một thay đổi nhỏ trong mã của bạn cũng có thể gây ra thảm họa.
Tôi không chỉ đề xuất 'Kiểm tra đơn vị' mà còn đề nghị kiểm tra phạm vi bảo hiểm mã của bạn, đảm bảo tối đa mã của bạn được bảo vệ bằng Kiểm tra đơn vị. Ngưỡng cho phạm vi bảo hiểm mã không được nhỏ hơn 95% và mục tiêu phải ở khoảng 100% . Bạn có thể tìm các công cụ để theo dõi phạm vi bảo hiểm mã của bạn và tạo một báo cáo.
Visual Studio cung cấp dữ liệu bảo hiểm -http://msdn.microsoft.com/en-us/l
Library / ms182496 (v = vs.80) .aspx Ngoài ra, bạn có thể sử dụng NCover hoặc dotCover.