Tôi muốn giới thiệu khái niệm về kiểm tra đơn vị (và kiểm tra nói chung) cho các đồng nghiệp của tôi; ngay bây giờ không có bài kiểm tra nào cả và mọi thứ được kiểm tra bằng cách thực sự thực hiện các tác vụ thông qua UI để xem kết quả mong muốn. Như bạn có thể tưởng tượng, mã được kết hợp rất chặt chẽ với việc triển khai chính xác - thậm chí dẫn đến mã phải nằm trong một lớp và được sử dụng lại trên toàn hệ thống được sao chép và dán qua các phương thức.

Do yêu cầu thay đổi, tôi đã được yêu cầu sửa đổi một mô-đun mà tôi đã viết trước đó và nó được ghép khá lỏng lẻo (không nhiều như tôi muốn, nhưng tốt nhất tôi có thể nhận được mà không phải giới thiệu nhiều khái niệm khác). Tôi đã quyết định bao gồm một bộ thử nghiệm đơn vị với mã sửa đổi của mình để "chứng minh" rằng nó hoạt động như mong đợi và chứng minh cách thử nghiệm hoạt động; Tôi không theo dõi TDD thực sự vì một số mã đã được viết nhưng tôi hy vọng sẽ tuân theo một số khái niệm TDD cho mã mới mà tôi phải tạo.

Bây giờ, chắc chắn tôi chắc chắn tôi sẽ được hỏi tại sao tôi phải mất hơn một hoặc hai ngày để viết mã, vì các phần của những gì tôi sẽ tương tác đã tồn tại trong hệ thống (mặc dù không có bất kỳ thử nghiệm nào và rất chặt chẽ được ghép nối) và khi tôi kiểm tra mã trong tôi sẽ được hỏi dự án "Thử nghiệm" này là gì. Tôi có thể giải thích các vấn đề cơ bản của thử nghiệm, nhưng tôi không thể giải thích các lợi ích thực tế theo cách mà người khác sẽ hiểu (vì họ nghĩ rằng thử nghiệm yêu cầu bạn phải tự chạy ứng dụng, vì thường UI thực sự quan trọng trong việc xác định xem tính năng "có hoạt động không " hay không). Họ không hiểu ý tưởng về khớp nối lỏng lẻo (hiển nhiên rõ ràng bởi thực tế không có gì được ghép lỏng lẻo; thậm chí không có bất kỳ giao diện nào bên ngoài mã tôi đã viết), Vì vậy, cố gắng sử dụng nó như một lợi ích có thể sẽ kiếm cho tôi một "Huh?" Kiểu nhìn, và một lần nữa tôi không thể lỏng lẻo như tôi muốn mà không phải làm lại một số mô-đun hiện có và có thể giới thiệu một số loại container IoC, sẽ bị xem là lãng phí thời gian và không "lập trình".

Có ai có bất kỳ đề xuất nào về cách tôi có thể chỉ ra mã này và nói "Chúng ta nên bắt đầu tạo các bài kiểm tra đơn vị" mà không bị từ chối (ví dụ: "Kiểm tra viết buộc bạn phải viết mã tốt." ngoại trừ của tôi là xấu ) hoặc không làm cho nó có vẻ như lãng phí thời gian mà không thêm bất kỳ giá trị thực sự?

Tôi muốn giới thiệu khái niệm về kiểm tra đơn vị (và kiểm tra nói chung) cho các đồng nghiệp của tôi

Tôi nghĩ rằng có thể tốt hơn để bắt đầu từ thực tế, không phải là khái niệm ,. Tất nhiên, nếu bạn thấy trong cuộc thảo luận ngẫu nhiên rằng đồng nghiệp và / hoặc quản lý của bạn quan tâm đến việc nghe thử nghiệm đơn vị, thì tốt hơn - sau đó bạn có thể tìm kiếm một số kinh nghiệm / bằng chứng cụ thể từ web, tập hợp một khóa đào tạo ngắn, v.v. Tuy nhiên, từ những gì bạn mô tả, có vẻ như đồng đội của bạn không cởi mở với ý tưởng mới lạ này.

Trong tình huống như vậy, tôi sẽ chỉ bắt đầu viết bài kiểm tra đơn vị nhỏ của mình mà không cố gắng giải thích quá nhiều cho bất cứ ai trước. Thêm một vài trong số chúng bất cứ khi nào tôi thay đổi mã, mà không cố gắng bao quát triệt để tất cả mã (sẽ mất một lượng thời gian không phù hợp). Lý tưởng nhất là nếu tôi xoay sở để đạt được số dư tốt, vào thời điểm họ nhận thấy tôi đang viết bài kiểm tra đơn vị, tôi có thể đã có một bộ kiểm tra đáng kể và một số kết quả cụ thể để hiển thị (như "với trường hợp kiểm tra này, tôi đã gặp phải lỗi được giới thiệu bởi sự thay đổi của tuần trước, nếu không sẽ chuyển sang QA / sản xuất "). Điều đó sẽ chứng minh giá trị của các thử nghiệm đối với bất kỳ nhà phát triển nghiêm túc nào.

Sau đó, tôi đang ở một vị trí tốt để bắt đầu giải thích những lợi ích lâu dài của thử nghiệm đơn vị, như

