Test Driven Development là gì
Test Driven Development, viết tắt là TDD, là một phương pháp phát triển phần mềm mà trong đó bạn sẽ viết test trước cho tính năng mà bạn muốn phát triển. Dĩ nhiên là test sẽ thất bại trong lần chạy đầu tiên, và sau đó bạn sẽ hoàn thiện đoạn code tính năng để test có thể thành công. Bạn chưa cần phải viết đoạn code hoàn hảo nhất, miễn là làm cho test thành công. Một khi đã thành công, bạn có thể refactor lại một cách an toàn.
Khi thực hiện TDD bạn cần phải vượt qua được cám dỗ viết test sau khi hoàn thành tính năng. Áp lực đến từ khách hàng có thể làm bạn quên mất đi việc viết test. Đầu tiên là bạn cần cho họ hiểu lợi ích của test, và sau đó là những lợi ích kèm theo của TDD thì bạn mới có được thời gian để thực hành TDD đúng chuẩn mực.
Những lợi ích
1. Những tiêu chí chấp nhận (Acceptance Criteria)
Khi bạn đang viết một đoạn code mới, bạn thường có một danh sách những đặc điểm bắt buộc. Bạn có thể sử dụng những đặc điểm này làm công cụ để biết được bạn cần test những gì. Ngay khi bạn có được danh sách như vậy dưới dạng test code, bạn có thể an tâm rằng mình sẽ không bỏ qua những tiêu chí chấp nhận mà khách hàng đưa ra.
2. Tập trung
Bạn sẽ trở nên năng suất hơn khi code, và TDD giúp bạn giữ năng suất của mình cao bằng việc giới hạn sự tập trung của bạn. Bạn sẽ viết một đoạn test thất bại, và sẽ tập trung cao độ để làm cho đoạn test đó được thành công. Điều đó bắt buộc bạn nghĩ tới những tính năng nhỏ nhất vào một thời điểm hơn là nghĩ về tổng thể hệ thống, và sau đó bạn có thể tập trung vào việc làm cho test thành công, hơn là dành nhiều tâm sức để nhìn vào bức tranh tổng thể ngay từ lúc đầu, điều mà sẽ dẫn đến nhiều bugs và nhiều thời gian dành cho việc phát triển. Add New
3. Interfaces
Bạn sẽ viết test cho một tính năng, viết test trước có nghĩa là bạn sẽ phải dành thời gian suy nghĩ về public interface mà các đoạn code khác trong hệ thống cần tích hợp cùng. Bạn sẽ không nghĩ tới những private methods hoặc là xử lý nội bộ ra sao. Dưới góc nhìn của một đoạn test, bạn sẽ chỉ viết những đoạn gọi method để test public methods. Điều này có nghĩa là code sẽ dễ đọc và dễ hiểu hơn.
4. Code gọn gàng hơn
Tiếp theo từ ý trên, vì đoạn test của bạn sẽ chỉ chạm vào public methods, cho nên bạn sẽ có cái nhìn rõ ràng hơn về method nào cần khai báo là private, có nghĩa là bạn sẽ không vô tình để lộ ra method mà không cần thiết phải là public. Nếu bạn không thực hành TDD, và bạn để một method là public, có nghĩa là bạn có thể sẽ phải hỗ trợ chức năng đó trong tương lai và bạn đã tạo thêm việc cho mình vì một method mà chỉ nên sử dụng nội bộ của một class.
5. Dependencies
Đoạn code mới của bạn có dependencies không? Khi bạn viết test, bạn sẽ có thể mock những dependencies mà không phải lo lắng về việc chúng sẽ làm gì ở phía sau cánh gà, điều mà sẽ giúp cho bạn tập trung vào logic của class bạn đang viết. Một điểm cộng nữa đó là những dependencies mà bạn mock sẽ giúp test chạy nhanh hơn vì những depedencies thật sự nhưfilesystem, network hay database sẽ không cần được sử đụng đến.
6. Refactor an toàn hơn
Ngay khi bạn làm cho test thành công, vậy là bạn có thể refactor code mình một cách an toàn rồi. Nếu bạn phải làm việc với legacy code, hay code được viết bởi người khác, và không có test, bạn vẫn có thể thực hành TDD. Thay vì bạn nghĩ rằng bạn sẽ chỉ TDD đoạn code mà bạnđã viết, thì bạn hãy nghĩ rằng bạn sẽ TDD cho đoạn code mà bạn sắp viết. Vậy thì khi bạn thừa kế đoạn code của người khác, trước khi bắt đầu, hãy viết test mà bao quát được càng nhiều càng tốt. Điều đó giúp bạn có cơ sở vững chắc để refactor, hay thậm chí là thêm tính năng mới, mà lại không lo rằng bạn đã làm hỏng cấu trúc nguyên bản.
7. Ít Bugs hơn
TDD sinh ra nhiều test, điều mà có thể dẫn tới thời gian chạy test lâu hơn. Tuy nhiên, với độ bao phủ test tốt, bạn có thể tiết kiệm thời gian mà bạn sẽ dùng để sửa bug. Điều này không có nghĩa là bạn sẽ có thể nghĩ tới tất cả test case, mà có nghĩa rằng nếu có một bug xuất hiện, bạn vẫn có thể viết một đoạn test trước khi tìm cách sửa nó, điều đó sẽ đảm bảo là bug sẽ không xuất hiện nữa. Điều này cũng giúp bạn chỉ ra rõ bug đó xuất phát từ đâu và tái hiện lại các bước được.
8. Increasing Returns
Chi phí cho TDD sẽ cao hơn lúc đầu, khi bạn so sánh với việc không viết test, mặc dù dự án không yêu cầu viết test ban đầu sẽ kết thúc bằng việc tốn kém hơn. Bởi vì không có độ bao phủ test tốt, hay không có, sẽ làm những dự án đó phát sinh bugs tiềm ẩn và tốn nhiều thời gian để sửa bugs. Ngoài ra, TDD còn giảm chi phí cho việc thay đổi vì những test được viết trước sẽ đảm bảo rằng những thay đổi mới sẽ không phá vỡ những chức năng đã có.
9. Một tài liệu sống
Test có thể đóng vai trò như tài liệu cho một lập trình viên. Nếu bạn không rõ một class hay một library hoạt động ra sao, hãy đọc qua test của chúng. Với TDD, test thường được viết cho nhiều trường hợp, một trong đó có thể là bạn muốn sử dụng class ra sao. Vì vậy bạn có thể hiểu được yêu cầu của input mong muốn cho một method và bạn có thể kỳ vọng output thông qua những test so sánh.
