Phát triển theo hướng thử nghiệm và Nguyên tắc mở/đóng hoạt động cùng nhau như thế nào?

Question

Tôi đã đọc các bài kiểm tra đơn vị, TDD và các nguyên tắc SOLID và tôi cần làm rõ một số. Sự hiểu biết của tôi là nếu tuân thủ nguyên tắc mở/đóng, thử nghiệm đơn vị có thể trở nên phần lớn không cần thiết do thực tế là mã được đóng để sửa đổi - do đó không cần kiểm tra lại nếu mã được tách biệt và tách riêng. Lợi ích lâu dài của chi phí trả trước thêm của kiểm tra đơn vị bị mất nếu một khi mã vượt qua các bài kiểm tra đơn vị liên quan, nó sẽ không thay đổi. Mã sẽ luôn vượt qua vì nó sẽ không bao giờ thay đổi, đúng không? Các lớp thừa kế sẽ cần phải được kiểm tra, nhưng một khi chúng vượt qua các bài kiểm tra liên quan, chúng cũng sẽ bị đóng để sửa đổi và sẽ không cần phải kiểm tra lại. The Wikipedia article on OCP củng cố dòng suy nghĩ này trong đoạn đầu tiên, (tôi nhận ra rằng không làm cho nó trở thành luật).
Giải thích tốt nhất mà tôi đã tìm thấy cho OCP và TDD sống hài hòa is here, mặc dù có vẻ như Arnon nói rằng OCP khen TDD trong đó nhà phát triển không được khuyến khích sửa đổi mã nguồn vì các phương pháp thử hiện có có thể trở nên phức tạp khi sửa đổi để kiểm tra chức năng mới.
Đó là tất cả những gì phải có? Xin lưu ý rằng tôi không tìm kiếm lý lẽ, tôi mới làm quen với điều này và tôi đang tìm cách làm rõ những người có nhiều kinh nghiệm hơn với chủ đề này hơn I.

Answer 1

Ngay cả khi bạn chấp nhận rằng một khi phần mềm hoạt động và không thay đổi, bạn không cần phải kiểm tra nó (mà tôi không), bạn vẫn cần phải chứng minh rằng một thành phần hoạt động ở nơi đầu tiên. Tôi sẽ tranh luận một trong những cách tốt nhất để làm điều đó là một bài kiểm tra đơn vị (s).

Ngoài ra, thực tế nói, một khi bạn đã thử nghiệm, chi phí rất ít để chạy nó. Vì vậy, ngay cả khi các thành phần không thay đổi, bạn sẽ không mất nhiều bằng cách liên tục chạy thử nghiệm. Hơn nữa, đôi khi thay đổi thiết kế và bạn cần phải quay trở lại và làm lại một số thành phần - có xét nghiệm đơn vị chắc chắn sẽ giúp trong trường hợp này ...

Hãy nhớ rằng, một kết quả của việc có một bộ thử nghiệm là nó thúc đẩy khả năng bảo trì bằng cách hiển thị khi một cái gì đó thay đổi. Vì vậy, ngay cả khi nhóm của bạn đang theo dõi O trong SOLID, điều đó không có nghĩa là mọi thứ sẽ không bị thay đổi một cách vô tình. Vì vậy, các bài kiểm tra giúp đỡ bằng cách hiển thị nếu một cái gì đó được thay đổi vô tình, và họ cho bạn thấy chính xác những gì đã bị ảnh hưởng bởi sự thay đổi.

Answer 2

kiểm tra đơn vị có thể trở thành phần lớn không cần thiết do thực tế rằng mã được đóng cửa để sửa đổi

Vâng, không gì cả. Làm thế nào để bạn biết bản gốc, đóng cửa, thực hiện là chính xác?

Lợi ích lâu dài của các chi phí trả trước tăng của kiểm tra đơn vị bị mất

Một phát hiện quan trọng về kinh tế công nghệ phần mềm là thì tốn nhiều tiền để phát hiện và sửa chữa một khiếm khuyết sau này trong cuộc đời của một sản phẩm. IIRC, theo thứ tự độ lớn cho từng giai đoạn trong quá trình phát triển "thác nước" cổ điển. Khi kiểm tra đơn vị (cho dù TDD hoặc thử nghiệm đầu tiên) phát hiện khuyết tật sớm, họ có thể nhanh chóng bù đắp chi phí của họ.

nó sẽ không thay đổi

Nếu nó có một khiếm khuyết trong đó nó sẽ phải được thay đổi. Tất nhiên, nếu bạn có thể đảm bảo rằng mã của bạn là khiếm khuyết miễn phí, những gì bạn nói là đúng sự thật. Nhưng nếu bạn có thể đảm bảo rằng bạn không cần bất kỳ loại thử nghiệm nào. Nhưng rất ít dự án phần mềm có thể đưa ra tuyên bố như vậy.