• nó chứng minh rằng mã hoạt động - mọi lúc, mọi nơi, ngay lập tức và tự động, lần lượt
• mang lại sự tự tin cho cấu trúc lại, dẫn đến thiết kế được cải thiện và khả năng bảo trì tốt hơn,
• và nếu một cái gì đó bị hỏng, các bài kiểm tra đơn vị cung cấp cho bạn (gần như) phản hồi tức thì, trái ngược với độ trễ vài ngày hoặc vài tuần nếu lỗi được phát hiện bởi một bộ phận QA riêng biệt. Việc này thường cho phép bạn sửa lỗi trong vài giây, thay vì gỡ lỗi hàng giờ / ngày, trong mã đã bị loại bỏ khỏi bộ nhớ ngắn hạn của bạn.

Xem thêm chủ đề liên quan này: Kiểm tra đơn vị tự động, kiểm tra tích hợp hoặc kiểm tra chấp nhận .

Và một cái trước đó từ SO: thử nghiệm đơn vị là gì?

Yếu tố lại mà không sợ hãi

Ở một góc độ hơi khác, TDD cho phép bạn "tái yếu tố mà không sợ hãi" và đây là một lợi ích chính mà bạn có thể bán cho nhóm của mình. Nó ngăn các nhà phát triển nói với chính họ:

• "Tôi không muốn chạm vào mã này vì tôi sợ tôi sẽ phá vỡ nó"
• "Tôi không muốn viết chức năng mới vào mã này vì tôi không biết nó hoạt động như thế nào"
• "Bí mật, tôi sợ mã đó"

Tôi có thể đàn hạc nhiều hơn, nhưng đây là mặt đất được che phủ tốt như chú Bob trên TDD và Martin Fowler trên TDD .

Phụ thuộc

Ồ, tôi sẽ thêm một điều nữa. Nó sẽ cho họ thấy TDD buộc thiết kế tốt cho phép bạn xử lý sạch các phụ thuộc như thế nào.

Bob: "Oh c% ^ p! Các ông chủ chỉ buộc tất cả chúng tôi sử dụng MS SQL Server 2008" Jane: "Không sao, thiệt hại giảm thiểu vì chúng tôi DI nguồn dữ liệu và các lớp DAO của chúng tôi, tôi rất vui vì TDD khuyến khích chúng tôi xuống con đường đó. "

Trong khi làm việc với mã nguồn không có kiểm tra tự động, chúng tôi phải làm việc rất cẩn thận và cần thêm đánh giá để tự tin rằng loại thay đổi mà chúng tôi đang thực hiện không phá vỡ bất kỳ chức năng hiện có nào.

Khi chúng tôi có các trường hợp kiểm tra tự động tốt, hậu quả sẽ phát triển nhanh hơn, tự tin và không sợ hãi (đó có thể là sửa lỗi, nâng cao hoặc tái bao thanh toán).

Làm toán

• t _mt = thời gian cần thiết để kiểm tra thủ công mọi thứ bạn có thể tưởng tượng có thể ảnh hưởng
• t _wt = thời gian cần thiết để viết bài kiểm tra

• k = số lần bạn có thể phải kiểm tra mọi thứ trước khi phát hành mã mới

  if (t _wt <t _mt ) hoặc (t _wt <(k * t _mt )) thì đó là điều không tưởng: viết các bài kiểm tra sẽ tăng tốc độ phát triển.

mặt khác nhìn vào tỷ lệ (t _wt / (k * t _mt )). Nếu đó là một con số rất lớn thì hãy chờ cơ hội khác; mặt khác biện minh với lợi ích kiểm tra hồi quy.

Lưu ý: Tại thời điểm này, tôi đề nghị chỉ kiểm tra các tính năng, không phải đơn vị - dễ dàng biện minh và hiểu hơn, và có thể làm việc ít hơn với giá trị cao hơn so với kiểm tra đơn vị khi tái cấu trúc.

Lưu ý 2: thời gian để chạy thử nghiệm không thành vấn đề , vì chúng tự động. Bạn có thể làm một cái gì đó hiệu quả trong khi các bài kiểm tra chạy, trừ khi các bài kiểm tra mất quá nhiều thời gian để chạy mà chúng sẽ khiến bạn bỏ lỡ thời hạn. Điều này là hiếm.

Một đề xuất nếu bạn là một cửa hàng của Microsoft: tìm một số tài liệu về MSDN khuyến nghị thử nghiệm đơn vị hoặc ghép lỏng lẻo là cách tốt nhất (tôi chắc chắn có nhiều trường hợp này ) và chỉ ra nếu có xung đột.

Nghe có vẻ như là một cách làm việc thô bỉ, nhưng tôi đã thấy rằng việc sử dụng thuật ngữ 'thực hành tốt nhất' sẽ đưa bạn đi một chặng đường dài đặc biệt là với quản lý.

Như tôi luôn khuyên, nếu bạn biết về một thực tiễn tuyệt vời, cách tốt nhất để giới thiệu nó một cách nhẹ nhàng vào môi trường của bạn tất nhiên là bắt đầu tự thực hiện và sau đó ở đâu đó, một số đồng nghiệp của bạn sẽ thấy những lợi ích và nhặt nó lên.

Từ khóa ở đây là sự tiến hóa, không phải là cuộc cách mạng.