10 lí do nên tránh phát triển hướng kiểm thử

Theo quan điểm của tôi thì Phát triển hướng kiểm thử (Test Driven Development – TDD) và tất cả những phương pháp bắt nguồn từ TDD (BDD, ATDD) rất tốt để lèo lái sự cố gắng của team trong việc phát triển (development), và nâng cao chất lượng của sản phẩm. Nhưng TDD không phải là một viên đạn bạc. Nó không phù hợp với tất cả dự án. Bài viết sau đây liệt kê 10 lí do quan trọng nhất để bạn không nên viết kiểm thử tự động cho mã nguồn của bạn .

Nếu bạn gặp một trong những trường hợp dưới đây thì nên cân nhắc khi dùng TDD và bất kỳ kỹ thuật linh hoạt nào, bởi vì chúng làm chỉ làm lãng phí những nỗ lực để thực hiện nó:

10. Dự án không có khách hàng

Đôi khi bạn sẽ phát triển một sản phẩm mà không ai sử dụng. Trong trường hợp này, mọi nỗ lực nhằm nâng cao chất lượng sản phẩm là hoàn toàn lãng phí. Chẳng ai quan tâm đến điều đó cả.

9. Khách hàng là 1 kiểm thử viên năng nổ

Đối với một vài người, không có gì thích thú hơn là một bản beta (thử nghiệm) của sản phẩm mới. Họ sống với niềm vui là tìm kiếm những lỗi mới (bugs) và cố gắng chỉ ra những sai sót. Một số khác có trái tim của nhà khoa học, họ thì thích vượt qua ngăn xếp dấu vết (stack traces) để tìm lại mã nguồn. Nếu ngẫu nhiên bạn có một khách hàng như trên, thì viết những kiểm thử tự động sẽ đánh mất sự thích thú của họ khi sử dụng phần mềm. Đừng làm điều đó!

8. Đó là một dự án ngắn, đơn giản và rõ ràng

Nếu nhóm của bạn có thể hoàn thành dự án trong một thời gian ngắn (không nhiều hơn vài tuần) và sẽ không cần phải bảo trì, thì việc đầu tư thời giao và sức lực vào việc tạo ra khả năng bảo trì dễ dàng, tái sử dụng và mở rộng là lãng phí.

7. Thiết kế của bạn vốn đã tuyệt vời

Khi không có phương án nào khác để cải thiện thiết kế của bạn và nó cũng không có nhu cầu mở rộng. TDD xuất phát từ luồng phát triển tăng trưởng và kiến trúc có khả năng mở rộng; đơn giản là tạo ra cho bạn có thể mở rộng kiến trúc từ TDD. Do vậy áp dụng TDD sẽ giống như vẽ son môi cho một con heo, là một cái gì đó không cần thiết.

6. Tài liệu của bạn cũng hoàn hảo

Bạn không bao giờ không hiểu một API, bất cứ thay đổi nào mà bạn thực hiện với phần mềm đều ngay lập tức được cập nhật vào tài liệu. Các bản kiểm thử được tạo ra với TDD cũng giống như một hình thức tài liệu, một ví dụ cho việc làm thế nào để sử dụng API đó. Đặt tên đúng cách và các trường hợp kiểm thử đã thật sự giải thích những bối cảnh của kiểm thử, nó đã cho bạn thấy một cách dễ dàng những gì mà bạn đang cần phải hiểu. Tài liệu của bạn như vậy đã hoàn chỉnh, do đó viết kiểm thử vi phạm rõ ràng về nguyên tắc DRY, vì vậy không nên sử dụng kiểm thử.

5. Nhóm của bạn không bao giờ thay đổi và tất cả đều có trí nhớ tuyệt vời

Nhóm không bao giờ quên một dòng code nào đã viết, cũng như hoàn cảnh khi viết ra chúng. Do đó, không cần các bài kiểm thử để nhắc lại với bạn rằng những đoạn code này làm công việc gì, tại sao nó làm điều đó hoặc làm thế nào để sử dụng. Cũng chính vì lẽ đó mà các thành viên không bao giờ rời nhóm, và cũng không tuyển thêm người mới, bởi vì nếu như điều đó xảy ra, bạn sẽ mất một vài thông tin từ người khác, hoặc có những thành viên nào đó không nhớ nổi về mã nguồn (không ở đó khi nó được viết ra). Nếu là trường hợp này, đừng bận tậm với các bài kiểm thử; chúng sẽ chỉ cản trở tốc độ đáng kinh ngạc của bạn.

