Tôi không hiểu làm thế nào TDD giúp tôi có được một thiết kế tốt nếu tôi cần một thiết kế để bắt đầu thử nghiệm nó

Tôi đang cố gắng xoay quanh TDD, đặc biệt là phần phát triển. Tôi đã xem một số cuốn sách, nhưng những cuốn tôi tìm thấy chủ yếu giải quyết phần thử nghiệm - Lịch sử của NUnit, tại sao thử nghiệm lại tốt, Red / Green / Refactor và cách tạo Máy tính Chuỗi.

Thứ tốt, nhưng đó là "chỉ" Kiểm tra đơn vị, không phải TDD. Cụ thể, tôi không hiểu làm thế nào TDD giúp tôi có được một thiết kế tốt nếu tôi cần một Thiết kế để bắt đầu thử nghiệm nó.

Để minh họa, hãy tưởng tượng 3 yêu cầu sau:

• Một danh mục cần phải có một danh sách các sản phẩm
• Danh mục cần nhớ những sản phẩm mà người dùng đã xem
• Người dùng sẽ có thể tìm kiếm một sản phẩm

Tại thời điểm này, nhiều cuốn sách kéo một con thỏ ma thuật ra khỏi mũ và lao vào "Thử nghiệm Dịch vụ Sản phẩm", nhưng họ không giải thích làm thế nào họ đưa ra kết luận rằng có Dịch vụ Sản phẩm ở nơi đầu tiên. Đó là phần "Phát triển" trong TDD mà tôi đang cố gắng hiểu.

Cần phải có một thiết kế hiện có, nhưng những thứ bên ngoài các dịch vụ thực thể (nghĩa là: Có một Sản phẩm, do đó cần phải có một Dịch vụ Sản phẩm) (ví dụ, yêu cầu thứ hai yêu cầu tôi phải có một số khái niệm về một Người dùng, nhưng tôi sẽ đặt chức năng này ở đâu để nhắc nhở? Và Tìm kiếm là một tính năng của ProductService hoặc SearchService riêng? Làm sao tôi biết nên chọn cái nào?)

Theo RẮN , tôi sẽ cần một Dịch vụ người dùng, nhưng nếu tôi thiết kế một hệ thống không có TDD, tôi có thể sẽ có một loạt các Dịch vụ Phương thức đơn. Không phải TDD có ý định khiến tôi khám phá thiết kế của mình ngay từ đầu sao?

Tôi là nhà phát triển .net, nhưng tài nguyên Java cũng sẽ hoạt động. Tôi cảm thấy rằng dường như không có một ứng dụng mẫu thực sự hoặc cuốn sách nào liên quan đến một dòng ứng dụng kinh doanh thực sự. Ai đó có thể cung cấp một ví dụ rõ ràng minh họa quá trình tạo ra một thiết kế bằng TDD không?

Ý tưởng của TDD là bắt đầu với thử nghiệm và làm việc từ đó. Do đó, để lấy ví dụ của bạn về "Một danh mục cần phải có một danh sách các sản phẩm" có thể được xem là có một bài kiểm tra "Kiểm tra sản phẩm trong danh mục" và do đó đây là thử nghiệm đầu tiên. Bây giờ, những gì giữ một danh mục? Cái gì giữ một sản phẩm? Đó là những mảnh tiếp theo và ý tưởng là để có được một số bit và mảnh ghép lại với nhau, đó sẽ là một thứ giống như một ProductService sẽ được sinh ra từ khi thử nghiệm đầu tiên đó vượt qua.

Ý tưởng của TDD là bắt đầu với một bài kiểm tra và sau đó viết mã làm cho bài kiểm tra đó vượt qua làm điểm đầu tiên. Các bài kiểm tra đơn vị là một phần của điều này, nhưng bạn không nhìn vào bức tranh tổng thể được hình thành bằng cách bắt đầu bằng các bài kiểm tra và sau đó viết mã để không có điểm mù tại thời điểm này vì chưa có mã nào.

