Giải đáp thắc mắc TDD là gì? Kiến thức tổng quan về TDD?

1. Lý giải TDD là gì?

TDD có nghĩa là “Test-Driven Development”, nói một cách dễ hiểu, đây là một mô hình phát triển mà mục tiêu của nó hướng về việc kiểm thử (test oriented). 

TDD được phát triển phần mềm từ Test case. Chi tiết hơn, Test case sẽ kiểm tra trước khi code, nếu Test case fail thì development sẽ check lại và update, nhiệm vụ của TDD chính là giúp cho viết code ra được chính xác, và rõ ràng hơn. TDD là một quy trình kiểm tra tự động trước khi phát triển ứng dụng, cho nên vì vậy, nhiều người còn gọi nó bằng cái tên “Test First Development”.

TDD được xây dựng lên từ 2 tiêu chí cơ bản: là Test First (Kiểm thử) và Refactoring (Điều chỉnh mã nguồn). 

TDD được hoạt động như thế nào? Khi một requirement được đặt ra:

Bước 1:  Developer viết một kịch bản kiểm thử test case cho hàm mới (đảm bảo hàm này sẽ fail) -> Thực hiện kiểm thử thất bại vì chức năng đó chưa được xây dựng. 

Bước 2: Dựa vào expectation của kịch bản trên, viết một đoạn code sơ khai nhất cho hàm đó, nhưng đảm bảo được kiểm thử sẽ được pass qua

Bước 3: Thực hiện tối ưu hóa lại code vừa viết cho hàm trên, đảm bảo được code sẽ pass và tối ưu nhất cho lập trình

Bước 4: Lặp lại cho các hàm khác từ bước 1

Xem thêm: Tổng hợp công việc nhập mã code và những điều mà bạn nên biết

2. Điểm khác biệt giữa TDD và mô hình testing truyền thống?

Dựa vào các bước đã được đưa ra ở bên trên, các bạn có thể dễ dàng nhận thấy, quy trình của TDD gần như là đảo ngược hoàn toàn so với một mô hình testing truyền thống. Vậy bạn nghĩ các này sẽ tối ưu hơn hay không?

Cùng mục đích chung với kiểm thử truyền thông, việc đặt ra là tìm ra được lỗi, có lỗi thì đồng nghĩa với việc kiểm thử vẫn đang diễn ra theo đúng tiến trình, và bạn sẽ biết được, bạn cần phải giải quyết vấn đề ở đâu.

Đầu tiên, đi phân tích mô hình truyền thống. Bạn sẽ nhận thấy ở một mô hình thác đổ Waterfall Model, đầu tiên việc phân tích requirement sẽ được thực hiện bởi Business Analyst, sau đó đến giai đoạn Implementing phase (hay gọi là giai đoạn xây dựng) thì developer sẽ được tiếp nhận các yêu cầu dưới dạng bản thiết kế. Mô hình truyền thống này sẽ tập trung nhiều vào phần test case. Như vậy, các bạn có thể thấy, họ đang thiếu đi cái nhìn thực tế đến từ phía của người dùng, của end user, họ chỉ chú trọng đến Input và Output mà thôi. Vì thế, trường hợp tất yếu có thể xảy ra đó là phần mềm không thân thiện với người dùng, bị lỗi,...Ngược lại, TDD là một cách tiếp cận kiểu mới, là một kỹ thuật đảm bảo cho việc mã nguồn của bạn luôn kiểm tra kỹ lưỡng ở mức độ xác nhận được. TDD tập trung nhiều vào production để đảm bảo cho việc kiểm thử là chính xác. Đối với mô hình này, mọi dòng code của bạn đều được test. Hay nói một cách nôm na đó là, đối với mô hình TDD, khoảng cách giữa đội thiết kế phần mềm và sản phẩm thực tiễn được gần nhau hơn và tối ưu được quy trình. Vì:

+ Dựa vào kịch bản kiểm thử, developer có thể hình dung ra được sản phẩm như nào trước khi xây dựng nên mã nguồn. Điều này sẽ làm cho sản phẩm cuối cùng thân thiện với người dùng hơn.

+ Phần mã nguồn được developer đưa vào vừa đủ để chạy kịch bản kiểm thử, tránh có thêm phần dư thừa dẫn đến lỗi không cần thiết.

+ Chắc chắn rằng mã nguồn được xây dựng đáp ứng vừa đủ nhu cầu của sản phẩm, tránh việc mất thời gian chỉ để tối ưu lại đoạn mã nguồn về sau.

3. Cấp độ của TDD

Có 2 cấp độ của TDD mà bạn nên nhớ đó là: Acceptance TDD (ATDD) và Developer TDD. 

