Kiến trúc tiến hóa và thiết kế nổi dần: Thiết kế hướng theo kiểm thử, phần 2 Bàn luận thêm về việc

Kiến trúc tiến hóa và thiết kế nổi dần: Thiết kế hướng theo kiểm thử, phần 2

Bàn luận thêm về việc cho phép dùng kiểm thử để định hướng và cải thiện thiết kế

của bạn

Neal Ford, Kiến trúc phần mềm, ThoughtWorks

Tóm tắt: Kiểm thử chỉ là một tác dụng phụ của việc phát triển hướng theo kiểm

thử (TDD - test-driven development); khi được thực hiện đúng cách, TDD sẽ cải

thiện thiết kế tổng thể của mã của bạn. Phần thứ 2 này của bài viết Kiến trúc tiến

hóa và thiết kế nổi dần sẽ hoàn tất các bước hướng dẫn về một ví dụ được mở

rộng, cho thấy cách làm thế nào để thiết kế có thể xuất hiện dần từ các mối quan

tâm nảy sinh trong quá trình kiểm thử.

Đây là phần thứ hai của bài viết gồm hai phần, nghiên cứu cách sử dụng TDD như

thế nào để cho phép làm nổi dần các bước thiết kế tốt hơn từ quá trình viết kiểm

thử trước khi bạn viết mã. Tại phần 1, tôi đã viết một phiên bản của trình tìm số

hoàn hảo (perfect numbers), sử dụng cách phát triển kiểm thử sau (viết các phép

kiểm thử sau khi viết mã). Sau đó, tôi đã viết một phiên bản sử dụng TDD (viết

các phép kiểm thử trước khi viết mã, cho phép kiểm thử chi phối thiết kế mã lệnh).

Ở cuối phần 1, tôi thấy rằng tôi đã mắc phải một lỗi cơ bản khi suy nghĩ về loại

cấu trúc dữ liệu được sử dụng để lưu giữ danh sách các số hoàn hảo: bản năng

mách bảo tôi bắt đầu bằng một danh sách mảng (ArrayList), nhưng tôi thấy rằng

phép trừu tượng hóa thành kiểu tập hợp (Set). Tôi sẽ bắt đầu từ điểm này, mở rộng

các thảo luận theo cách mà bạn có thể cải thiện chất lượng của các phép kiểm thử

của bạn và kiểm tra chất lượng của mã lệnh cuối cùng.

Chất lượng kiểm thử

Phép kiểm thử sử dụng cách trừu tượng hóa thành kiểu Set tốt hơn có trong liệt kê

1:

Liệt kê 1. Kiểm thử đơn vị với cách trừu tượng hóa thành Set tốt hơn

@Test public void add_factors() {

Set<Integer> expected =