Tại sao không viết tất cả các bài kiểm tra cùng một lúc khi làm TDD?

Chu trình Red - Green - Refactor cho TDD được thiết lập tốt và được chấp nhận. Chúng tôi viết một bài kiểm tra đơn vị thất bại và làm cho nó vượt qua đơn giản nhất có thể. Những lợi ích của phương pháp này là gì khi viết nhiều bài kiểm tra đơn vị thất bại cho một lớp và khiến tất cả đều vượt qua trong một lần.

Bộ kiểm tra vẫn bảo vệ bạn khỏi việc viết mã không chính xác hoặc mắc lỗi trong giai đoạn tái cấu trúc, vậy tác hại của nó là gì? Đôi khi, việc viết tất cả các bài kiểm tra cho một lớp (hoặc mô-đun) trước tiên sẽ dễ dàng hơn như một hình thức 'đổ não' để nhanh chóng viết ra tất cả các hành vi dự kiến ​​trong một lần.

Thiết kế hướng thử nghiệm là về việc làm cho API của bạn đúng chứ không phải mã.

Lợi ích của việc viết các bài kiểm tra thất bại đơn giản nhất trước tiên là bạn nhận được API của mình (mà về cơ bản là bạn đang thiết kế một cách nhanh chóng) càng đơn giản càng tốt. Lên phía trước.

Bất kỳ việc sử dụng nào trong tương lai (mà các bài kiểm tra tiếp theo bạn viết) sẽ đi từ thiết kế đơn giản ban đầu, thay vì thiết kế dưới mức tối ưu đối phó với các trường hợp phức tạp hơn.

Khi bạn viết một bài kiểm tra, bạn tập trung vào một điều.
Với nhiều bài kiểm tra, bạn đã tập trung chú ý vào nhiều nhiệm vụ, vì vậy đó không phải là một ý tưởng hay.

Một trong những khó khăn khi viết bài kiểm tra đơn vị là bạn đang viết mã và bản thân nó có khả năng dễ bị lỗi. Cũng có khả năng cuối cùng bạn cần phải thay đổi các bài kiểm tra của mình do nỗ lực tái cấu trúc khi bạn viết mã thực thi. Với TDD, điều này có nghĩa là bạn có khả năng cuối cùng sẽ thực hiện một chút quá trình thử nghiệm của mình và thấy rằng bạn cần phải viết lại rất nhiều mã kiểm tra "chưa được kiểm tra" về cơ bản khi quá trình triển khai của dự án. Một cách để tránh loại vấn đề này là chỉ cần tập trung vào làm một việc duy nhất tại một thời điểm. Điều này đảm bảo bạn giảm thiểu tác động của bất kỳ thay đổi nào đối với các bài kiểm tra của bạn.

Tất nhiên, điều này phần lớn sẽ phụ thuộc vào cách bạn viết mã kiểm tra. Bạn đang viết một bài kiểm tra đơn vị cho mỗi phương pháp riêng lẻ, hoặc bạn đang viết bài kiểm tra tập trung vào các tính năng / yêu cầu / hành vi? Một cách tiếp cận khác có thể là sử dụng cách tiếp cận hướng hành vi với khung phù hợp và tập trung vào viết bài kiểm tra như thể chúng là thông số kỹ thuật. Điều này có nghĩa là áp dụng phương pháp BDD hoặc điều chỉnh thử nghiệm BDD nếu bạn muốn gắn bó với TDD chính thức hơn. Ngoài ra, bạn có thể hoàn toàn gắn bó với mô hình TDD, nhưng thay đổi cách bạn viết bài kiểm tra để thay vì tập trung hoàn toàn vào các phương pháp kiểm tra riêng lẻ, bạn kiểm tra các hành vi nói chung như một phương tiện để đáp ứng các chi tiết cụ thể của các tính năng yêu cầu bạn đang thực hiện.

