Phát triển được dẫn lái bởi kiểm thử – Test Driven Development (TDD) là thực hành Agile để khử bỏ thật nhiều lỗi có thể để cho người phát triển có thể thêm các tính năng hay thực hiện các thay đổi nhưng vẫn tạo ra phần mềm chất lượng cho mọi lần lặp.

Khái niệm này tương đối đơn giản. Người phát triển phải tạo ra các kiểm thử đơn vị cho mã của họ trước khi viết mã. Về truyền thống phần lớn người phát triển viết mã trước rồi mới phát triển kiểm thử đơn vị. Tuy nhiên trong cách tiếp cận này, người phát triển đầu tiên bắt đầu bằng kiểm thử đơn vị để kiểm nghiệm mã sẽ làm gì. Bằng việc tạo ra kiểm thử trước cho phép người phát triển hiểu nhiều hơn về mã mà họ sẽ viết. Bằng việc viết mã để chắc nó sẽ qua được kiểm thử, họ có thể khử bỏ lỗi và có phần mềm chất lượng cao.

Tất nhiên lúc ban đầu phần lớn người phát triển thường cảm thấy không thoải mái bởi vì họ được đào tạo viết mã trước, kiểm thử sau. Tuy nhiên, nếu họ tuân theo cách tiếp cận này, họ sẽ hiểu rõ sự đơn giản của nó. Việc gỡ lỗi truyền thống thường có nghĩa là nhìn qua nhiều mã để nhận diện lỗi. Cách tiếp cận dẫn lái bởi kiểm thử cho phép người phát triển hội tụ vào đơn vị nhỏ để chắc nó không có lỗi. Cách gỡ lỗi truyền thống yêu cầu nhiều thời gian để lập các điểm ngắt, các biến tạm thời và câu lệnh in rồi sẽ bị bỏ đi sau kiểm thử. Một khi người phát triển tìm ra và sửa lỗi, những trường hợp kiểm thử này thường bị bỏ đi. Trong pha bảo trì, những người phát triển khác có thể phải bắt đầu lại với kiểm thử riêng của họ, điều yêu cầu nhiều nỗ lực hơn. Với cách tiếp cận dẫn lái theo kiểm thử, mọi kiểm thử đơn vị đều được duy trì cho dùng về sau. Nếu lỗi xảy ra, cùng kiểm thử đơn vị đó có thể bắt được nó lần nữa. Nếu lỗi mới xảy ra và không có kiểm thử đơn vị tương ứng, người phát triển có thể viết kiểm thử đơn vị mới bắt nó và dùng lại cùng kiểm  thử này về sau trong pha bảo trì.

Những kiểm thử đơn vị nhỏ này có thể được tổ chức thành tập các kiểm thử đơn vị để phát hiện mọi lỗi cho từng lần đưa ra. Vì chúng đã kiểm thử cho mọi mã một cách kĩ lưỡng, phần mềm đưa ra vào lúc này thường có ít lỗi hơn nhiều so với kiểm thử tích hợp truyền thống.

—-English version—-

Test driven  development

Test Driven Development (TDD) is an Agile practice to eliminate as many defects as possible so developers can add features or implement changes but still produce quality software for every iteration.

The concept is relatively simple. Developers must create Unit tests for their code before they write code. Traditionally most developers write code first then develop Unit tests. However in this approach, developers begin first with a Unit test to validate what the code will do. By create the test first allows developers to understand more about the code that they will write. By writing code to make sure it will pass the test, they can eliminate defects and have high quality software.

Of course in the beginning most developers often feel uncomfortable because they are trained to write code first, test later. However, if they follow this approach, they will appreciate the simplicity of it. Traditional debugging often means looking through a lot of code to identify defects. Test driven approach allows developers to focus on a smaller unit to make sure it does not have bugs. Traditional debugging requires lot of time to set up break points, temporary variable and print statements which are thrown away after test. Once developer find and fix the bug, these test cases are often discarded. During the maintenance phase, other developers may have to start again with their own tests which require more efforts. With Test-driven approach, all Unit tests are maintained for later use. If a bug happens, the same Unit test that caught it can catch it again. If a new bug happens and there is no matching Unit test, developer can write a new Unit test that captures it and reuse the same test later during maintenance phase.

These small unit tests can be organized into a set of automated unit tests to detecting all bugs for each release. Since they already test all codes thoroughly, released software at this time usually has much less defects than the traditional integration test.