Hướng dẫn phát triển hướng thử nghiệm trong đó các slide 20-22 là những điểm chính. Ý tưởng là để biết kết quả của chức năng nên làm gì, viết một bài kiểm tra cho nó và sau đó xây dựng một giải pháp. Phần thiết kế sẽ thay đổi tùy thuộc vào những gì được yêu cầu, nó có thể hoặc không đơn giản để làm. Một điểm quan trọng là sử dụng TDD ngay từ đầu thay vì cố gắng giới thiệu muộn vào một dự án. Nếu bạn bắt đầu với các bài kiểm tra đầu tiên, điều này có thể giúp ích và có khả năng đáng chú ý theo một nghĩa nào đó. Nếu bạn cố gắng thêm các bài kiểm tra sau đó, nó sẽ trở thành một thứ có thể bị trì hoãn hoặc trì hoãn. Các slide sau này cũng có thể hữu ích.

Lợi ích chính của TDD là bằng cách bắt đầu với các bài kiểm tra, ban đầu bạn không bị khóa trong một thiết kế. Vì vậy, ý tưởng là xây dựng các thử nghiệm và tạo mã sẽ vượt qua các thử nghiệm đó như một phương pháp phát triển. Một Big thiết kế Up Front có thể gây ra vấn đề như thế này cung cấp cho các ý tưởng về khóa thứ vào đúng vị trí mà làm cho hệ thống đang được xây dựng để được ít nhanh nhẹn cuối cùng.

Robert Harvey đã thêm điều này trong các bình luận có giá trị nêu trong câu trả lời:

Thật không may, tôi nghĩ rằng đây là một quan niệm sai lầm phổ biến về TDD: bạn không thể phát triển kiến ​​trúc phần mềm bằng cách chỉ viết các bài kiểm tra đơn vị và làm cho chúng vượt qua. Viết bài kiểm tra đơn vị không ảnh hưởng đến thiết kế, nhưng nó không tạo ra thiết kế. Bạn phải làm điều đó.

Đối với những gì nó có giá trị, TDD giúp tôi đến với thiết kế tốt nhất nhanh hơn là không làm TDD. Tôi có thể sẽ đến với thiết kế tốt nhất có hoặc không có nó. Nhưng thời gian đó tôi đã dành để suy nghĩ về nó và thực hiện một vài cú đâm vào mã được dành để viết bài kiểm tra thay thế. Và đó là ít thời gian hơn. Cho tôi. Không phải cho tất cả mọi người. Và, ngay cả khi mất cùng một khoảng thời gian, nó sẽ để lại cho tôi một bộ các bài kiểm tra, do đó việc tái cấu trúc sẽ an toàn hơn, dẫn đến mã thậm chí còn tốt hơn.

Làm thế nào để nó làm điều đó?

Đầu tiên, nó khuyến khích tôi nghĩ về mọi lớp học như một dịch vụ cho một số mã máy khách. Mã tốt hơn đến từ suy nghĩ về cách mã gọi muốn sử dụng API thay vì lo lắng về việc bản thân mã sẽ trông như thế nào.

Thứ hai, nó ngăn tôi viết quá nhiều phức tạp cyclometic vào một phương thức, trong khi tôi đang nghĩ ra. Mỗi đường dẫn thêm thông qua một phương thức sẽ có xu hướng tăng gấp đôi số lượng thử nghiệm tôi cần làm. Sự lười biếng tuyệt vời chỉ ra rằng sau khi tôi đã thêm quá nhiều logic và tôi phải viết 16 bài kiểm tra để thêm một điều kiện, đã đến lúc rút một số điều đó ra một phương thức / lớp khác và kiểm tra nó một cách riêng biệt.

Nó thực sự đơn giản. Nó không phải là một công cụ thiết kế kỳ diệu.

Tôi đang cố gắng quấn đầu quanh TDD ... Để minh họa, hãy tưởng tượng 3 yêu cầu sau:

• Một danh mục cần phải có một danh sách các sản phẩm
• Danh mục cần nhớ những sản phẩm mà người dùng đã xem

Những yêu cầu này nên được trình bày lại trong điều khoản của con người. Ai muốn biết những sản phẩm mà người dùng đã xem trước đó? Người dùng? Một nhân viên bán hàng?

• Người dùng sẽ có thể tìm kiếm một sản phẩm

Làm sao? Bằng tên? Theo thương hiệu? Bước đầu tiên trong phát triển dựa trên thử nghiệm là xác định thử nghiệm, ví dụ:

