Là đơn vị thử nghiệm 100% hay không ở tất cả các loại thỏa thuận?
Tôi đã duyệt qua các dự án cũ của tôi và bắt đầu thêm các tính năng, lần này với thử nghiệm đơn vị. Tuy nhiên, điều này cuối cùng có giá trị không nếu tôi sẽ sử dụng lại các thành phần trong quá khứ không có bài kiểm tra đơn vị?
Tôi có cần phải viết bài kiểm tra đơn vị cho tất cả các lớp trước đó không và không bận tâm, hoặc chỉ có thể viết bài kiểm tra đơn vị cho nội dung mới mà tôi đang thêm không?
Câu trả lời:
Bất kỳ bài kiểm tra đơn vị là tốt hơn không có. Vì vậy, nó không phải là một thỏa thuận tất cả hoặc không có gì.
Trong trường hợp của bạn, vì Phát triển hướng thử nghiệm không phải là tiêu chuẩn - bạn sẽ tự hỏi làm thế nào các thử nghiệm được sử dụng.
Bạn muốn đảm bảo rằng bất kỳ mã nào trong tương lai bạn viết không phá vỡ bất kỳ chức năng (hiện tại) nào - và đó là nơi các trường hợp phụ của bạn có ích. Nếu các bài kiểm tra viết tốt vượt qua, rất có thể bạn đã không làm hỏng bất cứ điều gì. Nhà phát triển tiếp theo đi cùng sẽ cảm ơn bạn về các bài kiểm tra và tài liệu.
Những gì bạn có thể bắt đầu là nếu bạn có một kiến trúc phân lớp tốt, chọn các tầng truy cập dữ liệu và làm việc lên (hướng tới lớp UI) với các bài kiểm tra. Nếu dự án có một mô hình miền thì ứng cử viên có khả năng nhất cho TDD là có khả năng có hầu hết logic. Nếu tầng dịch vụ (hoặc logic nghiệp vụ) chỉ thực hiện cuộc gọi đến tầng Truy cập tên miền / Dữ liệu thì không có điểm nào thực hiện tầng Dịch vụ theo kiểu TDD. Đó là những bài kiểm tra lông và không có nhiều giá trị.
Đã thêm vào một công cụ bao phủ mã như Emma - và bạn có thể theo dõi đều đặn sự cải thiện trong phạm vi kiểm tra tổng thể.
Tôi đã làm việc trên một cơ sở mã rất lớn mà ban đầu không có bài kiểm tra đơn vị. Bằng cách làm theo một vài thực tiễn, chúng tôi bây giờ (sau vài năm) có hầu hết các cơ sở mã được kiểm tra.
Tất cả các mã mới phải có bài kiểm tra đơn vị.
Tất cả các mã thay đổi phải có các bài kiểm tra đơn vị được thêm vào nó.
Cách mà chúng tôi đã thêm các thử nghiệm vào mã cũ một cách an toàn mà không phá vỡ nó chủ yếu là sử dụng phương pháp cơ bản sau:
Chọn một phần nhỏ của mã mà bạn cần thay đổi chức năng của.
Giới thiệu các giao diện bạn cần để có thể kiểm tra mã bạn đang thay đổi. Sử dụng các kỹ thuật Tái cấu trúc bao gồm các chuỗi thay đổi rất nhỏ mà bạn có độ tin cậy cao là chính xác. Cố gắng sử dụng công cụ hỗ trợ nếu có thể. Bạn có thể làm điều này bằng cách, ví dụ, di chuyển / trích xuất phương thức bạn đang thay đổi vào đối tượng của chính nó. Kiểm tra các thay đổi của bạn thường xuyên để bạn có thể hoàn nguyên. Thường xuyên xem xét lại cách bạn thực hiện các thay đổi bằng cách đi qua lịch sử kiểm soát sửa đổi.
Cố gắng thực hiện tối thiểu về các thay đổi được yêu cầu để phá vỡ các phụ thuộc đang ngăn bạn thêm các bài kiểm tra.
Chúng tôi thấy rằng chúng tôi càng làm điều này, nó càng dễ dàng hơn. Như mỗi lần bạn quay lại cơ sở mã, nó sẽ tốt hơn một chút.
Chúng tôi đã chứng kiến sự sụt giảm lớn về số lượng lỗi thông qua người kiểm tra QA của chúng tôi. Với các hồi quy chức năng hiện nay gần như chưa từng nghe thấy, vì vậy tôi nghĩ rằng nó đáng để nỗ lực cho chúng tôi.
(vì thiếu khả năng bình luận) Tôi nghĩ tốt hơn là không kiểm tra gì cả. Không phải mọi đoạn mã cần phải được kiểm tra, nhưng cuối cùng chỉ những gì sẽ được lập trình viên sử dụng. Kiểm tra các chức năng sử dụng mà bạn sử dụng nội bộ là tốt, nhưng không bắt buộc nếu bạn truy cập mọi thứ thông qua API sạch sau đó.
Nếu các công cụ cũ đã hoạt động tốt trong nhiều năm, việc tạo các bài kiểm tra đơn vị bây giờ là không bắt buộc trừ khi bạn thay đổi một cái gì đó trong các công cụ cũ. Dù sao, viết bài kiểm tra đơn vị cho các phần mới hoàn toàn không phải là vô nghĩa. Các bộ phận mới là những bộ phận có khả năng chứa lỗi nhất và chúng cũng là bộ phận có khả năng bị thay đổi hoặc tái cấu trúc nhiều nhất.
Bạn có thể bắt đầu bao gồm mã hiện tại của mình và, nếu bạn có thời gian để sử dụng, hãy bắt đầu trình bày chức năng cốt lõi của mã cũ. Ngoài ra, bạn có thể yêu cầu PM của mình thêm thời gian cho việc đó =)
Là đơn vị thử nghiệm 100% hay không ở tất cả các loại thỏa thuận?
Tuyệt đối không! Bắt đầu thử nghiệm mã mới mà bạn đang thêm. Bạn sẽ thấy những lợi ích to lớn từ việc đó, ngay cả khi một số thành phần cũ không có thử nghiệm. Khi bạn phải đối phó với một trong những thành phần đó, hoặc tìm thấy một lỗi trong đó, hãy viết một bài kiểm tra. Theo thời gian, bạn sẽ nhận được nhiều mã cũ hơn đang thử nghiệm.