[TDD 01] Những điều cần biết về TDD (Test Driven Development)

Chất lượng phần mềm là một điều cần thiết

Hiện nay, nhu cầu phần mềm tăng lên đáng kể và nó đã trở thành một phần không thể thiếu trong cuộc sống hàng ngày của mọi người. Phần mềm chất lượng cao được xem như là một nhu cầu phải có hơn là nên có. Bên cạnh đó, khách hàng và người sử dụng càng chú trọng hơn về chất lượng của phần mèm mà họ mua. Các ứng dụng hay các hệ thống doanh nghiệp cho thấy những sản phẩm hiệu suất kém hoặc không đáp ứng được yêu cầu người dùng sẽ bị loại bỏ. Vậy nhiệm vụ trọng tâm của các công ty phần mềm là 'quan tâm đến chất lượng sản phẩm của họ'.

Để có phần mềm chất lượng cao bao gồm rất nhiều yếu tố, một trong những yếu tố hàng đầu là phải có đội ngũ có trình độ giám sát từ lúc bắt đầu và xuyên suốt quá trình dự án với một quy trình phầm mềm mang tính chiến lược.

Làm gì để lập trình tốt hơn?

Có rất nhiều phương pháp để đem lại cho chúng ta những “code” chất lượng như: việc sử dụng theo các mẫu thiết kế (Design patterns), lập trình cặp (pair programming), xem lại mã (code review), baby steps, refactoring v.v.. và TEST cũng là một yếu tố không thể thiếu để đem lại những mã lệnh có giá trị.

TDD là gì?

TDD là một phương pháp cải tiến cho các nhà phát triển phầm mềm chuyên nghiệp, giúp nâng cao năng suất và hiệu quả phầm mềm. TDD bao gồm sự kết hợp của hai thành tố: TFD - Test-First Development (Phát triển kiểm thử đầu tiên - tức là bạn cần phải viết ra các trường hợp kiểm thử trước khi viết mã lệnh) và Refactoring (Tái cấu trúc – thay đổi cấu trúc đoạn mã sau khi các kiểm thử được thực thi để cải tiến đoạn mã tốt hơn).

Chúng ta có thể hiểu theo cách khác TDD là một đặc tả hay kỹ thuật lập trình. Nói cách khác nó là một cách để tư duy thông qua các yêu cầu của bạn hoặc bản thiết kế trước khi mà bạn bắt tay vào viết mã lệnh. Trong quy trình phát triển phần mềm linh hoạt (Agile Software Development) TDD là một trong những tiến trình đóng vai trò quan trọng.

Tại sao nên sử dụng TDD để phát triển phần mềm?

TDD thường được sử dụng phát triển phần mềm một cách chuyên nghiệp, đặc biệt là khi kết hợp với mô hình phát triển phần mềm Agile, bởi TDD mang đến các lợi ích sau:

-       Hiểu đúng bài toán cần giải quyết

-       Hướng vào mục tiêu rõ ràng, tránh được việc viết những đoạn chương trình thừa

-       Các thành phần của chương trình làm đến đâu chắc chắn đến đấy do đó khả năng bảo trì, mở rộng và kế thừa cao.

-       Làm ví dụ minh hoạ cho nhà phát triển

Hình vẽ dưới đây so sánh sự khác biệt khi phát triển phần mềm sử dụng TDD so với mô hình truyền thống

Hình 1: So sánh giá trị mã lệnh khi sử dụng TDD với mô hình truyền thống

Trong hình 1, trục thẳng đứng biểu diễn chi phí phải trả cho viết mã lệnh khi sử dụng TDD ngay từ thời điểm đầu tiên thấp hơn rất nhiều so với chi phí sau khi mã viết mã lệnh xong rồi tiến hành viết chương trình kiểm thử, trục nằm ngang thể hiện thời gian phải bỏ ra để hoàn thành.

Khi tạo kiểm thử ngay đầu tiên, trước khi viết mã, bạn sẽ thấy việc viết mã dễ dàng và nhanh hơn. Tổng thời gian để viết kiểm thử, và mã để vượt qua kiểm thử xấp xỉ thời gian lập trình một cách trực tiếp. Nhưng nếu đã có kiểm thử đơn vị, bạn không cần phải tạo ra chúng sau khi viết mã, điều đó giúp tiết kiệm được nhiều thời gian hơn cho hiện thời và rất nhiều về sau.

Việc tạo kiểm thử đơn vị giúp nhà phát triển thực sự quan tâm tới những gì cần hoàn thành. Các yêu cầu bài toán được làm rõ thông qua kiểm thử. Không có sự hiểu sai một đặc tả bài toán ở mã thực thi.