browse to http://ourcompany.com
enter "cookie" in the product search box
page should show "chocolate-chip cookies" and "oatmeal cookies"

>

Tại thời điểm này, nhiều cuốn sách kéo một con thỏ ma thuật ra khỏi mũ và lao vào "Thử nghiệm Dịch vụ Sản phẩm", nhưng họ không giải thích làm thế nào họ đưa ra kết luận rằng có Dịch vụ Sản phẩm ở nơi đầu tiên.

Nếu đây là những yêu cầu duy nhất, tôi chắc chắn sẽ không nhảy để tạo ra một Dịch vụ sản phẩm. Tôi có thể tạo một trang web rất đơn giản với danh sách sản phẩm tĩnh. Điều đó sẽ hoạt động hoàn hảo cho đến khi bạn nhận được các yêu cầu để thêm và xóa sản phẩm. Tại thời điểm đó tôi có thể quyết định đơn giản nhất là sử dụng cơ sở dữ liệu quan hệ và ORM và tạo một lớp Sản phẩm được ánh xạ vào một bảng duy nhất. Vẫn không có Dịch vụ sản phẩm. Các lớp như ProductService sẽ được tạo khi và nếu cần. Có thể có nhiều yêu cầu web cần thực hiện cùng một truy vấn hoặc cập nhật. Sau đó, lớp ProductService sẽ được tạo để ngăn việc sao chép mã.

Tóm lại, TDD điều khiển mã được viết. Thiết kế xảy ra khi bạn thực hiện các lựa chọn triển khai, và sau đó cấu trúc lại mã thành các lớp để loại bỏ sự phụ thuộc trùng lặp và kiểm soát. Khi bạn thêm mã, bạn sẽ cần tạo các lớp mới để giữ mã RẮN. Nhưng bạn không cần phải quyết định trước rằng bạn sẽ cần một lớp Sản phẩm và một lớp ProductService. Bạn có thể thấy rằng cuộc sống hoàn toàn tốt đẹp chỉ với một lớp Sản phẩm.

Những người khác có thể không đồng ý, nhưng đối với tôi, nhiều phương pháp mới hơn dựa trên giả định rằng nhà phát triển sẽ thực hiện hầu hết những gì các phương pháp cũ đã nêu ra theo thói quen hoặc niềm tự hào cá nhân, rằng nhà phát triển thường làm điều gì đó khá rõ ràng đối với họ, và công việc được gói gọn trong một ngôn ngữ sạch sẽ hoặc các phần sạch hơn của một ngôn ngữ hơi lộn xộn để bạn có thể thực hiện tất cả các công việc kiểm tra.

Một số ví dụ mà tôi đã gặp phải điều này trong quá khứ:

• Lấy một loạt các nhà thầu làm việc cụ thể và nói với họ rằng nhóm của họ là Agile và Test First. Họ thường không có thói quen nào khác ngoài làm việc để đặc tả và họ không quan tâm đến chất lượng công việc miễn là nó kéo dài đủ lâu để hoàn thành dự án.

• Trước tiên hãy thử và làm một bài kiểm tra mới, dành phần lớn thời gian của bạn để kiểm tra khi bạn thấy các phương pháp và giao diện khác nhau là tào lao.

• Viết mã ở mức độ thấp và bị tát vì thiếu bảo hiểm hoặc viết nhiều bài kiểm tra không có giá trị nhiều vì bạn không thể chế giễu các hành vi cơ bản mà bạn bị ràng buộc.

• Bất kỳ tình huống nào bạn không có đủ các cơ chế cơ bản trước thời hạn để thêm một tính năng có thể kiểm tra mà không cần viết một loạt các bit không thể kiểm soát cơ bản trước, như hệ thống con đĩa hoặc giao diện truyền thông cấp tcpip.

Nếu bạn đang làm TDD và nó đang làm việc cho bạn, tốt cho bạn, nhưng có rất nhiều thứ (toàn bộ công việc hoặc giai đoạn của một dự án) ngoài kia, nơi điều này chỉ đơn giản là không thêm giá trị.

Ví dụ của bạn nghe có vẻ như bạn chưa từng thiết kế, vì vậy hoặc bạn cần có một cuộc trò chuyện kiến ​​trúc, hoặc bạn đang tạo mẫu. Theo quan điểm của tôi, bạn cần phải vượt qua điều đó.