4. “Hoàn thành” cũng có nghĩa mã nguồn đã được bàn giao

Một số nhóm có một bản Định nghĩa hoàn thành (Definition of Done – DoD), có nghĩa rằng tính năng được “hoàn thành” khi nó ở trạng thái mà người dùng nhận và chạy (viết mã, kiểm thử, phát triển,tài liệu hóa, …). Tuy nhiên một vài nhóm khác, bao gồm cả nhóm của bạn, thích thú với một định nghĩa đơn giản và dễ dàng đạt được rằng “bàn giao” giống như “hoàn thành”. Lúc đấy bạn cho rằng nhà phát triển nào đó quả quyết anh ta hay cô ta đã hoàn thành phần việc của mình là đủ, còn những thứ khác là trách nhiệm của người khác. Nếu chủ sản phẩm/người quản lí/người dùng chấp nhận mã nguồn không cần được kiểm thử, bạn sẽ chuyển sang tính năng mới sớm hơn, thay vì kéo dài thời gian đối với tính năng đó.

3.Bạn được trả tiền để code, không phải để kiểm thử

Bỏ qua thực tế rằng kiểm thử đơn vị (unit tests) cũng là code, chúng tôi có những kiểm thử viên (testers) cho việc kiểm thử. Có lẽ nhóm kiểm thử viên của bạn đủ nhanh để có thể kiểm thử mã nguồn và phản hồi lại chỉ trong giây lát, chỉ rõ ra những vị trí mà mã nguồn có vấn đề. Vì thế bạn chỉ cần sửa chữa lỗi đó ngay khi bạn nhận thấy những điều cần thay đổi, cũng giống như sửa ngược lại sản phẩm khi bạn đã làm lỗi cái gì đó trong một thành phần khác mỗi tối (họ không ngại làm việc về đêm, mà lại rất thích sự tĩnh lặng). Tốt cho bạn, hãy yêu mến những kiểm thử viên đó, đảm bảo là họ có đủ công việc để làm và sẽ không cảm thấy chán nản để quyết định rời đến một công ty khác thử thách hơn.

2. Việc gỡ lỗi không được tính đến, kiểm thử thì quá lâu

Cũng giống như bất kì công ty có tính cạnh tranh nào, nhóm của bạn cũng cần phải đúng thời hạn , có nghĩa là cần phải ước tính thời gian phát hành. Vì DoD của bạn không bao gồm kiểm thử, nên có khả năng bạn không đoán được thời gian để gỡ lỗi – điều mà bạn phải làm khi QA. Nếu muốn đảm bảo cam kết, bạn cần thêm 20% thời gian bàn giao hoặc chậm thời hạn kết thúc. Tệ hơn nữa, nếu bạn tăng ước lượng thêm 20%, người quản lí sẽ gọi ngay cho bạn về bước đệm dự tính đó vì đấy là công việc của ông ấy. Nếu điều đó xảy ra, ai biết được những gì có thể xảy đến? Tốt hơn là chơi một cách an toàn.

1. Nếu đó chỉ là lý thuyết

Giống như Tiến hóa (và Vạn Vật Hấp Dẫn), đó cũng chỉ là một lí thuyết. Khi tất cả những lí do trên đều không phù hợp, chưa ai chứng minh được rằng sản phẩm này có thể được hoàn thành nhanh hơn và có chất lượng tốt hơn khi sử dụng một phương pháp phát triển mới mẻ như TDD. Đấy chỉ là 1 quan điểm.

Tự kiểm tra

Ngay bây giờ, kiểm tra xem bạn có nên sử dụng phương pháp phát triển hướng kiểm thử hay không, hãy đi qua từng mục trong danh sách trên, đếm xem có bao nhiêu lý do áp dụng với bạn. Nếu bạn được 10 điểm, đừng sử dụng TDD. Trong thực tế, số điểm của bạn nhiều hơn một (lí do #8 có thể thật sự là hợp lí) , đừng viết code nữa. Không chừng bạn muốn được chọn lựa chọn một công việc tốt hơn với ít ẩn số và thay đổi. Có lẽ nên mở đường chăng?

Bài viết được dịch từ: www.softwareandi.com

Người dịch: Trần Lê Hưng