Bất kể cách tiếp cận cụ thể nào bạn thực hiện, trong tất cả các trường hợp mà tôi đã mô tả ở trên, bạn đang sử dụng phương pháp thử nghiệm đầu tiên, do đó, có thể bạn chỉ cần tải xuống bộ não của mình vào một bộ thử nghiệm đáng yêu, bạn cũng muốn chiến đấu với cám dỗ để làm nhiều hơn là hoàn toàn cần thiết. Bất cứ khi nào tôi chuẩn bị bắt đầu một bộ thử nghiệm mới, tôi bắt đầu lặp lại YAGNI cho chính mình, và đôi khi thậm chí ném nó vào một nhận xét trong mã của tôi để nhắc tôi tập trung vào những gì quan trọng ngay lập tức và chỉ làm tối thiểu để đáp ứng yêu cầu của tính năng tôi sắp thực hiện. Bám sát Red-Green-Refactor giúp đảm bảo rằng bạn sẽ làm điều này.

Tôi nghĩ rằng bằng cách này, bạn bỏ lỡ quá trình TDD. Bằng cách chỉ viết tất cả các bài kiểm tra của bạn khi bắt đầu, bạn không thực sự trải qua quá trình phát triển bằng TDD. Bạn chỉ đơn giản là đoán trước những bài kiểm tra bạn sẽ cần. Đây sẽ là một bộ thử nghiệm rất khác so với những thử nghiệm mà bạn kết thúc bằng văn bản nếu bạn thực hiện chúng một lần khi bạn phát triển mã của mình. (Trừ khi chương trình của bạn sẽ không quan trọng trong tự nhiên.)

Tôi viết và viết tất cả các bài kiểm tra mà tôi có thể nghĩ ra trước trong khi não đang gây bão, tuy nhiên tôi viết mỗi bài kiểm tra như một nhận xét duy nhất mô tả bài kiểm tra.

Sau đó tôi chuyển đổi một bài kiểm tra thành mã và thực hiện công việc để nó sẽ biên dịch và vượt qua . Thường thì tôi quyết định tôi không cần tất cả các bài kiểm tra mà tôi nghĩ tôi đã làm hoặc tôi cần các bài kiểm tra khác nhau, thông tin này chỉ đến từ việc viết mã để làm cho các bài kiểm tra vượt qua.

Vấn đề là bạn không thể viết một bài kiểm tra bằng mã cho đến khi bạn đã tạo phương thức và các lớp nó kiểm tra vì nếu không, bạn sẽ chỉ nhận được rất nhiều lỗi trình biên dịch khiến bạn phải làm việc với một bài kiểm tra tại một thời điểm.

Bây giờ nếu bạn đang sử dụng một hệ thống như luồng thông số kỹ thuật khi các bài kiểm tra được viết bằng Tiếng Anh, bạn có thể muốn khách hàng đồng ý với một bộ thử nghiệm trong khi bạn có thời gian của họ, thay vì chỉ tạo một thử nghiệm duy nhất.

Ý tưởng đằng sau TDD là lặp đi lặp lại nhanh chóng.

Nếu bạn có rất nhiều bài kiểm tra phải được viết trước khi bạn phải viết mã, thật khó để lặp lại cấu trúc mã của bạn.

Nếu không tái cấu trúc mã dễ dàng, bạn sẽ mất rất nhiều lợi ích của TDD.

Theo kinh nghiệm (có giới hạn) của tôi với TDD, tôi có thể nói với bạn rằng mỗi lần tôi vi phạm kỷ luật viết một bài kiểm tra tại một thời điểm, mọi thứ trở nên tồi tệ. Đó là một cái bẫy dễ rơi vào. "Ồ, phương pháp đó là tầm thường", bạn tự nghĩ, "vì vậy tôi sẽ loại bỏ hai bài kiểm tra liên quan khác này và tiếp tục di chuyển." Cũng đoán những gì? Không có gì là tầm thường như nó có vẻ. Mỗi lần tôi rơi vào cái bẫy này, cuối cùng tôi đã gỡ lỗi một thứ mà tôi nghĩ là dễ dàng, nhưng hóa ra lại có những trường hợp góc kỳ lạ. Và vì tôi đã tiếp tục viết một số bài kiểm tra cùng một lúc, nên rất nhiều công việc để tìm ra lỗi ở đâu.

