Những nhược điểm của lập trình thử nghiệm đầu tiên là gì?

Đó là tất cả các cơn thịnh nộ ngày nay. "Mọi người" đề nghị nó. Điều đó trong và của chính nó làm cho tôi nghi ngờ.

Một số nhược điểm bạn đã tìm thấy khi thực hiện phát triển thử nghiệm đầu tiên (dựa trên thử nghiệm) là gì? Tôi đang tìm kiếm kinh nghiệm cá nhân từ các học viên có kiến ​​thức - Tôi có thể đọc các suy đoán giả thuyết của một trăm Wannabes ở nơi khác trên internet.

Tôi hỏi không phải vì tôi đang ghét TDD, mà vì đó là công việc của tôi để cải thiện quy trình phát triển phần mềm và chúng ta càng có thể tìm hiểu về những vấn đề mà mọi người gặp phải, chúng ta càng có cơ hội cải thiện quy trình.

Có khá nhiều, nhưng những ưu điểm vượt xa những nhược điểm.

Có một đường cong học tập dốc.

Nhiều nhà phát triển dường như mong đợi rằng họ có thể hiệu quả với lập trình thử nghiệm ngay từ ngày đầu tiên. Thật không may, phải mất rất nhiều thời gian để có được kinh nghiệm và chương trình với tốc độ như trước đây. Bạn không thể đi xung quanh nó.

Để cụ thể hơn, nó rất dễ bị sai. Bạn có thể rất dễ dàng (với ý định rất tốt) cuối cùng đã viết cả đống bài kiểm tra khó duy trì hoặc kiểm tra những thứ sai. Thật khó để đưa ra ví dụ ở đây - những loại vấn đề này chỉ đơn giản là cần kinh nghiệm để giải quyết. Bạn cần có một cảm giác tốt về việc tách các mối quan tâm và thiết kế để kiểm tra. Lời khuyên tốt nhất của tôi ở đây sẽ là lập trình cặp với một người hiểu rõ về TDD.

Bạn làm thêm mã hóa lên phía trước.

Thử nghiệm đầu tiên có nghĩa là bạn không thể bỏ qua các thử nghiệm (điều này tốt) và có nghĩa là bạn sẽ kết thúc việc viết thêm mã lên phía trước. Điều này có nghĩa là nhiều thời gian hơn. Một lần nữa, bạn không thể vượt qua nó. Bạn nhận được phần thưởng với mã dễ bảo trì, mở rộng và thường ít lỗi hơn, nhưng cần có thời gian.

Có thể là một bán khó khăn cho các nhà quản lý.

Các nhà quản lý phần mềm thường chỉ quan tâm đến các mốc thời gian. Nếu bạn chuyển sang lập trình thử nghiệm đầu tiên và bạn đột nhiên mất 2 tuần để hoàn thành một tính năng thay vì một tính năng, họ sẽ không thích nó. Đây chắc chắn là một trận chiến đáng để chiến đấu và nhiều nhà quản lý đã giác ngộ đủ để có được nó, nhưng nó có thể là một cuộc bán hàng khó khăn.

Có thể là một bán khó khăn cho các nhà phát triển đồng nghiệp.

Vì có một đường cong học tập dốc, không phải tất cả các nhà phát triển đều thích lập trình thử nghiệm đầu tiên. Trên thực tế, tôi đoán rằng hầu hết các nhà phát triển ban đầu không thích nó. Bạn có thể làm những việc như lập trình cặp để giúp họ tăng tốc, nhưng nó có thể là một việc khó khăn.

Cuối cùng, những lợi thế vượt trội hơn những nhược điểm, nhưng nó không có ích nếu bạn bỏ qua những nhược điểm. Biết những gì bạn đang giải quyết ngay từ đầu giúp bạn thương lượng một số, nếu không nói là tất cả, về những bất lợi.

Thử nghiệm đầu tiên giả sử bạn đang viết mã đó là:

• kiểm tra theo cách kiểm tra đơn vị
• rằng những gì bạn đang phát triển có một cách tiếp cận rõ ràng và sẽ không yêu cầu thử nghiệm hoặc tạo mẫu rộng rãi
• rằng bạn sẽ không cần phải cấu trúc lại quá nhiều hoặc bạn có thời gian để viết lại hàng trăm hoặc hàng ngàn trường hợp thử nghiệm
• không có gì được niêm phong
• tất cả mọi thứ là mô-đun
• tất cả mọi thứ là tiêm hoặc nhạo báng
• rằng tổ chức của bạn đặt một giá trị đủ cao cho các khuyết tật thấp để biện minh cho việc chìm tài nguyên
• rằng có một cái gì đó có lợi để kiểm tra ở cấp độ thử nghiệm đơn vị

