Làm cách nào để duy trì kỷ luật khi thực hiện TDD?

Question

Khi tôi phấn khởi về một tính năng mới mà tôi sắp sửa triển khai hoặc về một lỗi mà tôi vừa mới hiểu ", có sự thôi thúc chỉ cần nhảy vào mã và lấy cắp dữ liệu. Phải mất một số nỗ lực để ngăn bản thân mình làm điều đó và viết bài kiểm tra tương ứng trước. Sau đó, bài kiểm tra thường trở thành tầm thường 4-lót, nhưng trước khi viết nó vẫn còn có suy nghĩ ở phía sau đầu, "có lẽ tôi có thể bỏ qua cái này, lần này?" Lý tưởng nhất là tôi muốn có một yêu cầu để viết thử nghiệm, và chỉ sau đó, có lẽ, mã :)

Phương pháp (hoặc cách suy nghĩ hoặc thủ thuật hoặc chính sách tự thưởng hay bất kỳ) nào bạn sử dụng để trợ giúp duy trì kỷ luật? Hay bạn chỉ thực hành nó cho đến khi nó cảm thấy tự nhiên?

Answer 1

Tôi thích phản hồi ngay lập tức từ thử nghiệm, đó là phần thưởng đủ cho tôi. Nếu tôi có thể tái tạo một lỗi trong một thử nghiệm đó là một cảm giác tốt, tôi biết tôi đang đi đúng hướng như trái ngược với đoán và có thể lãng phí thời gian của tôi.

Tôi thích làm việc Bài kiểm tra đầu tiên bởi vì tôi cảm thấy như nó giúp tôi theo kịp hơn với những gì mã thực sự hoạt động như trái ngược với đoán dựa trên một mô hình tâm thần có thể không chính xác. Có thể xác nhận giả định của tôi lặp đi lặp lại là một phần thưởng lớn cho tôi.

Answer 2

wear a green wristband

Answer 3

1) Bạn cặp với người khác trong nhóm của bạn. Một người viết bài kiểm tra, các công cụ khác.

Được gọi là ghép nối "ping-pong".

Thực hiện việc này sẽ buộc bạn phải thảo luận về thiết kế và tìm hiểu xem phải làm gì.

Việc thảo luận này cũng giúp bạn dễ dàng xem những bài kiểm tra nào bạn cần.

2) Khi tôi tự làm việc, tôi muốn thử các đoạn mã tương tác. Tôi chỉ cần gõ chúng vào dấu nhắc ruby. Khi tôi đang thử nghiệm như thế này, tôi thường cần thiết lập một số dữ liệu để thử nghiệm và một số câu lệnh in để xem kết quả là gì.

Những chút, thí nghiệm throwaway khép kín thường:

• một cách nhanh chóng để thiết lập tính khả thi của một thực hiện, và
• nơi tốt để bắt đầu chính thức hóa thành một thử nghiệm.

Answer 4

Tôi thấy rằng các bài kiểm tra viết giúp tôi phác họa cách tiếp cận của mình cho vấn đề trong tầm tay. Thông thường, nếu bạn không thể viết một bài kiểm tra tốt, nó có nghĩa là bạn không nhất thiết phải suy nghĩ đủ về những gì nó là nghĩa vụ phải làm. Sự hài lòng của việc tự tin rằng tôi biết làm thế nào để giải quyết vấn đề một khi các bài kiểm tra được viết là khá hữu ích.

Answer 5

Tôi sẽ cho bạn biết khi nào tôi tìm phương thức hoạt động. :-)

Nhưng nghiêm túc, tôi nghĩ rằng "thực hành của bạn cho đến khi nó cảm thấy tự nhiên" bình luận khá nhiều chạm vào móng tay trên đầu. Một thử nghiệm 4 dòng có thể xuất hiện tầm thường, nhưng miễn là những gì bạn đang thử nghiệm đại diện cho một điểm thất bại thực sự thì nó là giá trị làm.