Nếu bạn cần một đống thông tin, bạn có rất nhiều lựa chọn:

• Bảng trắng
• Câu chuyện của người dùng
• Bình luận
• Bút và giấy tốt

Lưu ý rằng không nơi nào trong danh sách này là trình biên dịch. :-)

Bạn đang giả định rằng bạn biết mã của bạn sẽ trông như thế nào trước khi bạn viết nó. TDD / BDD là một quá trình thiết kế / khám phá cũng như là một quá trình QA. Đối với một tính năng nhất định, bạn viết thử nghiệm đơn giản nhất sẽ xác minh rằng tính năng đó được thỏa mãn (đôi khi điều này có thể yêu cầu một số tính năng vì độ phức tạp của tính năng). Bài kiểm tra đầu tiên mà bạn viết được tải với các giả định về mã làm việc sẽ trông như thế nào. Nếu bạn viết toàn bộ bộ kiểm tra trước khi viết dòng mã đầu tiên để hỗ trợ nó, bạn đang thực hiện một loạt các giả định chưa được xác minh. Thay vào đó, hãy viết một giả định và xác minh nó. Sau đó viết tiếp. Trong quá trình xác minh giả định tiếp theo, bạn có thể chỉ cần phá vỡ một giả định trước đó để bạn phải quay lại và thay đổi giả định đầu tiên đó để phù hợp với thực tế hoặc thay đổi thực tế để giả định đầu tiên vẫn được áp dụng.

Hãy nghĩ về mỗi bài kiểm tra đơn vị bạn viết như một lý thuyết trong một cuốn sổ tay khoa học. Khi bạn điền vào sổ ghi chép, bạn chứng minh lý thuyết của mình và hình thành những cái mới. Đôi khi việc chứng minh một lý thuyết mới bác bỏ một lý thuyết trước đó để bạn phải sửa nó. Việc chứng minh một lý thuyết tại một thời điểm dễ dàng hơn thay vì cố gắng chứng minh nói 20 cùng một lúc.

TDD là một cách tiếp cận lặp đi lặp lại, mà (theo kinh nghiệm của tôi) phù hợp hơn với các cách phát triển trong thế giới thực. Thông thường việc triển khai của tôi sẽ hình thành dần dần trong quá trình này và mỗi bước có thể mang lại thêm câu hỏi, hiểu biết và ý tưởng để thử nghiệm. Điều này là lý tưởng để giữ cho tâm trí của tôi tập trung vào nhiệm vụ thực tế, và rất hiệu quả bởi vì tôi chỉ cần giữ một số lượng hạn chế của mọi thứ trong bộ nhớ ngắn hạn tại bất kỳ thời điểm nào. Điều này lần lượt làm giảm khả năng sai lầm.

Ý tưởng của bạn về cơ bản là một cách tiếp cận Big Test Up Front, mà IMHO khó xử lý hơn và có thể trở nên lãng phí hơn. Điều gì sẽ xảy ra nếu bạn nhận ra giữa chừng công việc của mình rằng cách tiếp cận của bạn không tốt, API của bạn không hoàn thiện và bạn cần bắt đầu lại hoặc sử dụng thư viện của bên thứ 3 thay thế? Sau đó, rất nhiều công việc đưa vào viết bài kiểm tra của bạn lên phía trước trở nên lãng phí công sức.

Điều đó nói rằng, nếu điều này làm việc cho bạn, tốt. Tôi có thể tưởng tượng rằng nếu bạn làm việc từ một đặc tả kỹ thuật chi tiết, cố định, trên một miền mà bạn có kinh nghiệm mật thiết và / hoặc trên một nhiệm vụ khá nhỏ, bạn có thể có hầu hết hoặc tất cả các trường hợp thử nghiệm cần thiết và việc triển khai của bạn rõ ràng ngay từ bắt đầu. Sau đó, có thể có ý nghĩa để bắt đầu bằng cách viết tất cả các bài kiểm tra cùng một lúc. Nếu kinh nghiệm của bạn là điều này giúp bạn làm việc hiệu quả hơn trong thời gian dài, bạn không cần quá lo lắng về các quy tắc :-)

