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

Post a Comment

Mới hơn Cũ hơn