+ Mức độ 1: Acceptance TDD (ATDD). ATDD còn được gọi là Behavioral Driven Development (BDD). Mức độ chấp nhận hướng phát triển kiểm thử. Nhiệm vụ của bạn là viết một đoạn test chấp nhận đơn hoặc một đặc tả hành vi. Sau đó bạn viết code để kiểm thử đoạn test này. Mà test này chỉ cần đủ cho các mã của chương trình sản phẩm thực hiện.

+ Mức độ 2: Developer TDD, mức độ lập trình. Ở mức độ này, bạn chỉ cần viết một bài test lập trình đơn, và test này cũng chỉ cần đủ cho các mã của chương trình sản phẩm thực hiện.

Xem thêm: Việc làm IT phần mềm

4. Tại sao nên dùng TDD?

Như bạn có thể thấy từ những phân tích trên, TDD là mô hình đã được mở rộng hơn so với các mô hình truyền thống thông thường. Trong quá trình mà bạn viết test, được hình dung giống việc bạn đang nháp và xóa nháp đi nhiều lần vậy. Và chỉ cần sau một vài lượt nháp như vậy, thì bài toán và lời giải bài toán đó của bạn đã rất gần với thực tế.

4.1. Tư duy thay đổi

Trong trường hợp bạn gặp một bài toán thông thường, bạn sẽ tiến hành theo các bước như sau:

+ Bước 1: Phân tích đề và đưa ra câu hỏi yêu cầu

+ Bước 2: Hướng giải quyết yêu cầu đó

+ Bước 3: Đưa ra lời giải cụ thể

+ Bước 4: Thao tác (trên máy tính, được hiểu là lập trình)

Nghe những bước này, thoạt đầu bạn sẽ thấy rất hợp lý đúng không nào? Và bạn tưởng chừng như tiến trình sẽ rất suôn sẻ. Nhưng thật sự không phải vậy, khi bạn trực tiếp bắt tay vào làm thì bạn mới nhận thấy được nó còn có khá nhiều hạn chế. Thật vậy, người ta thường tốn rất nhiều thời gian vào việc phân tích 3 bước đầu tiên ở quy trình trên, vài ngày thậm chí tới vài tháng, mà thật sự bước 4 có cần nhiều kết quả ở 3 bước trên thế không?

4.2. Tiết kiệm thời gian

Có một câu hỏi được rất nhiều người đặt ra, đó chính là: “TDD thật sự mất nhiều thời gian, vì phải test trước khi viết cơ mà, sao lại nói tiết kiệm thời gian được?” 

Thực ra không hoàn toàn vậy. Như mình đã phân tích ở trên, thì TDD giống như là bạn đang viết nháp mà thôi, mà thậm chí khi giải quyết một bài toán, kể cả bạn có không nháp thì bạn vẫn phải nghĩ ở trong đầu thôi mà? Đúng không nào, chẳng qua là bạn chưa tính thời gian nghĩ đó vào tổng thể thời gian thôi. 

4.3. Dự phòng vẫn tốt hơn

Giống như câu nói “phòng bệnh hơn chữa bệnh”, test trước sẽ làm bạn đỡ tốn công chỉnh sửa. Lập trình viên nếu tuân thủ được các bước tiến hàng thì sẽ không mất thời gian để dò lỗi (nếu có) sau này mà thôi.

4.4. Lấy làm tư liệu

Đối với những nhà phát triển thì đặc biệt thích phần này, TDD chính xác là làm những việc làm như là đưa tài liệu viết code, thêm một vài comment trước những bài test,...

5. Công cụ phục vụ TDD

Có khá nhiều các công cụ để phục vụ TDD mà bạn có thể tham khảo, điển hình có thể kể đến vài cái tên như: CUnit, DUnit, DBUnit, DBFit, HTMLUnit, JUnit, OUnit, PHPUnit, SimpleTest, TestNG,... và một vài công cụ khác bạn có thể tìm hiểu nhé!

TypeScript là gì

6. Các lỗi thường gặp khi ứng dụng TDD

Song song với đó, vẫn còn tồn tại một số lỗi khi bạn áp dụng TDD. Tiêu biểu đó là:

+ Thường bỏ qua những test bị fail

+ Quên mất giai đoạn tối ưu sau khi viết code cho test pass hoặc thực hiện tối ưu code ngay khi đang viết

+ Đặt những cái tên cho test một cách tối nghĩa, gây khó hiểu

+ Viết kịch bản test quá phức tạp

+ Chỉ chạy mỗi các test đang bị fail hiện tại

TDD là một trong những kỹ thuật lập trình vô cùng quan trọng mà bạn nên biết. Hy vọng thông qua bài viết này, bạn có thể củng cố thêm kiến thức cho mình trong định hướng nghề nghiệp nhé.