TDD là 1 phương thức lập trình mà trong đó:

  • bạn phải duy trì 1 cách đầy đủ 1 bộ các Testcase.
  • không có một đoạn mã sản phẩm nào được tạo ra mà không thông qua các Test.
  • các Testcase phải được viết đầu tiên
  • các Testcase xác định những đoạn mã sản phẩm được tạo ra như thế nào.

1. Các bước áp dụng đơn giản

1.1. Ví dụ 1

1(1)

1.2. Ví dụ 2

2(1)

1.3. Ví dụ 3

Ví dụ 3

 

2. Tái cấu trúc mã nguồn Refactoring

2.1. Refactoring là gì?

Refactoring – tái cấu trúc – là quá trình làm thay đổi mã hiện có bên trong mà không thay đổi hành vi bên ngoài của nó. Nói cách khác, tức là thay đổi cách nó thực hiện, nhưng không không thay đổi nó làm cái gì. Mục đích là để cải thiện cơ cấu nội bộ.

Tái cấu trúc liên quan chặt chẽ đến TDD theo hai cách:

  • Sau khi thực hiện điều đơn giản nhất để thực hiện một chương trình kiểm tra (vi phạm bất kỳ / tất cả các quy tắc trong tiến trình), chúng ta cấu trúc lại để làm sạch, chủ yếu là loại bỏ trùng lặp mà chúng ta đã làm để pass 1 test.
  • Nếu chúng ta đang thực hành TDD, thì ta sẽ có một mạng lưới an toàn của các test cho phép chúng ta cấu trúc lại với sự tự tin và an toàn hơn. Vì khi tái cấu trúc, ta sẽ dựa trên các test đó để đảm bảo rằng không có 1 sự biến đổi nào về mục đích của đoạn code đó.

2.2. Khi nào thì thực hiện refactoring?

Nói chung, chúng ta cấu trúc lại bất cứ khi nào chúng ta cần. Tuy nhiên, có ba tình huống mà chúng ta phải cấu trúc lại:

  • khi có sự trùng lặp
  • khi chúng ta nhận thức rằng mã và / hoặc mục đích của nó là không rõ ràng
  • khi chúng ta phát hiện code smells (1 thuật ngữ để chỉ các đoạn mã tồi tệ), và đó xem như rằng có một vấn đề.

Code smells (code mà bốc mùi, hoặc có mùi lạ trong code) là bất kỳ triệu chứng bất ổn nào bên trong mã nguồn của một chương trình, mà vì nó có thể sẽ dẫn đến các vấn đề lớn hơn. Code smells không phải là bugs (lỗi lập trình), nghĩa là chúng không làm sai chứ năng của ứng dụng. Thay vào đó, chúng là biểu hiện của sự yếu kém trong thiết kế và sẽ làm cho quá trình phát triển ứng dụng bị chậm lại hoặc tăng nguy cơ của bugs hoặc lỗi trong tương lai.

2.3. Ví dụ về refactoring

5

6

7

2.4. Cách kiểm tra công đoạn refactoring

8

9

Link bài viết gốc: http://blog.co-mit.com/post/11/TDD