Nếu dự án của bạn không đáp ứng những yêu cầu đó, bạn sẽ gặp khó khăn. Các nhà quảng bá của TDD không có câu trả lời tốt nào khác để đề nghị bạn thiết kế lại sản phẩm của mình để phù hợp hơn với những dòng đó. Có những tình huống là không thể hoặc không mong muốn.

Trong thực tế cũng có thể cho tôi một vấn đề lớn với những người nghĩ rằng các bài kiểm tra thử nghiệm đầu tiên thực sự chứng minh bất cứ điều gì về chức năng chính xác của chương trình. Trong nhiều trường hợp điều này không đúng, nhưng ngay cả trong những trường hợp đúng, nó vẫn không phải là một bức tranh hoàn chỉnh về sự đúng đắn. Mọi người nhìn thấy hàng trăm bài kiểm tra vượt qua và cho rằng việc kiểm tra ít hơn là an toàn vì trước khi TDD họ chỉ thực hiện vài trăm trường hợp kiểm tra. Theo kinh nghiệm của tôi, TDD có nghĩa là bạn cần phải có nhiều thử nghiệm tích hợp hơn nữa vì các nhà phát triển cũng sẽ có bảo mật sai và nỗi đau khi thay đổi tất cả các thử nghiệm để thực hiện một công cụ tìm kiếm lớn có thể khiến các nhà phát triển thực hiện những công việc thú vị xung quanh.

Ví dụ:

Ví dụ tốt nhất của cá nhân tôi là khi viết mã bảo mật cho asp.net. Nếu chúng có nghĩa là chạy trong môi trường thù địch từ cấu hình máy, chúng sẽ bị khóa, ký và đóng dấu, và vì chúng đang chạy với các đối tượng thần IIS nên chúng rất khó để giả định rất chính xác. Thêm vào một số ràng buộc cho việc sử dụng hiệu năng và bộ nhớ và bạn sẽ nhanh chóng mất tính linh hoạt khi sử dụng các đối tượng giữ chỗ trong các khu vực còn lại.

Bất kỳ loại bộ điều khiển vi mô hoặc mã môi trường tài nguyên thấp nào khác có thể không thực hiện được thiết kế kiểu OO thực sự vì các tóm tắt không tối ưu hóa và bạn có giới hạn tài nguyên thấp. Điều tương tự cũng có thể được nói cho các thói quen hiệu suất cao trong nhiều trường hợp là tốt.

Hạn chế lớn nhất tôi từng thấy không phải với bản thân TDD mà là với các học viên. Họ có một cách tiếp cận giáo điều và nhiệt tâm , nơi mọi thứ phải được kiểm tra . Đôi khi (nhiều lần là như vậy), điều đó là không cần thiết. Ngoài ra, nó có thể không thực tế (.ie. Giới thiệu một tổ chức cho TDD.)

Một kỹ sư giỏi tìm thấy sự đánh đổi và áp dụng số dư phù hợp khi / ở đâu / làm thế nào để áp dụng thử nghiệm trước. Ngoài ra, nếu bạn thấy mình liên tục dành nhiều thời gian hơn để phát triển các bài kiểm tra thay vì mã thực tế (theo hệ số 2-3 trở lên), bạn sẽ gặp rắc rối.

Nói cách khác, hãy thực dụng và hợp lý với TDD (hoặc bất cứ điều gì trong phát triển phần mềm cho vấn đề đó.)

Tôi bắt đầu làm TDD vào đầu tháng 8 năm 2009 và thuyết phục toàn bộ công ty của tôi chuyển sang sử dụng nó vào tháng 9/10 năm 2009. Hiện tại, toàn bộ đội ngũ phát triển đã được chuyển đổi hoàn toàn và cam kết mã chưa được kiểm tra cho repo được coi là một điều xấu và bị ném vào. Nó đã làm việc rất tốt cho chúng tôi và tôi không thể tưởng tượng được việc quay lại mã hóa cao bồi.

Tuy nhiên, có hai vấn đề khá đáng chú ý.

Bộ kiểm tra phải được duy trì

Khi bạn nghiêm túc về TDD, cuối cùng bạn sẽ viết rất nhiều bài kiểm tra. Hơn nữa, phải mất một thời gian và kinh nghiệm để nhận ra là những gì đúng granularity xét nghiệm (quá trớn gần như là xấu như underdoing nó). Các xét nghiệm này cũng là mã , và chúng dễ bị bitrot. Điều này có nghĩa là bạn phải duy trì chúng như mọi thứ khác: cập nhật nó khi bạn nâng cấp thư viện mà chúng phụ thuộc, thỉnh thoảng tái cấu trúc ... Khi bạn thực hiện các thay đổi lớn trong mã của mình, rất nhiều thử nghiệm sẽ đột nhiên bị lỗi thời hoặc thậm chí sai lầm Nếu bạn may mắn, bạn có thể chỉ cần xóa chúng, nhưng nhiều lần bạn sẽ trích xuất các bit hữu ích và điều chỉnh chúng theo kiến ​​trúc mới.