Ngoài việc chỉ nghĩ về một điều, một mô hình của TDD là viết mã ít nhất có thể để vượt qua bài kiểm tra. Khi bạn viết một bài kiểm tra tại một thời điểm, sẽ dễ dàng hơn nhiều để xem đường dẫn viết mã vừa đủ để bài kiểm tra đó vượt qua. Với toàn bộ các bài kiểm tra để vượt qua, bạn không đi đến mã theo các bước nhỏ mà phải thực hiện một bước nhảy lớn để làm cho tất cả chúng vượt qua trong một lần.

Bây giờ nếu bạn không giới hạn bản thân viết mã để làm cho tất cả chúng vượt qua "trong một lần", nhưng thay vào đó hãy viết mã vừa đủ để vượt qua một bài kiểm tra tại một thời điểm, nó vẫn có thể hoạt động. Tuy nhiên, bạn phải có nhiều kỷ luật hơn để không chỉ đi trước và viết nhiều mã hơn bạn cần. Khi bạn bắt đầu con đường đó, bạn sẽ bỏ ngỏ để viết nhiều mã hơn các bài kiểm tra mô tả, điều này có thể chưa được kiểm tra , ít nhất là theo nghĩa là nó không bị điều khiển bởi một bài kiểm tra và có lẽ theo nghĩa là không cần thiết (hoặc tập thể dục) bằng bất kỳ bài kiểm tra nào.

Nhận được những gì phương pháp nên làm, như bình luận, câu chuyện, một đặc tả chức năng, vv, là hoàn toàn chấp nhận được. Mặc dù vậy, tôi sẽ chờ để dịch chúng thành các bài kiểm tra một lần.

Một điều khác mà bạn có thể bỏ lỡ bằng cách viết tất cả các bài kiểm tra cùng một lúc là quá trình suy nghĩ mà qua đó một bài kiểm tra có thể khiến bạn nghĩ về các trường hợp kiểm tra khác. Nếu không có ngân hàng của các bài kiểm tra hiện tại, bạn cần nghĩ đến trường hợp kiểm tra tiếp theo trong bối cảnh của bài kiểm tra cuối cùng. Như tôi đã nói, có một ý tưởng tốt về những gì phương pháp được cho là rất tốt, nhưng nhiều lần tôi đã thấy mình tìm thấy những khả năng mới mà tôi đã không coi là một tiên nghiệm, nhưng chỉ xảy ra trong quá trình viết xét nghiệm. Có một mối nguy hiểm mà bạn có thể bỏ lỡ những điều này trừ khi bạn đặc biệt có thói quen suy nghĩ những bài kiểm tra mới nào tôi có thể viết mà tôi chưa có.

Tôi đã làm việc trong một dự án nơi các nhà phát triển đã viết các bài kiểm tra (thất bại) khác với các nhà phát triển triển khai mã cần thiết để làm cho chúng vượt qua và tôi thấy nó thực sự hiệu quả.

Trong trường hợp đó, chỉ các bài kiểm tra liên quan đến phép lặp hiện tại được viết một lần. Vì vậy, những gì bạn đề xuất là hoàn toàn có thể trong loại kịch bản đó.

• Sau đó, bạn cố gắng tập trung vào quá nhiều thứ một lúc.
• Trong khi thực hiện để làm cho tất cả các bài kiểm tra vượt qua, bạn không có phiên bản làm việc của ứng dụng của mình. Nếu bạn phải thực hiện nhiều thì bạn sẽ không có phiên bản làm việc trong một thời gian dài.

Chu trình Red-Green-Refactor là một danh sách kiểm tra dành cho các nhà phát triển mới sử dụng TDD. Tôi muốn nói rằng nên theo dõi danh sách kiểm tra này cho đến khi bạn biết khi nào nên theo dõi nó và khi nào bạn có thể phá vỡ nó (nghĩa là cho đến khi biết không phải hỏi câu hỏi này trên stackoverflow :)

Đã thực hiện TDD gần một thập kỷ, tôi có thể nói với bạn rằng tôi rất hiếm khi viết các bài kiểm tra thất bại trước khi tôi viết mã sản xuất.

