TDD so với thử nghiệm đơn vị [đã đóng]

Công ty của tôi khá mới đối với đơn vị thử nghiệm mã của chúng tôi. Tôi đã đọc về TDD và kiểm thử đơn vị một thời gian và tôi bị thuyết phục về giá trị của chúng. Tôi đã cố gắng thuyết phục nhóm của chúng tôi rằng TDD đáng để chúng tôi nỗ lực học hỏi và thay đổi suy nghĩ về cách chúng tôi lập trình nhưng đó là một cuộc đấu tranh. Điều này đưa tôi đến (các) câu hỏi của tôi.

Có nhiều người trong cộng đồng TDD rất sùng đạo về việc viết bài kiểm tra và sau đó viết mã (và tôi đồng hành cùng họ), nhưng đối với một nhóm đang gặp khó khăn với TDD, liệu một thỏa hiệp có mang lại lợi ích bổ sung không?

Tôi có thể thành công trong việc yêu cầu nhóm viết các bài kiểm tra đơn vị sau khi mã được viết (có lẽ như một yêu cầu để kiểm tra mã) và giả định của tôi là vẫn có giá trị khi viết các bài kiểm tra đơn vị đó.

Cách tốt nhất để đưa một đội đang gặp khó khăn vào TDD là gì? Và thất bại đó là nó vẫn đáng để viết các bài kiểm tra đơn vị ngay cả khi nó sau khi mã được viết?

BIÊN TẬP

Những gì tôi rút ra từ điều này là điều quan trọng đối với chúng tôi là bắt đầu thử nghiệm đơn vị, một nơi nào đó trong quá trình mã hóa. Đối với những người trong nhóm đón nhận ý tưởng này, hãy bắt đầu hướng tới TDD nhiều hơn và thử nghiệm trước. Cảm ơn mọi người đã đóng góp ý kiến.

THEO SÁT

Gần đây chúng tôi đã bắt đầu một dự án nhỏ mới và một phần nhỏ trong nhóm đã sử dụng TDD, phần còn lại viết các bài kiểm tra đơn vị sau mã. Sau khi chúng tôi kết thúc phần viết mã của dự án, những người viết các bài kiểm tra đơn vị sau khi viết mã đã rất ngạc nhiên khi thấy các bộ mã TDD đã được thực hiện và với mã vững chắc hơn. Đó là một cách tốt để chiến thắng những người hoài nghi. Chúng ta còn rất nhiều khó khăn đang lớn phía trước, nhưng cuộc chiến về ý chí dường như đã kết thúc. Cảm ơn tất cả những người đã đưa ra lời khuyên!

Nếu nhóm đang lúng túng trong việc triển khai TDD, nhưng họ không tạo bất kỳ Bài kiểm tra đơn vị nào trước đó ... thì hãy bắt đầu bằng cách tạo Kiểm tra đơn vị sau khi mã của họ được viết. Ngay cả các bài kiểm tra Đơn vị được viết sau mã cũng tốt hơn không có bài kiểm tra đơn vị nào cả!

Một khi họ thành thạo Kiểm thử đơn vị (và mọi thứ đi kèm với nó), thì bạn có thể bắt họ tạo các bài kiểm tra trước tiên ... và mã thứ hai.

Nó vẫn hoàn toàn đáng để viết các bài kiểm tra đơn vị sau khi viết mã. Chỉ là đôi khi nó thường khó hơn vì mã của bạn không được thiết kế để có thể kiểm tra được và bạn có thể đã phức tạp hóa nó.

Tôi nghĩ rằng một cách thực dụng tốt để đưa một đội vào TDD là cung cấp phương pháp thay thế "kiểm tra trong quá trình phát triển" trong giai đoạn chuyển tiếp, hoặc có thể trong dài hạn. Họ nên được khuyến khích TDD các phần mã có vẻ tự nhiên đối với họ. Tuy nhiên, trong các phần mã có vẻ khó tiếp cận với thử nghiệm trước hoặc khi sử dụng các đối tượng được xác định trước bởi quy trình A&D không nhanh nhẹn, các nhà phát triển có thể được cung cấp tùy chọn viết một phần nhỏ của mã, sau đó viết thử nghiệm để bao gồm mã và lặp lại quá trình này. Viết các bài kiểm tra đơn vị cho một số mã ngay sau khi viết mã đó tốt hơn là không viết bất kỳ bài kiểm tra đơn vị nào cả.