Ngoài ra, các kiểm thử đơn vị sẽ gửi những phản hồi tức thì khi bạn làm việc. Những phản hồi thường không rõ ràng một khi nhà phát triển đã hoàn thành các chức năng cần thiết. Sự tăng đột biến về phạm vi như sự mở rộng hay điều kiện lỗi cần phải được xem xét. Nếu chúng ta tạo ra các kiểm thử đơn vị đầu tiên, thì khi tất cả các kiểm thử đơn vị chạy không có nghĩa là chúng ta đã hoàn thành.

Ngoài ra, kiểm thử đơn vị còn có lợi cho thiết kế hệ thống. Việc kiểm thử đơn vị các hệ thống phần mềm gặp khó khăn xảy ra rất thường xuyên. Những hệ thống này thường có mã xây dựng trước và mã kiểm thử triển khai sau – thường do một nhóm khác phát triển. Bằng cách tạo ra các kiểm thử đầu tiên, mong muốn kiểm tra mọi thứ có giá trị với khách hành sẽ ảnh hưởng tới thiết kế. Do đó thiết kế của bạn sẽ dễ kiểm thử.

Có nhịp để phát triển phần mềm với kiểm thử đơn vị trước. Bạn tạo ra một kiểm thử để xác định một khía cạnh nhỏ của vấn đề. Sau đó, bạn viết mã đơn giản nhất để vượt qua kiểm thử. Sau đó, bạn viết kiểm thử thứ hai. Và bây giờ, bạn thêm vào mã để hoàn thiện kiểm thử mà bạn vừa tạo ra. Bạn tiếp tục cho tới khi không còn vấn đề nào cần giải quyết nữa. Một ví dụ viết bằng Java: Các vấn đề của máy pha cà phê.

Mã mà bạn viết ra thật đơn giản và ngắn gọn, chỉ thực hiện các chức năng bạn muốn. Nhà phát triển khác có thể xem cách sử dụng mã mới thông qua các kiểm thử. Khi giá trị đầu vào cho kết quả không xác định sẽ bị loại bỏ trong bộ kiểm thử.

Khi làm việc với TDD hãy luôn ghi nhớ rằng: “Không tiến hành viết mã nguồn cho tới khi các kiểm thử đã được thiết kế hoàn chỉnh”.

Quy trình làm việc với TDD

Chiến lược trong TDD được thể hiện qua hình minh họa sau:

Hình 2: Quy trình làm việc với TDD

Các chiến lược khi viết kiểm thử dựa trên ba màu cơ bản: red (thất bại) – khi kiểm thử gặp lỗi, green (thành công) – khi một kiểm thử thông qua, blue (cải tiến) – cấu trúc lại mã nguồn

Làm cho Thất bại: không có mã nguồn nào mà không có kiểm thử thất bại. Làm cho Thành công: đơn giản nhất có thể. Làm cho Tốt hơn: cải tiến (mã nguồn, thiết kế, kiểm thử, tài liệu). Tin tưởng vào việc kiểm thử.

Luồng công việc chính trong TDD

Hình 3: Các luồng công việc chính trong TDD

Việc phát triển - dựa theo hướng kiểm thử yêu cầu các thử nghiệm xuất hiện trước. Chỉ sau khi bạn đã viết các thử nghiệm (và thất bại) bạn mới viết mã lệnh được thử nghiệm. Nhiều nhà phát triển sử dụng một biến thể cách làm thử nghiệm được gọi là phát triển thử nghiệm sau (TAD), ở đó bạn viết mã lệnh và sau đó viết các thử nghiệm đơn vị. Trong trường hợp này, bạn vẫn nhận được các thử nghiệm, nhưng bạn không nhận được các khía cạnh thiết kế nổi dần của TDD. Chẳng có gì ngăn cản bạn viết mã lệnh cực kỳ ghớm guốc và sau đó lúng túng tìm cách để thử nghiệm nó như thế nào. Khi viết mã lệnh trước, bạn đã nhúng các định kiến của bạn về cách thức mã sẽ hoạt động ra sao, sau đó thử nghiệm nó. TDD đòi hỏi bạn phải làm ngược lại: viết các thử nghiệm trước và cho phép nó thông báo cho bạn cách làm thế nào để viết mã lệnh làm cho thử nghiệm thông qua. 

Để minh họa sự khác biệt quan trọng này, chúng ta sẽ xem ví dụ trong phần tiếp theo.