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

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:18

Thêm vào BST

Báo xấu

100
lượt xem 7
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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á...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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

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 expected =
new HashSet(Arrays.asList(1, 2, 3, 6)); Classifier4 c = new Classifier4(6); c.addFactor(2); c.addFactor(3); assertThat(c.getFactors(), is(expected)); } Mã này kiểm thử một trong những phần quan trọng nhất trong miền b ài toán của tôi: lấy các ước số của một số. Tôi muốn kiểm tra hành vi đó một cách kỹ lưỡng bởi vì nó là phần phức tạp nhất của bài toán, dễ bị gặp lỗi nhất. Tuy nhiên, nó chứa một cấu trúc cồng kềnh, đó là: new HashSet (Arrays.asList (1, 2, 3, 6)). Ngay cả với sự hỗ trợ của IDE hiện đại, cấu trúc này làm cho mã lệnh rắc rối: gõ nhập new, gõ nhập Has và để mã bên trong tiếp tục; gõ nhập
HashSet (Arrays.asList (1, 2, 3, 6)) mới) là một ví dụ tuyệt vời về điều này bởi vì bạn sẽ muốn có rất nhiều biến thể của nó trong các phép kiểm thử khác nhau. (N.D: tác giả chơi chữ ở đây khi đưa ra nguyên tắc Moist. “Moist” – nghĩa là “ẩm ướt” đối lập với DRY- nghĩa là “khô”). Quy tắc ngón tay cái TDD của tôi là các kiểm thử chỉ là ẩm (moist) chứ không phải là ướt sũng nước (drenched). Ý tôi muốn nói là một số trùng lắp trong các phép kiểm thử có thể chấp nhận được (và không tránh khỏi), nhưng bạn không nên đi quá xa, tạo ra các cấu trúc cồng kềnh lặp đi lặp lại. Để đạt mục đích n ày, tôi sẽ tái cấu trúc phép kiểm thử của mình để cung cấp một phương thức phụ trợ riêng tư (private) để giúp tôi xử lý cách viết hàm tạo phổ biến này, nó có trong liệt kê 2: Liệt kê 2. Phương thức phụ trợ để giữ cho phép thử của tôi ở mức “ẩm” private Set expectationSetWith(Integer... numbers) { return new HashSet(Arrays.asList(numbers)); } Mã trong Liệt kê 2 làm cho tất cả các phép kiểm thử của tôi về các ước số trở nên sạch hơn nhiều, như đã thấy trong phép kiểm thử thể hiện trong Liệt kê 3, được viết lại từ liệt kê 1: Liệt kê 3. Phép kiểm thử “ẩm hơn” để kiểm tra các ước số của một số @Test public void factors_for_6() { Set expected = expectationSetWith(1, 2, 3, 6); Classifier4 c = new Classifier4(6); c.calculateFactors();
assertThat(c.getFactors(), is(expected)); } Bởi vì bạn đang viết các phép kiểm thử không có nghĩa là bạn phải vứt bỏ đi các nguyên tắc thiết kế tốt. Phép kiểm thử là các loại mã lệnh khác, nhưng các nguyên tắc tốt (mặc dù khác) cũng được áp dụng đối với chúng. Các điều kiện biên TDD khuyến khích các nhà phát triển phần mềm viết một phép kiểm thử không thực hiện được khi viết phép kiểm thử đầu tiên cho một chức năng mới nào đó. Điều này tránh việc phép kiểm thử vô tình chạy thông suốt trong mọi trường hợp, làm cho phép kiểm thử thực sự không kiểm tra bất cứ điều gì (phép kiểm thử thừa – tautology test). Các phép kiểm thử cũng có thể xác minh hành vi mà bạn nghĩ rằng bạn là đúng nhưng chưa kiểm tra đủ để tự tin. Các phép kiểm thử này không nhất thiết phải là trước tiên thất bại (mặc dù thất bại khi bạn nghĩ rằng phép kiểm thử sẽ thông suốt là điều hoàn toàn tốt bởi vì bạn đã tìm ra một lỗi tiềm tàng). Suy nghĩ về việc kiểm thử dẫn bạn đến xem xét những gì có thể kiểm thử được. Một số trường hợp kiểm thử thường không được chú ý là các điều kiện biên: mã của bạn sẽ làm gì khi phải đối mặt với đầu vào bất thường? Khi viết nhiều phép kiểm thử đối với phương thức getFactors() sẽ mở ra cho bạn suy nghĩ về những đầu vào hợp lý và không hợp lý nào có thể xảy ra. Với mục đích này, tôi sẽ bổ sung một số phép thử dành cho các điều kiện biên đáng chú ý, được thể hiện trong liệt kê 4: Liệt kê 4. Các điều kiện biên cho phân tích ước số @Test public void factors_for_100() { Classifier5 c = new Classifier5(100); c.calculateFactors();
assertThat(c.getFactors(), is(expectationSetWith(1, 100, 2, 50, 4, 25, 5, 20, 10))); } @Test(expected = InvalidNumberException.class) public void cannot_classify_negative_numbers() { new Classifier5(-20); } @Test public void factors_for_max_int() { Classifier5 c = new Classifier5(Integer.MAX_VALUE); c.calculateFactors(); assertThat(c.getFactors(), is(expectationSetWith(1, 2147483647))); } Con số 100 dường như thú vị bởi vì nó có rất nhiều ước số. Bằng cách kiểm thử cho các số khác nhau, tôi nhận ra rằng trong miền bài toán việc có các số âm là vô nghĩa, do đó, tôi đã viết một phép kiểm thử (và thực sự phép thử này đã thất bại trước khi tôi sửa lỗi ấy) để loại trừ các số âm. Nghĩ về các số âm cũng làm cho tôi nghĩ về MAX_INT: Phải chăng giải pháp của tôi nên xem xét những gì sẽ xảy ra nếu người sử dụng hệ thống cần các số lớn, kiểu long? Giả định ban đầu của tôi chỉ giới hạn ở các số kiểu interger, nhưng tôi cần phải chắc chắn rằng đây là một giả định hợp lệ.
Thu thập các yêu cầu là quá trình nén chịu thiệt (lossy compression – khi nén sẽ bị mất thông tin) Bạn hãy nhìn xung quanh mình và tìm một bức tranh hoặc tác phẩm nghệ thuật. Giả sử rằng bức tranh đó chứa 2 triệu điểm ảnh (pixel). Điều gì sẽ xảy ra nếu bạn nén bức tranh đó để chỉ có 2.000 điểm ảnh? Bức tranh đó vẫn c òn trông như cũ không? (Có lẽ thế nếu đó là một bức tranh của Rothko (N.D: hoạ sĩ theo trường phái trừu tượng, tranh của ông chỉ gồm các mảng mầu), nhưng đó là một trường hợp hiếm hoi). Thao tác nén bằng cách loại bỏ các thông tin l à một thuật toán nén chịu thiệt. Nếu bạn dùng phiên bản đã nén và cố gắng khôi phục lại nó thành 2 triệu điểm ảnh, thì bạn sẽ cần phải thực hiện một số ngón nghề. Đôi khi bạn có thể đoán đúng, nhưng không phải trong mọi trường hợp. Các phiên làm việc yêu cầu “big design up front" (N.D: phương thức "thiết kế hoàn hảo trước, viết mã chương trình sau”, thường gắn với mô hình thác nước trong phát triển phần mềm) truyền thống là quá trình nén chịu thiệt đối với những gì mà một ứng dụng cần làm. Các nhà phân tích nghiệp vụ không thể lường trước mọi vấn đề sẽ phát sinh, do đó các nhà phát triển sẽ phải tạo ra các thông tin để điền vào các chi tiết. Các nhà phát triển nổi tiếng là những người làm việc này rất tệ, dẫn đến nhiều điều bực mình giữa những người xác định các yêu cầu và những người thực hiện các yêu cầu đó. Các quy trình lanh lẹn nỗ lực giảm bớt sự mất mát thông tin này bằng cách trì hoãn thuật toán giải nén càng muộn càng tốt và luôn luôn trông cậy vào một ai đó có thể trả lời câu hỏi về những điều thực sự nên làm. Thiết kế mà không có chi tiết thiết kế là điều không thể, vì vậy dù phương thức luận của bạn là gì, thì bạn phải tìm ra một cách hoàn toàn khả dĩ để điền vào các chi tiết chắc chắn bị loại bỏ bởi quá trình thu thập và xác định. Việc kiểm thử các điều kiện biên buộc bạn phải đặt dấu hỏi cho các giả định của bạn. Rất dễ đưa ra các giả định không hợp lệ khi mã hóa một giải pháp. Trong thực tế, đây là một trong những điểm yếu của việc thu thập các yêu cầu truyền thống - nó không bao giờ có thể tập hợp đủ chi tiết để loại bỏ các câu hỏi khi triển khai thực hiện, chắc chắn sẽ xảy ra. Quá trình thu thập các yêu cầu là một dạng nén chịu thiệt. Bởi vì có quá nhiều điều bị bỏ sót bởi quá trình xác định những gì mà một phần mềm phải làm, bạn cần một cơ chế tại chỗ để giúp bạn tạo lại các câu hỏi mà bạn phải đưa ra để hiểu nó hoàn toàn. Phỏng đoán về những gì những người kinh doanh thực sự mong muốn là điều nguy hiểm vì bạn sẽ nhận được phần lớn câu trả sai. Sử dụng các phép kiểm thử để kiểm tra các điều kiện biên giúp bạn tìm ra các vấn đề để hỏi, mà hầu hết chúng là câu hỏi về cách hiểu vấn đề. Việc tìm ra các câu hỏi đúng có ý nghĩa rất nhiều trong việc đạt được một thiết kế tốt.
Các phép kiểm thử dương và âm Khi bắt đầu việc khảo sát các vấn đề này, tôi phân rã nó thành nhiều tác vụ con. Khi tôi viết các phép kiểm thử, tôi phát hiện một tác vụ phân rã quan trọng. Sau đây là toàn bộ danh sách các tác vụ: 1. Tôi cần các ước số của số đang xét. 2. Tôi cần phải xác định xem một số có phải là một ước số không. 3. Tôi cần phải xác định làm thế nào để bổ sung các ước số vào danh sách các ước số. 4. Tôi cần phải tính tổng các ước số. 5. Tôi cần phải xác định xem một số có là hoàn hảo không. Hai tác vụ còn lại là tính tổng các ước số và kiểm tra tính hoàn hảo của số đang xét. Không có gì ngạc nhiên xảy ra với hai tác vụ này; hai phép kiểm thử cuối cùng có trong liệt kê 5: Liệt kê 5. Hai phép kiểm thử cuối cùng cho các số hoàn hảo @Test public void sum() { Classifier5 c = new Classifier5(20); c.calculateFactors(); int expected = 1 + 2 + 4 + 5 + 10 + 20; assertThat(c.sumOfFactors(), is(expected)); } @Test public void perfection() {
int[] perfectNumbers = new int[] {6, 28, 496, 8128, 33550336}; for (int number : perfectNumbers) assertTrue(classifierFor(number).isPerfect()); } Sau khi xem trang web Wikipedia để tìm một vài số hoàn hảo đầu tiên, tôi có thể viết một phép kiểm thử, kiểm tra xem tôi thực tế có thể tìm thấy các số hoàn hảo hay không. Nhưng tôi chưa kết thúc. Kiểm thử dương chỉ là một nửa công việc. Tôi cũng cần một phép kiểm thử để kiểm tra xem liệu tôi có vô tình nhận nhầm một số không hoàn hảo. Với mục đích này, tôi viết một phép thử âm, như trong liệt kê 6: Liệt kê 6. Phép thử âm để đảm bảo rằng việc phân loại số hoàn hảo làm việc chính xác. @Test public void test_a_bunch_of_numbers() { Set expected = new HashSet( Arrays.asList(PERFECT_NUMS)); for (int i = 2; i < 33550340; i++) { if (expected.contains(i)) assertTrue(classifierFor(i).isPerfect()); else assertFalse(classifierFor(i).isPerfect());
} } Mã này cho biết rằng thuật toán số hoàn hảo của tôi làm việc một cách chính xác, nhưng nó rất chậm. Tôi có thể đoán được lý do tại sao bằng cách xem phương thức calculateFactors() của tôi, hiển thị trong liệt kê 7: Liệt kê 7. Phương thức getFactors() đơn sơ. public void calculateFactors() { for (int i = 2; i < _number; i++) if (isFactor(i)) addFactor(i); } Vấn đề biểu hiện trong Liệt kê 7 tương tự như vấn đề trong phiên bản mã kiểm thử sau trong Phần 1 của loạt bài: Mã lệnh thu thập các ước số đi suốt toàn bộ con đường cho đến tận chính số đó. Tôi có thể cải thiện mã này bằng cách thu thập các ước số theo cặp, cho phép tôi chỉ phân tích tới căn bậc hai của số đang xét, nh ư được thể hiện trong phiên bản mã đã tái cấu trúc trong liệt kê 8: Liệt kê 8. Phiên bản đã tái cấu trúc, hoạt động tốt hơn của phương thức calculateFactors()
public void calculateFactors() { for (int i = 2; i < sqrt(_number) + 1; i++) if (isFactor(i)) addFactor(i); } public void addFactor(int factor) { _factors.add(factor); _factors.add(_number / factor); } Đây là cách tái cấu trúc mã lệnh tương tự cách mà tôi đã làm trong phiên bản mã kiểm thử sau (trong Phần 1), nhưng lần này có sự thay đổi trong hai phương thức khác nhau. Sự thay đổi ở đây đơn giản hơn vì tôi đã trừu tượng hóa chức năng addFactors() thành một phương thức riêng của nó, và phiên bản này sử dụng cách trừu tượng hóa thành Set, loại bỏ việc kiểm thử vụng về để chắc chắn rằng tôi không nhận các ước số hai lần như trong phiên bản kiểm thử sau. Nguyên tắc chỉ đạo của việc tối ưu hóa luôn luôn phải là làm cho đúng, sau đó làm cho nhanh. Một bộ đầy đủ các phép kiểm thử đơn vị làm cho việc kiểm tra các hành vi trở nên dễ dàng, cho phép bạn tự do chơi trò chơi “What if” với việc tối ưu hóa mà không cần lo lắng rằng bạn đã làm sai điều gì đó. Tôi đã làm xong với phiên bản mã hướng theo kiểm thử của trình tìm số hoàn hảo. Toàn bộ mã của lớp này được hiển thị trong liệt kê 9. Liệt kê 9. Phiên bản TDD đầy đủ của trình phân loại số
public class Classifier6 { private Set _factors; private int _number; public Classifier6(int number) { if (number < 1) throw new InvalidNumberException( "Can't classify negative numbers"); _number = number; _factors = new HashSet(); _factors.add(1); _factors.add(_number); } private boolean isFactor(int factor) { return _number % factor == 0; } public Set getFactors() { return _factors; }
private void calculateFactors() { for (int i = 2; i < sqrt(_number) + 1; i++) if (isFactor(i)) addFactor(i); } private void addFactor(int factor) { _factors.add(factor); _factors.add(_number / factor); } private int sumOfFactors() { int sum = 0; for (int i : _factors) sum += i; return sum; } public boolean isPerfect() { calculateFactors(); return sumOfFactors() - _number == _number; }
} Các phương thức có thể hợp thành được Một trong những lợi ích của mã được phát triển hướng theo kiểm thử đã đề cập trong Phần 1 của bài biết này là khả năng hợp thành, dựa trên bản mẫu phương thức hợp thành của Kent Beck (xem mục Tài nguyên). Phương thức hợp thành khuyến khích xây dựng các phần mềm với nhiều phương thức kết dính nhau. TDD tạo điều kiện thuận lợi cho cách làm này bởi vì bạn phải có các bó nhỏ các chức năng để kiểm thử được. Phương thức hợp thành cũng trợ giúp việc thiết kế bởi vì nó tạo ra các khối xây dựng có thể tái sử dụng. Bạn có thể thấy điều này qua số hiệu và tên của các phương thức trong giải pháp mà TDD đem lại. Dưới đây là những phương thức trong phiên bản cuối cùng của trình phân loại các số hoàn hảo theo TDD: isFactor()  getFactors()  calculateFactors()  addFactor()  sumOfFactors()  isPerfect()  Dưới đây là một ví dụ về những lợi ích của phương thức hợp thành. Giả sử bạn đã viết trình tìm kiếm số hoàn hảo TDD của mình, và một số nhóm khác trong công ty của bạn đã viết một phiên bản kiểm thử sau của trình tìm kiếm số hoàn hảo (một ví dụ về trình tìm kiếm này có tại Phần 1 của loạt bài này). Bây giờ, những người sử dụng của bạn chạy vào phòng hốt hoảng: "Chúng ta cũng phải xác định cả các số thừa và các số thiếu nữa!" Trong một số thừa (abundant number), th ì tổng các ước số của số đó lớn hơn chính nó, và trong một số thiếu (deficient number), thì tổng các ước số của số đó nhỏ hơn chính nó. Đối với phiên bản kiểm thử sau, ở đây tất cả các lô gic đều nằm trong một phương thức dài, thì họ phải viết lại toàn bộ giải pháp, tái cấu trúc các mã lệnh chung cho
các số thừa, số thiếu và số hoàn hảo. Trong phiên bản TDD, tôi chỉ cần viết hai phương thức mới, được thể hiện trong liệt kê 10: Liệt kê 10. Hỗ trợ cho các số thừa và các số thiếu public boolean isAbundant() { calculateFactors(); return sumOfFactors() - _number > _number; } public boolean isDeficient() { calculateFactors(); return sumOfFactors() - _number < _number; } Tác vụ duy nhất còn lại trong hai phương thức này là tái cấu trúc phương thức calculateFactors() thành hàm tạo (constructor) của lớp. (Nó là vô hại trong phương thức isPerfect(), nhưng bây giờ phương thức này được sao chép lại trong cả ba phương thức và do đó nên được tái cấu trúc). Việc viết mã như là các khối xây dựng nhỏ làm cho mã có thêm khả năng được tái sử dụng, vì thế điều này nên được coi là một trong những tiêu chí thiết kế chính của bạn. Việc sử dụng các phép kiểm thử để giúp tiến triển dần thiết kế của bạn sẽ khuyến khích viết các phương thức hợp thành được, như vậy sẽ cải thiện thiết kế của bạn.
Đo chất lượng mã Ngay đầu Phần 1 của loạt bài viết, tôi đã tuyên bố rằng khách quan mà nói thì phiên bản mã TDD sẽ tốt hơn phiên bản mã kiểm thử sau. Tôi đã cho các bạn thấy một số bằng chứng nhỏ nhặt, nhưng lấy gì để chứng minh điều này? Tất nhiên, ta không có biện pháp hoàn toàn khách quan nào để đánh giá chất lượng của mã, nhưng ta có một số thước đo có thể cho biết các kích thước nhất định của chất lượng mã; một trong những kích thước đó là tính phức tạp đo lường (xem phần Tài nguyên), do Thomas McCabe tạo ra để đo độ phức tạp chu số (cyclomatic complexity) của mã. Công thức khá đơn giản: lấy số lượng các cung trừ đi số các nút rồi cộng với 2, ở đây các cung là tuyến đường thi hành và các nút là các dòng mã. Để lấy ví dụ, bạn hãy xem xét các mã trong liệt kê 11: Liệt kê 11. Phương thức Java đơn giản để xác định độ phức tạp chu số public void doit() { if (c1) { f1(); } else { f2(); } if (c2) { f3(); } else { f4(); } }
Nếu bạn vẽ sơ đồ phương thức trong Liệt kê 11 thành một biểu đồ dòng chảy, bạn có thể dễ dàng đếm được số lượng các cung và các nút và tính toán độ phức tạp chu số, như trong hình 1. Phương thức này có độ phức tạp chu số là 3 (8 -7 + 2). Hình 1. Các nút và các cung c ủa phương thức doit () Để đo hai phiên bản mã của trình tìm số hoàn hảo, tôi sẽ sử dụng một công cụ mã nguồn mở đo tính phức tạp chu số của Java gọi là JavaNCSS ("NCSS" là viết tắt của "non-commenting source statements – các câu lệnh nguồn không giải thích", mà công cụ này cũng đo số lượng NCSS đó). Xem phần Tài nguyên để biết thông tin tải về. (N.D: NCSS là số câu lệnh về lô gic, không bị xuống dòng để chèn thêm các giải thích, thường sẽ ít hơn so với số dòng lệnh (Source Lines of Code - SLOC) là số dòng mã nguồn về mặt vật lý)., Việc chạy JavaNCSS với phiên bản mã kiểm thử sau cho các kết quả như trong hình 2: Hình 2. Độ phức tạp chu số của trình tìm kiếm số hoàn hảo, phiên bản kiểm
thử sau Chỉ có một phương thức tồn tại trong phiên bản này, và JavaNCSS cho kết quả là các phương thức có trung bình là 13 dòng mã, với độ phức tạp chu số là 5.00. Bạn hãy so sánh kết quả này với phiên bản TDD, như trong hình 3: Hình 3. Độ phức tạp chu số của phiên bản TDD của trình tìm kiếm số hoàn hảo Phiên bản TDD của mã rõ ràng bao gồm nhiều phương thức hơn, trung bình 3.56 dòng mã cho mỗi phương thức, với độ phức tạp chu số trung bình chỉ là 1.56. Đo
bằng biện pháp này, phiên bản TDD đơn giản hơn hơn ba lần so với mã kiểm thử sau. Ngay cả đối với bài toán nhỏ này, đó là một sự khác biệt đáng kể. Tóm tắt Trong hai bài viết vừa qua của loạt bài Kiến trúc tiến hóa thiết kế nổi dần tôi đã trình bày sâu về các lợi ích của kiểm thử trước khi bạn viết mã của mình. Bạn có được phương thức đơn giản hơn, được trừu tượng hóa tốt hơn, có thể tái sử dụng dễ hơn như các khối xây dựng. Và bạn có các phép kiểm thử miễn phí! 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. Trong phần tiếp theo của loạt bài viết, tôi sẽ tạm dừng nói đến kiểm thử và nói về hai mẫu hình quan trọng của thế giới lập trình Smalltalk: phương thức hợp thành và nguyên lý chỉ một mức trừu tượng. Mục lục Chất lượng kiểm thử  Đo chất lượng mã  Tóm tắt 