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:
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.
Để 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.
إرسال تعليق