Một điều tôi thấy hữu ích là bao gồm xác thực phạm vi mã như là một phần của quá trình xây dựng. Nếu tôi không viết bài kiểm tra, bản xây dựng sẽ phàn nàn với tôi.Nếu tôi tiếp tục không viết bài kiểm tra, bản xây dựng tích hợp liên tục sẽ "lỗi" và mọi người ở gần sẽ nghe thấy âm thanh tôi đã kết nối với thông báo "hỏng xây dựng". Sau một vài tuần của "Tốt đau buồn ... Bạn đã phá vỡ nó một lần nữa?", Và ý kiến ​​tương tự, tôi sớm bắt đầu viết nhiều bài kiểm tra để tránh bối rối.

Một điều khác (chỉ xảy ra với tôi sau khi tôi đã gửi câu trả lời lần đầu tiên) là khi tôi thực sự có thói quen viết bài kiểm tra đầu tiên, tôi đã tăng cường tích cực từ thực tế là tôi có thể gửi lỗi -fix và các tính năng bổ sung với sự tự tin lớn hơn nhiều so với tôi có thể trong các ngày thử nghiệm trước khi tự động của mình.

Answer 6

Tôi nghĩ rằng phần quan trọng của việc giữ cho mình trong kiểm tra như xa như TDD là có liên quan là để có dự án thử nghiệm thiết lập đúng. Bằng cách đó, thêm một trường hợp thử nghiệm tầm thường thực sự là tầm thường.

Nếu để thêm một bài kiểm tra, trước tiên bạn cần tạo một dự án thử nghiệm, sau đó tìm hiểu cách cô lập các thành phần, khi nào mô phỏng mọi thứ, v.v.

Vì vậy, tôi đoán nó quay trở lại để có các xét nghiệm đơn vị hoàn toàn được tích hợp vào quá trình phát triển của bạn.

Answer 7

Khi tôi lần đầu tiên bắt đầu làm TDD vào khoảng năm 2000, nó cảm thấy rất không tự nhiên. Sau đó, đến phiên bản đầu tiên của .net và cổng JUnit của NUnit, và tôi bắt đầu thực hành TDD ở cấp Shu (của Shu-Ha-Ri), có nghĩa là kiểm tra (đầu tiên) mọi thứ, với cùng các câu hỏi như của bạn.

Một vài năm sau, tại một nơi làm việc khác, cùng với một nhà phát triển cấp cao có năng lực và chuyên môn, chúng tôi đã thực hiện các bước cần thiết để đạt đến cấp độ Hà. Điều này có nghĩa là ví dụ, không mù quáng với sự tham gia trong báo cáo bảo hiểm, nhưng câu hỏi "là loại thử nghiệm thực sự hữu ích, và nó có thêm giá trị hơn nó chi phí?".

Bây giờ, tại một nơi làm việc khác, cùng với một đồng nghiệp tuyệt vời khác, tôi cảm thấy rằng chúng tôi đang thực hiện các bước đầu tiên của chúng tôi đối với cấp Ri. Đối với chúng tôi, hiện tại có nghĩa là tập trung vào các câu chuyện BDD/thực thi. Với những người đã xác minh yêu cầu ở cấp độ cao hơn, tôi cảm thấy hiệu quả hơn, vì tôi không cần phải viết lại một loạt các bài kiểm tra đơn vị mỗi lần giao diện công cộng của lớp cần thay đổi, thay thế một cuộc gọi tĩnh với một phương pháp mở rộng, v.v.

Đừng hiểu lầm, các bài kiểm tra lớp TDD thông thường vẫn được sử dụng và cung cấp giá trị lớn cho chúng tôi. Thật khó để nói bằng lời, nhưng chúng tôi chỉ giỏi hơn "cảm giác" và "cảm nhận" những thử nghiệm có ý nghĩa, và cách thiết kế phần mềm của chúng tôi, so với mười năm trước.

Answer 8

Cách dễ nhất tôi thấy là chỉ cần sử dụng TDD rất nhiều. Tại một số thời điểm, viết mã mà không cần kiểm tra đơn vị sẽ trở thành một hoạt động rất, rất lo lắng.

Ngoài ra, hãy cố gắng tập trung vào thử nghiệm tương tác hoặc hành vi thay vì thử nghiệm dựa trên trạng thái.