Tôi tin rằng TDD là một cách tiếp cận rất có giá trị đối với thiết kế chi tiết của hệ thống - tức là các API và mô hình đối tượng. Tuy nhiên, để đi đến điểm trong một dự án nơi bạn sẽ bắt đầu sử dụng TDD, bạn cần phải có một bức tranh lớn về thiết kế đã được mô phỏng theo một số thời trang và bạn cần phải có một bức tranh lớn về kiến ​​trúc đã được mô phỏng theo thời trang. @ user414076 paraph cụm từ Robert Martin có ý tưởng thiết kế trong đầu, nhưng không kết hôn với nó. Chính xác. Kết luận - TDD không phải là hoạt động thiết kế duy nhất đang diễn ra, đó là cách các chi tiết của thiết kế được bổ sung. TDD phải được đi trước bởi các hoạt động thiết kế khác và phù hợp với cách tiếp cận tổng thể (như Agile) nhằm giải quyết cách thức thiết kế tổng thể được tạo ra và phát triển.

FYI - hai cuốn sách tôi giới thiệu về chủ đề đưa ra các ví dụ hữu hình và thực tế:

Phát triển phần mềm hướng đối tượng, được hướng dẫn bởi các thử nghiệm - giải thích và đưa ra một ví dụ dự án đầy đủ. Đây là một cuốn sách về thiết kế, không thử nghiệm . Kiểm tra được sử dụng như một phương tiện xác định hành vi dự kiến ​​trong các hoạt động thiết kế.

phát triển dựa trên thử nghiệm Hướng dẫn thực hành - bước đi chậm và từng bước thông qua việc phát triển một ứng dụng hoàn chỉnh, mặc dù nhỏ.

TTD thúc đẩy phát hiện thiết kế do thử nghiệm thất bại, không thành công, do đó bạn có thể kiểm tra các ẩn số và kiểm tra lại vì các ẩn số bị lộ cuối cùng dẫn đến một khai thác hoàn toàn các thử nghiệm đơn vị - một điều rất hay để bảo trì liên tục và rất khó để thử trang bị thêm sau khi mã được viết / phát hành.

Ví dụ, một yêu cầu có thể là đầu vào có thể ở một số định dạng khác nhau, không phải tất cả đều được biết đến. Sử dụng TDD trước tiên bạn sẽ viết một bài kiểm tra xác minh đầu ra thích hợp được cung cấp cho bất kỳ định dạng đầu vào nào . Rõ ràng thử nghiệm này sẽ thất bại, vì vậy bạn viết mã để xử lý các định dạng đã biết và kiểm tra lại. Vì các định dạng không xác định được đưa ra thông qua thu thập yêu cầu, các thử nghiệm mới được viết trước khi mã được viết, những điều này cũng sẽ thất bại. Sau đó, mã mới được viết để hỗ trợ các định dạng mới và tất cả các thử nghiệm được chạy lại làm giảm cơ hội hồi quy.

Cũng rất hữu ích khi nghĩ về thất bại đơn vị là mã "chưa hoàn thành" thay vì mã "bị hỏng". TDD cho phép các đơn vị chưa hoàn thành (thất bại dự kiến), nhưng làm giảm sự xuất hiện của các đơn vị bị hỏng (thất bại bất ngờ).

Trong câu hỏi được nêu:

... Nhiều cuốn sách kéo một con thỏ ma thuật ra khỏi mũ và lao vào "Thử nghiệm dịch vụ sản phẩm", nhưng họ không giải thích làm thế nào họ đi đến kết luận rằng có một Dịch vụ sản phẩm ở nơi đầu tiên.

Họ đi đến kết luận đó bằng cách nghĩ về cách họ sẽ thử nghiệm sản phẩm này. "Những loại sản phẩm này làm gì?" "Chà, chúng ta có thể tạo ra một dịch vụ". "Ok, chúng ta hãy viết một bài kiểm tra cho một dịch vụ như vậy"

