Trong phần 1, phần 2 chúng ta đã tìm hiểu về TDD và thực hiện một ví dụ để minh hoạ về TDD. Trong phần này, chúng ta tìm hiểu về kiểm thử chấp nhận tự động.
Kiểm thử chấp nhận tự động
Kiểm thử đơn vị rất tỉ mỉ. Nó đi sâu vào chi tiết, có nghĩa
là bạn sẽ có thể bỏ lỡ thứ gì đó lớn và dễ thấy, và đương nhiên, những thứ lớn
và dễ thấy là điều mà khách hàng quan tâm nhất. Chúng thường là những thứ mà họ
có thể thực sự nhìn thấy. Khách hàng mong đợi các chức năng làm việc được với
nhau mà không cần biết từng bộ phận được gắn kết ra sao. Họ muốn lái một chiếc
xe mà không cần phải chỉnh từng bộ phận của động cơ để nó có thể chạy.
Cho kiểm thử chấp nhận tự động vào. Đó là một khái niệm đa
năng chung cho môt số cách tiếp cận như: phát triển hướng hành vi (behavior
driven development – BDD), kiểm thử tích hợp (integration test) và kiểm thử đối
mặt khách hàng (customer facing test). Chúng giúp bạn xác nhận rằng khách hàng
vẫn đang hài lòng, rằng bạn không vừa đập chết một chức năng ưa thích của họ với
những thay đổi vừa đưa vào. Chúng là những kiểm thử dùng để nắm bắt những yêu cầu
cốt lõi của khách hàng. Kết quả là, chúng thường hoạt động ở những tầng cao hơn
rất nhiều so với tầng đơn vị. Chúng kéo theo rất nhiều các lớp có liên quan để
kiểm tra xem các lớp đó có làm việc như mong đợi không.
Hầu hết các ‘kiểm thử chấp nhận tự động’ chấp nhận các sự phụ
thuộc đã cho. Nếu một đối tượng yêu cầu sự phụ thuộc, nó sẽ tạo một thể hiện
cho đối tượng đó, mà không cố gắng tách lẻ mọi thứ ra. Đó là một con dao hai lưỡi.
Nói chung tính năng đó sẽ dễ dàng hơn để làm việc tại mức độ này. Vì các kiểm
thử sẽ chứng minh rằng một chức năng cụ thể làm việc đúng như khách hàng mong
muốn. Kiểm thử đó tồn tại để xác nhận sự kì vọng của bạn. Sự xác nhận đó có rất
nhiều giá trị thương mại. Cùng lúc đó, bạn sẽ cố tránh sự phân tách mã nguồn.
Quá trình phân tách đó rất đau đớn và tốn thời gian – nhưng, nếu bạn để nó đó
quá lâu, mã nguồn của bạn sẽ trở nên hỗn độn. Khi đó sẽ rất khó để làm việc và
thay đổi mã nguồn.
Ngược lại, một kiểm thử đơn vị được cài đặt đúng cách – tức
là với DI, sẽ cắt mã của bạn ra thành những phương thức và lớp hoàn toàn độc lập.
Mọi thay đổi được giữ một cục bộ. Và điều đó luôn đúng dù bạn viết kiểm thử trước
hay sau khi mã nguồn đã tồn tại. Nếu bạn có đủ các kiểm thử đơn vị, sẽ rất dễ
dàng để đưa thay đổi vào. Các kiểm thử xác nhận rằng bạn không phá vỡ bất kì chức
năng đã tồn tại nào cả. Chúng cũng làm những dự đoán của bạn chính xác và đáng
tin cậy hơn. Bạn thậm chí không cần dùng phần mềm tìm lỗi. Kiểm thử chấp nhận tự
động thì không giúp bạn trung thực như vậy.
Kiểm thử chấp nhận tự động vẫn có thể hữu dụng khi dùng để sắp
xếp lại mã nguồn. Bạn sẽ ngăn chặn được những “tai nạn hồi qui” cho khách hàng.
Điều mà xảy ra khá thường xuyên trong những dự án dài với nhiều chức năng. Những
hồi quy tiềm năng thường xảy ra nhiều lần khi làm việc với phần mềm, trước cả
khi bạn bắt đầu giai đoạn thử nghiệm. Nếu bạn biết mình vừa đánh vỡ thứ gì, bạn
có thể sửa nó mà không cần làm phiền ai khác.
Khi bạn khám phá ra những yêu cầu mới, hay những mong đợi của
khách hàng, bạn có thể viết ra những kiểm thử chấp nhận tự động để xác nhận mã
nguồn của mình có làm đúng như vậy không. Khi bạn thêm vào các chức năng, bạn sẽ
phải trải qua một sự bùng nổ rất nhiều các con đường khả dĩ khác nhau. Có một
kiểm thử chấp nhận tự động sẽ rất hữu ích để chắc rằng bạn đã thỏa mãn những thứ
cơ bản. Bạn có thể tập trung viết các thuật toán tốt, vì một lượng lớn các kiểm
thử đơn giản sẽ cho biết bạn đã thỏa mãn chúng hay chưa.
Chúng phục vụ như là các lưới chắn an toàn khi bạn thử nghiệm.
Ví dụ: nhờ vào các kiểm thử chấp nhận tự động tốt, bạn sẽ không cần phải liên tục
kiểm tra thủ công xem việc viết đè một tập tin đã được đổi tên có vượt ra ngoài
kịch bản hay tạo ra một tập tin hoàn toàn mới không. Mỗi cách làm sẽ có một vài
kiểm thử nhỏ và sẽ cho bạn phản hồi ngay lập tức.
Công cụ yêu thích của tôi cho việc đó là Fitnesse. Ví dụ các bảng trên wiki. Chúng được nối
vào kiểm thử khai thác – thứ mà sẽ phiên bản hóa một số lớp và xác nhận các lớp
làm đúng những gì bạn mong đợi. Bởi vì tất cả thông tin đều ở trên wiki, tất cả
mọi người trong nhóm đều có thể đóng góp để xây dựng bộ kiểm thử: từ những nhà
phân tích nghiệp vụ, đến các phát triển viên và các kiểm thử viên. Điều này làm
cho việc thảo luận dễ dàng hơn để có thể hiểu một cách chính xác vấn đề. Những
nhà phát triển cũng tham gia vào quá trình này, và vì vậy, họ sẽ có cơ hội tạo
ra những mã nguồn để giải quyết đúng vấn đề.
Hiểu sai yêu cầu là một dạng lãng phí lớn nhất trong nhiều dự
án phần mềm, với một sự hao tổn đáng kể, cỡ khoảng hơn 50%. Hơn thế nữa, chúng
có một tác động tiêu cực lớn đến dự án. Scott Ambler tóm tắt như sau: “Chi phí
để khắc phục vấn đề sẽ vô cùng lớn nếu lỗi xảy ra là hậu quả của việc hiểu sai
yêu cầu, dẫn đến việc làm hư hại một lượng lớn dữ liệu. Hoặc trong trường hợp
phần mềm thương mại, hay ít nhất là phần mềm “đối mặt với khách hàng” được sử dụng
bởi đối tác của công ty, sự bẽ mặt bởi phần mềm lỗi sẽ rất đáng kể (khách hàng
sẽ không còn tin tưởng vào bạn nữa chẳng hạn).” Và như vậy, giảm thiểu khả năng
lỗi như thế chính là tăng thêm khă năng dự án sẽ thực sự cho khách hàng cái mà
họ muốn.
Việc kiểm thử có thể dẫn bạn quay lại tuyến đường thiết kế tốt
hơn nếu bạn đi trệch ra. Một trong những cái hại ngầm đến một thiết kế tốt là
những nhà thiết kế và các định kiến của họ. Việc cắt đứt khỏi ý nghĩ của bạn những
phần đã vô tình quyết định sai là điều khó khăn. TDD cung cấp một cách thức
thành thói quen để cho các giải pháp nổi lên như bong bóng từ các bài toán thay
vì tuôn xuống như mưa các suy nghĩ lầm lẫn.
Ghi nhớ khi làm việc
với TDD là TDD nói về vấn đề thiết kế chứ không phải kiểm thử hay TDD là tài liệu
tham đầu tiên khi xây dựng dự án. Hãy giữ nó ở mức độ đơn giản nhất có thể thì
sẽ thành công (Keep – It – Simple -
Stupid)
Công cụ trong lập trình để triển khai với TDD
Hình 6: Các công cụ triển khai với TDD
Ví dụ minh họa trong bài sử dụng với JUNIT
Nguồn tham khảo để viết bài
http://www.ambysoft.com/essays/agileTesting.html
http://tapchilaptrinh.vn
https://github.com/sebastianbergmann/phpunit/
http://qunitjs.com/
http://www.agiledata.org/essays/tdd.html
http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
Đăng nhận xét