Theo ý kiến ​​khiêm tốn của tôi, tốt hơn là có phạm vi kiểm tra 50% với "mã trước, kiểm tra sau" và thư viện đã hoàn thành 100%, phạm vi kiểm tra 100% và thư viện đã hoàn thành 50% với TDD. Sau một thời gian, các nhà phát triển đồng nghiệp của bạn hy vọng sẽ cảm thấy thú vị và mang tính giáo dục khi viết các bài kiểm tra cho tất cả các publicmã họ viết, vì vậy TDD sẽ len lỏi vào quy trình phát triển của họ.

Tôi vừa đọc điều này trên một cuốn lịch: "Mọi quy tắc, được thực thi đến mức tối đa, đều trở nên lố bịch hoặc thậm chí nguy hiểm." Vì vậy, đề nghị của tôi là không nên tôn giáo về nó. Mọi thành viên trong nhóm của bạn phải tìm ra sự cân bằng giữa những gì họ cảm thấy "đúng" khi thử nghiệm. Bằng cách này, mọi thành viên trong nhóm của bạn sẽ làm việc hiệu quả nhất (thay vì nói, suy nghĩ "tại sao tôi phải viết bài kiểm tra sti **** này ??").

Vì vậy, một số thử nghiệm tốt hơn không, các thử nghiệm sau mã tốt hơn một số thử nghiệm và thử nghiệm trước mã tốt hơn sau. Nhưng mỗi bước đều có giá trị riêng và bạn không nên cau có trước những bước nhỏ.

TDD là về thiết kế! Vì vậy, nếu bạn sử dụng nó, bạn sẽ chắc chắn có một thiết kế có thể kiểm tra được của mã của mình, giúp bạn viết kiểm tra dễ dàng hơn. Nếu bạn viết các bài kiểm tra sau khi mã được viết, chúng vẫn có giá trị nhưng IMHO bạn sẽ lãng phí thời gian vì bạn có thể sẽ không có một thiết kế có thể kiểm tra được.

Một gợi ý mà tôi có thể đưa ra cho bạn để cố gắng thuyết phục nhóm của bạn chấp nhận TDD là sử dụng một số kỹ thuật được mô tả trong Thay đổi không sợ hãi: Mẫu để giới thiệu ý tưởng mới của Mary Lynn Manns và Linda Rising .

Nếu họ mới thử nghiệm hơn IMO, hãy bắt đầu mã thử nghiệm đã được viết và từ từ chuyển sang viết thử nghiệm trước. Là một người đang cố gắng học TDD và mới làm quen với kiểm thử đơn vị, tôi thấy thật khó để thực hiện 180 hoàn chỉnh và thay đổi suy nghĩ của mình để viết các bài kiểm tra trước khi viết mã, vì vậy cách tiếp cận mà tôi đang áp dụng là hỗn hợp 50-50 ; khi tôi biết chính xác mã sẽ trông như thế nào, tôi sẽ viết mã và sau đó viết một bài kiểm tra để xác minh nó. Đối với những tình huống mà tôi không hoàn toàn chắc chắn thì tôi sẽ bắt đầu với một bài kiểm tra và làm ngược lại.

Cũng nên nhớ rằng không có gì sai khi viết các bài kiểm tra để xác minh mã, thay vì viết mã để đáp ứng các bài kiểm tra. Nếu nhóm của bạn không muốn đi theo con đường TDD thì đừng ép buộc họ.

Tôi có thể thành công trong việc yêu cầu nhóm viết các bài kiểm tra đơn vị sau khi mã được viết (có lẽ như một yêu cầu để kiểm tra mã) và giả định của tôi là vẫn có giá trị khi viết các bài kiểm tra đơn vị đó.

Hoàn toàn không có nghi ngờ gì về thực tế là có giá trị trong mã đơn vị được kiểm tra (bất kể thời điểm kiểm tra được viết) và tôi bao gồm "mã được kiểm tra đơn vị" trong "Định nghĩa về việc hoàn thành". Mọi người có thể sử dụng TDD hoặc không, miễn là họ thử nghiệm.