Một chức năng có thể có nhiều thiết kế và TDD sẽ không hoàn toàn cho bạn biết cái nào là tốt nhất. Thậm chí, nếu các bài kiểm tra sẽ giúp bạn xây dựng nhiều mã mô-đun hơn, nó cũng có thể dẫn bạn xây dựng các mô-đun phù hợp với yêu cầu kiểm tra và không thực tế sản xuất. Vì vậy, bạn phải hiểu nơi bạn sẽ đến và làm thế nào mọi thứ nên phù hợp trong toàn bộ bức tranh. Nói cách khác, có những yêu cầu về Chức năng và Không Chức năng, đừng quên điều cuối cùng.

Liên quan đến thiết kế Tôi đề cập đến các cuốn sách của Robert C. Martin (Phát triển Agile) mà còn về các mô hình kiến ​​trúc ứng dụng doanh nghiệp và thiết kế trình điều khiển miền của Martin Fowler. Điều đặc biệt sau này là rất hệ thống trong việc trích xuất các Thực thể và Quan hệ ra khỏi các yêu cầu.

Sau đó, khi bạn có được cảm giác tốt về các tùy chọn có sẵn cho bạn về cách quản lý các thực thể đó, bạn có thể cung cấp cho bạn phương pháp TDD.

Không phải TDD có ý định khiến tôi khám phá thiết kế của mình ngay từ đầu sao?

Không.

Làm thế nào bạn có thể kiểm tra một cái gì đó mà bạn chưa thiết kế đầu tiên?

Để minh họa, hãy tưởng tượng 3 yêu cầu sau:

• Một danh mục cần phải có một danh sách các sản phẩm
• Danh mục cần nhớ những sản phẩm mà người dùng đã xem
• Người dùng sẽ có thể tìm kiếm một sản phẩm

Đây không phải là yêu cầu, đây là định nghĩa của dữ liệu. Tôi không biết kinh doanh phần mềm của bạn là gì, nhưng không có khả năng các nhà phân tích nói như vậy.

Bạn cần biết những bất biến của hệ thống của bạn là gì.

Một yêu cầu sẽ là một cái gì đó như:

• Một khách hàng có thể đặt hàng một số lượng sản phẩm nhất định, nếu có đủ sản phẩm này trong kho.

Vì vậy, nếu đây là yêu cầu duy nhất, bạn có thể có một lớp như:

public class Product {

  private int quantity;

  public Product(int initialQuantity) {
    this.quantity = initialQuantity;
  }

  public void order(int quantity) {
    // To be implemented.
  }

}

Sau đó, sử dụng TDD, bạn sẽ viết một trường hợp thử nghiệm trước khi thực hiện phương thức order ().

public void ProductTest() {

    public void testCorrectOrder() {

        Product p = new Product(10);
        p.order(3);
        p.order(4);

    }

    @Expect(ProductOutOfStockException)
    public void testIncorrectOrder() {

        Product p = new Product(10);
        p.order(7);
        p.order(4);

    }

}

Vì vậy, thử nghiệm thứ hai sẽ thất bại, sau đó bạn có thể thực hiện phương thức order () theo cách bạn muốn.

Bạn hoàn toàn đúng TDD sẽ dẫn đến việc thực hiện tốt một thiết kế nhất định. Nó sẽ không giúp quá trình thiết kế của bạn.

TDD giúp rất nhiều, tuy nhiên có một phần quan trọng trong phát triển phần mềm. Nhà phát triển nên lắng nghe mã đang được viết. Tái cấu trúc là phần thứ 3 trong chu trình TDD. Đây là bước chính mà nhà phát triển nên tập trung và suy nghĩ trước khi đi đến thử nghiệm màu đỏ tiếp theo. Có sự trùng lặp nào không? Các nguyên tắc RẮN được áp dụng? Điều gì về sự gắn kết cao và khớp nối thấp? Còn tên thì sao? Hãy xem xét kỹ hơn về mã đang nổi lên từ các thử nghiệm và xem liệu có gì cần phải thay đổi, thiết kế lại không. Hỏi mã và mã sẽ cho bạn biết, nó muốn được thiết kế như thế nào. Tôi thường viết các bộ nhiều bài kiểm tra, kiểm tra danh sách đó và tạo ra thiết kế đơn giản đầu tiên, nó không cần phải là "bản cuối cùng", thường thì không, vì nó đã thay đổi khi thêm các bài kiểm tra mới. Đó là nơi thiết kế đến.