Thỉnh thoảng kiểm tra trừu tượng

Chúng tôi đang sử dụng Django, có một khung thử nghiệm khá tuyệt vời. Tuy nhiên, đôi khi nó đưa ra các giả định hơi mâu thuẫn với thực tế. Ví dụ, một số phần mềm trung gian có thể phá vỡ các bài kiểm tra. Hoặc, một số thử nghiệm đưa ra các giả định về một phụ trợ bộ đệm. Ngoài ra, nếu bạn đang sử dụng db "thực" (không phải SQLite3), thì việc chuẩn bị db cho các bài kiểm tra sẽ mất rất nhiều thời gian. Chắc chắn, bạn có thể (và nên) sử dụng SQLite3 và db trong bộ nhớ để kiểm tra cục bộ, nhưng một số mã sẽ chỉ hoạt động khác nhau tùy thuộc vào cơ sở dữ liệu bạn sử dụng. Thiết lập một máy chủ tích hợp liên tục chạy trong một thiết lập thực tế là bắt buộc.

(Một số người sẽ nói với bạn rằng bạn nên chế nhạo tất cả những thứ như cơ sở dữ liệu, hoặc các bài kiểm tra của bạn không "thuần túy", nhưng đó chỉ là ý thức hệ. Nếu bạn mắc lỗi trong mã giả của mình (và tin tôi đi, bạn sẽ), testsuite của bạn sẽ vô giá trị.)

Tất cả đã nói, các vấn đề tôi mô tả bắt đầu chỉ đáng chú ý khi bạn khá tiến bộ với TDD ... Khi bạn mới bắt đầu với TDD (hoặc làm việc trên các dự án nhỏ hơn), việc tái cấu trúc thử nghiệm sẽ không thành vấn đề.

Đối với tôi có một số vấn đề tâm lý sâu sắc với các bài kiểm tra bất cứ khi nào tôi cố gắng áp dụng chúng rộng rãi, như trong TDD: nếu chúng ở đó, tôi viết mã chậm chạp vì tôi tin rằng các bài kiểm tra sẽ bắt gặp bất kỳ vấn đề nào. Nhưng nếu không có thử nghiệm nào để cung cấp mạng lưới an toàn, tôi mã hóa cẩn thận và kết quả sẽ tốt hơn so với các thử nghiệm.

Có lẽ đó chỉ là tôi. Nhưng tôi cũng đã đọc được ở đâu đó rằng những chiếc xe có tất cả các loại chuông và còi an toàn có xu hướng bị hỏng nhiều hơn (vì các tài xế biết rằng các tính năng an toàn ở đó), vì vậy có lẽ đây là điều cần thừa nhận; TDD có thể không tương thích với một số cá nhân.

Một tình huống trong đó thử nghiệm đầu tiên thực sự cản trở tôi là khi tôi muốn nhanh chóng thử một số ý tưởng và xem liệu nó có thể hoạt động trước khi tôi viết một triển khai đúng không.

Cách tiếp cận của tôi là bình thường:

1. Thực hiện một cái gì đó chạy (bằng chứng của khái niệm).
2. Nếu nó hoạt động, hợp nhất bằng cách thêm các thử nghiệm, cải thiện thiết kế, tái cấu trúc.

Đôi khi tôi không đến được bước 2.

Trong trường hợp này, sử dụng TDD hóa ra có nhiều nhược điểm hơn là lợi thế đối với tôi:

• Viết các bài kiểm tra trong quá trình thực hiện bằng chứng về khái niệm chỉ làm tôi chậm lại và làm gián đoạn dòng suy nghĩ của tôi: Tôi muốn hiểu một ý tưởng và tôi không muốn lãng phí thời gian kiểm tra chi tiết về việc thực hiện thô sơ đầu tiên của mình.
• Có thể mất nhiều thời gian hơn để tìm hiểu xem ý tưởng của tôi có giá trị gì hay không.
• Nếu hóa ra ý tưởng đó là vô ích, tôi phải vứt bỏ cả mã và các bài kiểm tra đơn vị được viết độc đáo của mình.

Vì vậy, khi tôi phải khám phá một số ý tưởng mới, tôi không sử dụng TDD và chỉ giới thiệu các bài kiểm tra đơn vị khi tôi cảm thấy mã mới đang ở đâu đó.