Về kiểm soát phiên bản, tôi thích sử dụng " các nhánh phát triển " với chính sách được kiểm tra đơn vị (tức là mã biên dịch và xây dựng, tất cả các kiểm thử đơn vị đều vượt qua). Khi các tính năng được thực hiện, chúng được xuất bản từ các nhánh phát triển đến thân cây. Nói cách khác, nhánh thân là " nhánh Hoàn thành " (Không có rác trên thân cây!) Và có chính sách shippable (có thể phát hành bất kỳ lúc nào) nghiêm ngặt hơn và bao gồm nhiều thứ hơn "đơn vị được kiểm tra".

Đây là điều mà nhóm của bạn sẽ phải có được những thành công của riêng mình trước khi họ bắt đầu tin vào điều đó. Tôi sẽ nói về sự hiển linh nUnit của tôi cho những ai quan tâm:

Khoảng 5 năm trước, tôi phát hiện ra nUnit khi làm việc trong một dự án. Chúng tôi đã gần như hoàn thành V1.0 và tôi đã tạo một vài thử nghiệm chỉ để thử công cụ mới này. Chúng tôi có rất nhiều lỗi (rõ ràng là như vậy!) Bởi vì chúng tôi là một đội mới, thời hạn chặt chẽ, kỳ vọng cao (nghe có vẻ quen thuộc?), V.v. Dù sao thì chúng tôi cũng đã nhận 1.0 và bắt đầu từ 1.1. Chúng tôi đã tổ chức lại đội một chút và tôi đã giao 2 nhà phát triển cho mình. Tôi đã làm một bản demo kéo dài 1 giờ cho họ và nói với họ rằng mọi thứ chúng tôi viết phải có một trường hợp thử nghiệm với nó. Chúng tôi liên tục chạy "phía sau" phần còn lại của nhóm trong suốt chu kỳ phát triển 1.1 vì chúng tôi đang viết nhiều mã hơn, các bài kiểm tra đơn vị. Chúng tôi đã kết thúc làm việc nhiều hơn nhưng đây là thành quả - cuối cùng khi chúng tôi bắt đầu thử nghiệm, chúng tôi có chính xác 0 lỗi trong mã của mình. Chúng tôi đã giúp những người khác gỡ lỗi và sửa lỗi của họ. Trong quá trình khám nghiệm tử thi, khi số lượng lỗi hiển thị,

Tôi không đủ ngu ngốc để nghĩ rằng bạn có thể thử nghiệm theo cách của mình để thành công nhưng tôi là một người tin tưởng thực sự khi nói đến các bài kiểm tra đơn vị. Dự án đã áp dụng nUnit và nó nhanh chóng lan rộng đến công ty cho tất cả các dự án .Net với kết quả là 1 thành công. Tổng khoảng thời gian cho bản phát hành V1.1 của chúng tôi là 9 tuần phát triển nên chắc chắn KHÔNG phải là một thành công trong một sớm một chiều. Nhưng về lâu dài, nó đã chứng tỏ thành công cho dự án của chúng tôi và công ty mà chúng tôi đã xây dựng các giải pháp.

Không có nghi ngờ gì về việc thử nghiệm (Đầu tiên, Trong khi hoặc thậm chí Sau đó) sẽ tiết kiệm thịt xông khói của bạn và cải thiện năng suất và sự tự tin của bạn. Tôi khuyên bạn nên áp dụng nó!

Tôi cũng ở trong tình huống tương tự, bởi vì tôi là một nhà phát triển "noob", tôi thường thất vọng khi làm việc trong dự án nhóm bởi thực tế là một đóng góp đã phá vỡ bản dựng. Tôi không biết mình đáng trách hay thậm chí trong một số trường hợp, phải đổ lỗi cho ai. Nhưng tôi lo ngại hơn rằng tôi đang làm điều tương tự với các nhà phát triển đồng nghiệp của mình. Nhận thức này sau đó đã thúc đẩy việc áp dụng một số chiến lược TDD. Nhóm của chúng tôi bắt đầu có những trò chơi ngớ ngẩn và các quy tắc, chẳng hạn như bạn không thể về nhà cho đến khi tất cả các bài kiểm tra của bạn vượt qua, hoặc nếu bạn gửi thứ gì đó mà không có bài kiểm tra, thì bạn phải mua cho mọi người "bia / bữa trưa / v.v." và điều đó khiến TDD vui hơn.