Bạn đang mô tả BDD, trong đó một số bên liên quan bên ngoài có một đặc tả thực thi. Điều này có thể có lợi nếu có một đặc tả kỹ thuật được xác định trước (ví dụ: một đặc tả định dạng, tiêu chuẩn công nghiệp hoặc nơi lập trình viên không phải là chuyên gia về miền).

Cách tiếp cận thông thường sau đó là dần dần bao gồm ngày càng nhiều thử nghiệm chấp nhận, đó là tiến trình hiển thị cho người quản lý dự án và khách hàng.

Bạn thường có các bài kiểm tra này được chỉ định và thực hiện trong khung BDD như Cucumber, Fitnesse hoặc một số bài kiểm tra khác.

Tuy nhiên, đây không phải là thứ bạn trộn lẫn với các bài kiểm tra đơn vị của mình, nó gần với các chi tiết triển khai quá thô thiển với rất nhiều trường hợp cạnh liên quan đến API, các vấn đề khởi tạo, v.v. tập trung nhiều vào mục được kiểm tra , đó là một tạo tác triển khai .

Kỷ luật tái cấu trúc màu đỏ-xanh lá cây có rất nhiều lợi ích, và nhược điểm duy nhất bạn có thể hy vọng bằng cách gõ chúng lên phía trước là hòa vốn.

Một thử nghiệm tại thời điểm: lợi thế chính là tập trung vào một điều. Hãy nghĩ về thiết kế chuyên sâu: bạn có thể đi sâu và tập trung với vòng phản hồi nhanh. Bạn có thể bỏ lỡ phạm vi của toàn bộ vấn đề! Đó là thời điểm (lớn) tái cấu trúc phát huy tác dụng. Không có nó, TDD không hoạt động.

Tất cả các bài kiểm tra: phân tích và thiết kế có thể tiết lộ cho bạn nhiều hơn về phạm vi của vấn đề. Hãy nghĩ về thiết kế đầu tiên. Bạn phân tích vấn đề từ nhiều góc độ hơn và thêm đầu vào từ kinh nghiệm. Nó vốn đã khó hơn, nhưng có thể mang lại lợi ích thú vị - ít tái cấu trúc - nếu bạn làm "vừa đủ". Hãy coi chừng nó dễ dàng phân tích quá mức và hoàn toàn bỏ lỡ dấu hiệu!

Nói chung, tôi cảm thấy khó khăn khi khuyên bạn nên thích cái này hay cái khác, bởi vì nhiều yếu tố: kinh nghiệm (đặc biệt là với cùng một vấn đề), kiến ​​thức và kỹ năng tên miền, sự thân thiện của mã để tái cấu trúc, độ phức tạp của vấn đề ...

Tôi đoán nếu chúng ta tập trung hẹp hơn vào các ứng dụng kinh doanh thông thường thì TDD với phương pháp tiếp cận thử nghiệm và xử lý nhanh nhất thường sẽ giành chiến thắng về mặt hiệu quả.

Giả sử rằng khung thử nghiệm của bạn hỗ trợ nó, điều tôi muốn đề xuất là thay vì thực hiện các thử nghiệm mà bạn muốn kiểm tra, thay vào đó hãy viết các thử nghiệm đang chờ mô tả mà sau này bạn sẽ thực hiện. Ví dụ: nếu API của bạn nên thực hiện foo và bar nhưng không phải biz, chỉ cần thêm mã sau (ví dụ này là trong rspec) cho bộ thử nghiệm của bạn, sau đó tấn công từng cái một. Bạn suy nghĩ nhanh chóng và có thể giải quyết từng vấn đề một. Khi tất cả các bài kiểm tra vượt qua, bạn sẽ biết khi nào bạn đã giải quyết tất cả các vấn đề bạn gặp phải trong thời gian thử thách.

describe "Your API" do

  it "should foo" do
    pending "braindump from 4/2"
  end

  it "should bar" do
    pending "braindump from 4/2"
  end

  it "should not biz" do
    pending "braindump from 4/2"
  end

end