Nhược điểm hoặc chi phí của TDD

Lưu ý: Có một loạt các loại TDD khác nhau. Bất kể đơn vị, BDD, ATDD, hoặc các biến thể khác, nhiều khó khăn vẫn còn

Phản ứng phụ

Cho dù đó là chế giễu, đồ đạc hoặc kiểm tra chức năng, sự phụ thuộc vào các trạng thái hoặc hệ thống bên ngoài thường là nguồn gốc của sự phức tạp nhất trong các thử nghiệm, sự nhầm lẫn trong cách kiểm tra và rủi ro lớn nhất khi hiểu sai. Một vài vấn đề tôi đã thấy:

• Mocking: quên xác nhận thứ tự các cuộc gọi
• Mocking: mock không khớp với cuộc gọi hoặc phản hồi thực
• Lịch thi đấu: kiểm tra dựa trên dữ liệu không thực tế, che giấu các vấn đề khác
• Lịch thi đấu: kiểm tra trạng thái không thể trong sản xuất
• Chức năng: phá vỡ bản dựng sai do hệ thống phụ thuộc tạm thời không khả dụng
• Chức năng: tốc độ kiểm tra rất chậm

Bạn sẽ phải thay đổi cách tiếp cận của bạn đối với tiền mã hóa, đối với một số người, đó sẽ là một sự thay đổi mạnh mẽ.

Mã người khác nhau theo những cách cực kỳ khác nhau. Trong TDD, bạn cần bắt đầu với một bài kiểm tra xác nhận một hành vi cụ thể và sau đó thực hiện để bài kiểm tra vượt qua. Tôi đã thấy và là một lập trình viên có lập trình không có lợi cho TDD. Tôi mất khoảng 2 tháng khi tôi bắt đầu quen với việc thay đổi cách tiếp cận phát triển của mình.

Phải mất thời gian để hiểu những gì bạn quan tâm về thử nghiệm và những gì bạn không quan tâm đến thử nghiệm.

Mỗi đội nên đưa ra quyết định rõ ràng về nơi họ muốn vẽ đường trong thử nghiệm. Những thứ họ đánh giá mà họ muốn thử nghiệm và những gì họ không thử. Nó thường là một quá trình đau đớn để học cách viết các bài kiểm tra tốt, và những gì bạn thực sự quan tâm về kiểm tra. Trong khi đó, mã sẽ tiếp tục ở trong tình trạng thay đổi cho đến khi có sự thống nhất trong cả phong cách và cách tiếp cận.

Kiểm tra đơn vị cụ thể: các nhà tái cấu trúc lớn

Một bộ tái cấu trúc lớn hoặc cơ bản của một cơ sở mã quan trọng với hàng chục ngàn bài kiểm tra đơn vị sẽ tạo ra một chi phí rất lớn để cập nhật tất cả các bài kiểm tra. Điều này thường sẽ biểu hiện trong việc chống lại việc thực hiện một bộ tái cấu trúc ngay cả khi đó là điều chính xác cần làm đơn giản vì chi phí liên quan đến việc thực hiện nó.

Sự tương tự của tôi là những rào cản trên một bản nhạc Scalextric. Nếu bạn đặt chúng vào, bạn sẽ bớt thận trọng hơn nhiều.

Mọi người cũng có được một chút không gian không gian về các thử nghiệm của họ - vì họ chạy tốt, họ tin rằng mã được kiểm tra đầy đủ trong khi đó mới chỉ là khởi đầu của quá trình thử nghiệm.

Đối với tôi, TDD là một bước đệm cho BDD. Một loạt các bài kiểm tra chạy không thực sự giúp hỗ trợ các nhà phát triển mà không biết các bài kiểm tra làm gì. Với BDD, đầu ra thử nghiệm bằng tiếng Anh, tài liệu thử nghiệm và từ đó xây dựng sự hiểu biết về hệ thống.

Lợi ích của TDD là nó buộc bạn phải bảo vệ mã của mình trước những người không hiểu nó. Vâng, điều này thường bao gồm chính bạn. Nhưng, điều gì xảy ra khi mã không đáng để bảo vệ? Có rất nhiều mã thậm chí không nên có ở nơi đầu tiên! Vì vậy, vấn đề với TDD là khi nói đến các nhà phát triển viết mã xấu. TDD có lẽ sẽ không giúp họ viết mã tốt, nhiều khả năng họ cũng sẽ viết các bài kiểm tra khủng khiếp. Do đó, trong trường hợp của họ, TDD sẽ chỉ thêm vào mớ hỗn độn; các bài kiểm tra viết sai và / hoặc dự phòng không có gì thú vị hơn các dạng mã xấu khác.