Một trong những khía cạnh hữu ích nhất của kiểm thử đơn vị là đảm bảo tính đúng đắn liên tục của mã đã hoạt động. Khi bạn có thể cấu trúc lại theo ý muốn, hãy để IDE nhắc nhở bạn về lỗi thời gian biên dịch, sau đó nhấp vào nút để cho phép các thử nghiệm của bạn phát hiện bất kỳ lỗi thời gian chạy tiềm ẩn nào - đôi khi đến các khối mã nhỏ trước đây, sau đó tôi nghĩ bạn sẽ tìm thấy nhóm của mình bắt đầu đánh giá cao TDD. Vì vậy, bắt đầu với việc kiểm tra mã hiện có chắc chắn hữu ích.

Ngoài ra, nói thẳng ra, tôi đã học được nhiều hơn về cách viết mã có thể kiểm tra bằng cách thử kiểm tra mã đã viết hơn là bắt đầu với TDD. Thoạt đầu, nó có thể quá trừu tượng nếu bạn đang cố gắng nghĩ về những hợp đồng vừa hoàn thành mục tiêu cuối cùng vừa cho phép thử nghiệm. Nhưng khi bạn nhìn vào mã và có thể nói "Singleton này ở đây hoàn toàn làm hỏng việc tiêm phụ thuộc và làm cho việc thử nghiệm này trở nên bất khả thi", bạn bắt đầu phát triển sự đánh giá cao về những mẫu nào giúp cuộc sống thử nghiệm của bạn dễ dàng hơn.

Chà, nếu bạn không viết các bài kiểm tra lần đầu thì nó không phải là "Test Driven", nó chỉ là thử nghiệm. Bản thân nó có những lợi ích và nếu bạn đã có một cơ sở mã thì việc thêm các bài kiểm tra cho nó chắc chắn là hữu ích ngay cả khi nó không phải là TDD mà chỉ đơn thuần là kiểm tra.

Viết bài kiểm tra trước tiên là tập trung vào những gì mã phải làm trước khi viết nó. Có bạn cũng nhận được một bài kiểm tra khi làm điều đó và nó tốt, nhưng một số có thể cho rằng đó thậm chí không phải là điểm quan trọng nhất.

Những gì tôi sẽ làm là đào tạo nhóm về các dự án đồ chơi như thế này (xem Coding Dojo, Katas) bằng cách sử dụng TDD (nếu bạn có thể nhờ các lập trình viên TDD có kinh nghiệm tham gia vào hội thảo như vậy sẽ tốt hơn). Khi họ thấy được lợi ích, họ sẽ sử dụng TDD cho dự án thực. Nhưng trong khi đó đừng ép họ, không thấy lợi họ sẽ không làm đúng.

Nếu bạn có các phiên thiết kế trước khi viết mã hoặc phải tạo tài liệu thiết kế, thì bạn có thể thêm Bài kiểm tra đơn vị làm kết quả hữu hình của phiên.

Sau đó, điều này có thể phục vụ như một đặc tả về cách mã của bạn sẽ hoạt động. Khuyến khích ghép nối trong phiên thiết kế, để mọi người nói về cách hoạt động của một thứ gì đó và nó nên làm gì trong các tình huống nhất định. Các trường hợp cạnh là gì, với các trường hợp thử nghiệm rõ ràng cho chúng để mọi người biết nó sẽ làm gì nếu cho một đối số rỗng chẳng hạn.

Một bên nhưng BDD cũng có thể được quan tâm

Bạn có thể tìm thấy một số lực kéo bằng cách hiển thị một hoặc hai ví dụ trong đó TDD dẫn đến ít mã được viết hơn - bởi vì bạn chỉ viết mã cần thiết để thực hiện bài kiểm tra, nên sự cám dỗ đối với tấm vàng hoặc tham gia vào YAGNI sẽ dễ dàng chống lại hơn. Mã bạn không viết không cần phải được duy trì, tái cấu trúc, v.v., vì vậy đó là một "khoản tiết kiệm thực sự" có thể giúp bán khái niệm TDD.

Nếu bạn có thể chứng minh rõ ràng giá trị về thời gian, chi phí, mã và lỗi được lưu, bạn có thể thấy đó là một sản phẩm dễ bán hơn.

Bắt đầu xây dựng các lớp thử nghiệm JUnit là cách để bắt đầu, đối với mã hiện có thì đó là cách duy nhất để bắt đầu. Theo kinh nghiệm của tôi, việc tạo các lớp thử nghiệm cho mã hiện có là rất hữu ích. Nếu ban quản lý cho rằng việc này sẽ đầu tư quá nhiều thời gian, bạn có thể đề xuất chỉ viết các lớp thử nghiệm khi lớp tương ứng được phát hiện có lỗi hoặc cần được dọn dẹp.

Đối với quy trình bảo trì, cách tiếp cận để đưa nhóm vượt qua dòng sẽ là viết các bài kiểm tra JUnit để tái tạo các lỗi trước khi bạn sửa chúng, tức là

• lỗi được báo cáo
• tạo lớp kiểm tra JUnit nếu cần
• thêm một bài kiểm tra tái tạo lỗi
• sửa mã của bạn
• chạy thử nghiệm để hiển thị mã hiện tại không tái tạo lỗi

Bạn có thể giải thích rằng bằng cách "ghi lại" các lỗi theo cách này sẽ ngăn những lỗi đó quay trở lại sau này. Đó là lợi ích mà nhóm có thể trải nghiệm ngay lập tức.

Tôi đã làm điều này ở nhiều tổ chức và tôi đã tìm ra cách tốt nhất để bắt đầu TDD và tiếp theo là thiết lập lập trình cặp. Nếu bạn có người khác mà bạn có thể tin tưởng rằng biết TDD thì hai bạn có thể tách ra và ghép nối với các nhà phát triển khác để thực sự thực hiện một số lập trình ghép nối bằng TDD. Nếu không, tôi sẽ đào tạo một người sẽ giúp bạn làm điều này trước khi trình bày với các thành viên còn lại trong nhóm.

Một trong những trở ngại lớn đối với kiểm thử đơn vị và đặc biệt là TDD là các nhà phát triển không biết cách thực hiện nó, vì vậy họ không thể thấy nó có thể đáng giá như thế nào. Ngoài ra, khi bạn mới bắt đầu, nó chậm hơn nhiều và dường như không mang lại lợi ích. Nó chỉ thực sự mang lại lợi ích cho bạn khi bạn giỏi nó. Bằng cách thiết lập các phiên lập trình được ghép nối, bạn có thể nhanh chóng giúp các nhà phát triển có thể học nó một cách nhanh chóng và thành thạo nó nhanh hơn. Ngoài ra, họ sẽ có thể thấy những lợi ích tức thì từ nó khi bạn làm việc cùng nhau.

Cách tiếp cận này đã làm việc nhiều lần cho tôi trong quá khứ.

Một cách hiệu quả để khám phá lợi ích của TDD là viết lại một số chức năng hiện có, có lẽ vì lý do hiệu suất. Bằng cách tạo một bộ kiểm tra thực hiện tốt công việc bao gồm tất cả các chức năng của mã hiện có, điều này sau đó mang lại cho bạn sự tự tin để cấu trúc lại nội dung trái tim của bạn với hoàn toàn tin tưởng rằng các thay đổi của bạn là an toàn.

Lưu ý rằng trong trường hợp này, tôi đang nói về việc kiểm tra thiết kế hoặc hợp đồng - các bài kiểm tra đơn vị kiểm tra các chi tiết triển khai sẽ không phù hợp ở đây. Nhưng một lần nữa, TDD không thể kiểm tra việc triển khai theo định nghĩa, vì chúng phải được viết trước khi triển khai.

TDD là một công cụ mà các nhà phát triển có thể sử dụng để tạo ra mã tốt hơn. Tôi tình cờ cảm thấy rằng bài tập viết mã có thể kiểm tra được ít giá trị bằng chính các bài kiểm tra. Việc cô lập IUT (Triển khai Đang Thử nghiệm) cho mục đích thử nghiệm có ảnh hưởng mặt đến việc tách mã của bạn.

TDD không dành cho tất cả mọi người, và không có phép thuật nào có thể khiến một nhóm lựa chọn thực hiện nó. Rủi ro là những người viết thử nghiệm đơn vị không biết điều gì đáng để thử nghiệm sẽ viết rất nhiều thử nghiệm có giá trị thấp, điều này sẽ là thức ăn cho những người hoài nghi TDD trong tổ chức của bạn.

Tôi thường tạo Kiểm tra chấp nhận tự động không thể thương lượng, nhưng cho phép các nhà phát triển áp dụng TDD khi nó phù hợp với họ. Tôi đã huấn luyện / cố vấn các TDDers có kinh nghiệm của mình và "chứng minh" tính hữu ích bằng ví dụ trong khoảng thời gian nhiều tháng.

Đây là một thay đổi xã hội / văn hóa nhiều như một thay đổi kỹ thuật.