Có phải là một ý tưởng tốt để viết tất cả các trường hợp thử nghiệm có thể sau khi chuyển đổi nhóm thành TDD để đạt được một phạm vi bảo hiểm đầy đủ?

Giả sử chúng tôi có một ứng dụng cấp doanh nghiệp lớn mà không có bất kỳ bài kiểm tra đơn vị / chức năng nào. Không có quá trình phát triển dựa trên thử nghiệm trong quá trình phát triển do thời hạn rất chặt chẽ (tôi biết chúng ta không bao giờ nên hứa bất kỳ thời hạn chặt chẽ nào khi chúng ta không chắc chắn, nhưng những gì đã hoàn thành!)

Bây giờ tất cả các thời hạn đã trôi qua và mọi thứ đều bình tĩnh, mọi người đã đồng ý chuyển đổi chúng tôi thành một nhóm dựa trên TDD / BDD hiệu quả ... Yay!

Bây giờ câu hỏi là về mã mà chúng ta đã có: (1) Vẫn ổn hay tốt để dừng hầu hết sự phát triển và bắt đầu viết toàn bộ các trường hợp thử nghiệm có thể ngay từ đầu, mặc dù mọi thứ vẫn hoạt động hoàn toàn OKAY (chưa!) ? Hoặc (2) tốt hơn là đợi điều gì đó xấu xảy ra và sau đó trong quá trình sửa lỗi, hãy viết các bài kiểm tra đơn vị mới, hoặc (3) thậm chí quên các mã trước đó và chỉ viết các bài kiểm tra đơn vị cho các mã mới và hoãn mọi thứ cho bộ tái cấu trúc chính tiếp theo.

Có một vài bài viết hay và liên quan như bài này . Tôi vẫn không chắc có đáng để đầu tư vào việc này hay không vì chúng tôi có thời gian rất hạn chế và nhiều dự án / công trình khác đang chờ chúng tôi.

Lưu ý : Câu hỏi này đang giải thích / tưởng tượng một tình huống hoàn toàn khó xử trong một nhóm phát triển. Đây không phải là về tôi hoặc bất kỳ đồng nghiệp của tôi; nó chỉ là một tình huống tưởng tượng. Bạn có thể nghĩ rằng điều này không bao giờ nên xảy ra hoặc người quản lý phát triển chịu trách nhiệm cho một mớ hỗn độn như vậy! Nhưng dù sao, những gì đã làm được thực hiện. Nếu có thể, xin đừng downvote chỉ vì bạn nghĩ điều này sẽ không bao giờ xảy ra.

Không có quá trình phát triển dựa trên thử nghiệm trong quá trình phát triển do thời hạn rất chặt chẽ

Tuyên bố này rất liên quan. Không phải vì điều đó có nghĩa là bạn đã phát triển mà không có TDD hoặc vì bạn không thử nghiệm mọi thứ. Điều này có liên quan, bởi vì nó cho thấy bạn nghĩ TDD sẽ làm bạn chậm lại và khiến bạn bỏ lỡ thời hạn.

Miễn là bạn thấy nó theo cách này bạn chưa sẵn sàng cho TDD. TDD không phải là thứ bạn có thể dần dần dễ dàng. Bạn có biết làm thế nào để làm điều đó hoặc bạn không. Nếu bạn cố gắng thực hiện nửa chừng, bạn sẽ làm cho nó và bản thân bạn trông xấu đi.

TDD là điều đầu tiên bạn nên thực hành ở nhà. Tìm hiểu để làm điều đó, bởi vì nó giúp bạn viết mã ngay bây giờ . Không phải vì ai đó bảo bạn làm điều đó. Không phải vì nó sẽ giúp ích khi bạn thay đổi sau này. Khi nó trở thành thứ bạn làm bởi vì bạn đang vội thì bạn đã sẵn sàng để làm nó một cách chuyên nghiệp.

TDD là điều bạn có thể làm trong bất kỳ cửa hàng nào . Bạn thậm chí không phải bật mã kiểm tra của mình. Bạn có thể giữ nó cho riêng mình nếu những người khác coi thường các bài kiểm tra. Khi bạn làm đúng, các bài kiểm tra sẽ tăng tốc độ phát triển của bạn ngay cả khi không có ai khác chạy chúng.

Mặt khác, nếu người khác yêu thích và chạy thử nghiệm của bạn, bạn vẫn nên nhớ rằng ngay cả trong cửa hàng TDD, công việc của bạn không phải là kiểm tra. Đó là để tạo mã sản xuất làm việc đã được chứng minh. Nếu nó xảy ra để có thể kiểm tra, gọn gàng.

Nếu bạn nghĩ rằng quản lý phải tin vào TDD hoặc rằng các lập trình viên đồng nghiệp của bạn phải hỗ trợ các bài kiểm tra của bạn thì bạn đã bỏ qua điều tốt nhất TDD dành cho bạn. Nó nhanh chóng cho bạn thấy sự khác biệt giữa những gì bạn nghĩ rằng mã của bạn làm và những gì nó thực sự làm.

Nếu bạn không thể tự mình thấy điều đó có thể giúp bạn đáp ứng thời hạn nhanh hơn thì bạn chưa sẵn sàng cho TDD tại nơi làm việc. Bạn cần thực hành tại nhà.

Điều đó nói rằng, thật tuyệt khi nhóm có thể sử dụng các bài kiểm tra của bạn để giúp họ đọc mã sản xuất của bạn và khi quản lý sẽ mua các công cụ TDD mới.

Có phải là một ý tưởng tốt để viết tất cả các trường hợp thử nghiệm có thể sau khi chuyển đổi nhóm thành TDD?

Bất kể những gì nhóm đang làm, không phải lúc nào cũng nên viết tất cả các trường hợp thử nghiệm có thể. Viết các trường hợp kiểm tra hữu ích nhất. Bảo hiểm mã 100% đi kèm với một chi phí. Đừng bỏ qua luật giảm lợi nhuận chỉ vì thực hiện một cuộc gọi phán xét là khó khăn.

Tiết kiệm năng lượng thử nghiệm của bạn cho logic kinh doanh thú vị. Các công cụ đưa ra quyết định và thực thi chính sách. Kiểm tra cái quái gì đó Chán rõ ràng mã keo cấu trúc dễ đọc mà chỉ nối các thứ lại với nhau không cần kiểm tra gần như tồi tệ.

(1) Vẫn còn ổn hay tốt để dừng hầu hết sự phát triển và bắt đầu viết toàn bộ các trường hợp thử nghiệm có thể ngay từ đầu, mặc dù mọi thứ đều hoạt động hoàn toàn OKAY (chưa!)? Hoặc là

Không. Đây là suy nghĩ "hãy viết lại hoàn toàn". Điều này phá hủy kiến ​​thức khó giành được. Đừng yêu cầu quản lý thời gian để viết bài kiểm tra. Chỉ cần viết bài kiểm tra. Một khi bạn biết những gì bạn đang làm, các bài kiểm tra sẽ không làm bạn chậm lại.

(2) tốt hơn là chờ đợi điều gì đó xấu xảy ra và sau đó trong quá trình sửa lỗi, hãy viết các bài kiểm tra đơn vị mới, hoặc

(3) thậm chí quên các mã trước đó và chỉ viết các bài kiểm tra đơn vị cho các mã mới và hoãn mọi thứ cho bộ tái cấu trúc chính tiếp theo.

Tôi sẽ trả lời 2 và 3 theo cùng một cách. Khi bạn thay đổi mã, vì bất kỳ lý do gì, thật tuyệt nếu bạn có thể trượt trong một bài kiểm tra. Nếu mã là di sản, hiện tại nó không chào đón một thử nghiệm. Điều đó có nghĩa là rất khó để kiểm tra nó trước khi thay đổi nó. Chà, vì dù sao bạn cũng thay đổi nó, bạn có thể thay đổi nó thành thứ gì đó có thể kiểm tra và kiểm tra nó.

Đó là lựa chọn hạt nhân. Đó là rủi ro. Bạn đang thực hiện thay đổi mà không cần kiểm tra. Có một số thủ thuật sáng tạo để kiểm tra mã kế thừa trước khi bạn thay đổi nó. Bạn tìm kiếm những gì được gọi là đường nối cho phép bạn thay đổi hành vi của mã mà không thay đổi mã. Bạn thay đổi tập tin cấu hình, xây dựng tập tin, bất cứ điều gì nó cần.

Michael Feathers đã cho chúng tôi một cuốn sách về điều này: Làm việc hiệu quả với Bộ luật kế thừa . Hãy đọc và bạn sẽ thấy rằng bạn không cần phải đốt cháy mọi thứ cũ để tạo ra thứ gì đó mới.

Vẫn còn ổn hay ý tưởng tốt để ngăn chặn hầu hết sự phát triển và bắt đầu viết toàn bộ các trường hợp thử nghiệm có thể ngay từ đầu [...]?

Cho ¹ mã kế thừa , viết các bài kiểm tra đơn vị trong các tình huống sau:

• khi sửa lỗi
• khi tái cấu trúc
• khi thêm chức năng mới vào mã hiện có

Cũng hữu ích như các bài kiểm tra đơn vị, việc tạo một bộ kiểm thử đơn vị hoàn chỉnh cho ¹ cơ sở mã hiện tại có lẽ không phải là một ý tưởng thực tế. Sức mạnh đã thúc đẩy bạn đưa ra một thời hạn chặt chẽ. Họ không cho phép bạn có thời gian để tạo các bài kiểm tra đơn vị đầy đủ khi bạn đang phát triển. Bạn có nghĩ rằng họ sẽ cho bạn đủ thời gian để tạo các bài kiểm tra cho "chương trình hoạt động" không?

¹ _{Mã kế thừa là mã không có kiểm tra đơn vị. Đây là định nghĩa TDD của mã kế thừa. Nó được áp dụng ngay cả khi mã kế thừa được phân phối mới [ngay cả khi mực chưa khô].}

Theo kinh nghiệm của tôi, các bài kiểm tra không cần tổng bảo hiểm là hữu ích. Thay vào đó, bạn bắt đầu gặt hái các loại lợi ích khác nhau khi mức độ bao phủ tăng:

• phạm vi bảo hiểm hơn 30% (còn gọi là một vài bài kiểm tra tích hợp): nếu các bài kiểm tra của bạn thất bại, một cái gì đó cực kỳ bị hỏng (hoặc các bài kiểm tra của bạn không ổn định). Rất may các bài kiểm tra đã cảnh báo bạn một cách nhanh chóng! Nhưng bản phát hành vẫn sẽ yêu cầu thử nghiệm thủ công rộng rãi.
• phạm vi bảo hiểm hơn 90% (còn gọi là hầu hết các thành phần có các bài kiểm tra đơn vị bề ngoài): nếu các bài kiểm tra của bạn vượt qua, phần mềm có khả năng tốt. Các phần chưa được kiểm tra là trường hợp cạnh, điều này tốt cho phần mềm không quan trọng. Nhưng bản phát hành vẫn sẽ yêu cầu một số thử nghiệm thủ công.
• Độ bao phủ rất cao của các chức năng / câu lệnh / chi nhánh / yêu cầu: bạn đang sống trong giấc mơ TDD / BDD và các bài kiểm tra của bạn là sự phản ánh chính xác chức năng của phần mềm của bạn. Bạn có thể tái cấu trúc với độ tin cậy cao, bao gồm các thay đổi kiến ​​trúc quy mô lớn. Nếu các bài kiểm tra vượt qua, phần mềm của bạn gần như đã sẵn sàng để phát hành; chỉ cần một số thử nghiệm khói thủ công.

Sự thật là, nếu bạn không bắt đầu với BDD, bạn sẽ không bao giờ đến đó, bởi vì công việc cần kiểm tra sau khi mã hóa chỉ là quá mức. Vấn đề không phải là viết các bài kiểm tra, mà là nhận thức được các yêu cầu thực tế (chứ không phải là chi tiết triển khai ngẫu nhiên) và có thể thiết kế phần mềm theo cách vừa chức năng vừa dễ kiểm tra. Khi bạn viết các bài kiểm tra đầu tiên hoặc cùng với mã, điều này thực tế là miễn phí.

Vì các tính năng mới yêu cầu kiểm tra, nhưng các kiểm tra yêu cầu thay đổi thiết kế, nhưng tái cấu trúc cũng yêu cầu kiểm tra, bạn có một chút vấn đề về gà và trứng. Khi phần mềm của bạn leo gần hơn với phạm vi bảo hiểm tốt, bạn sẽ phải thực hiện một số thao tác tái cấu trúc cẩn thận trong các phần của mã nơi các tính năng mới xuất hiện, chỉ để làm cho các tính năng mới có thể kiểm tra được. Điều này sẽ làm bạn chậm lại rất nhiều - ban đầu. Nhưng bằng cách chỉ tái cấu trúc và thử nghiệm những phần cần phát triển mới, các thử nghiệm cũng tập trung vào khu vực mà chúng cần nhất. Mã ổn định có thể tiếp tục mà không cần kiểm tra: nếu đó là lỗi, bạn vẫn phải thay đổi mã.

Trong khi bạn thử thích nghi với TDD, một số liệu tốt hơn so với tổng độ bao phủ của dự án sẽ là phạm vi kiểm tra trong các phần đang được thay đổi. Phạm vi bảo hiểm này phải rất cao ngay từ đầu, mặc dù không thể kiểm tra tất cả các phần của mã bị ảnh hưởng bởi việc tái cấu trúc. Ngoài ra, bạn gặt hái được hầu hết các lợi ích của phạm vi kiểm tra cao trong các thành phần được kiểm tra. Điều đó không hoàn hảo, nhưng vẫn khá tốt.

Lưu ý rằng mặc dù các bài kiểm tra đơn vị dường như là phổ biến, nhưng bắt đầu với các phần nhỏ nhất không phải là một chiến lược phù hợp để có được một phần mềm kế thừa đang được thử nghiệm. Bạn sẽ muốn bắt đầu với các bài kiểm tra tích hợp thực hiện một phần lớn phần mềm cùng một lúc.

Ví dụ: Tôi thấy hữu ích khi trích xuất các trường hợp kiểm thử tích hợp từ các tệp dữ liệu trong thế giới thực. Tất nhiên, việc chạy các thử nghiệm như vậy có thể mất nhiều thời gian, đó là lý do tại sao bạn có thể muốn thiết lập một máy chủ tự động chạy thử nghiệm thường xuyên (ví dụ: máy chủ Jenkins được kích hoạt bởi các cam kết). Chi phí thiết lập và bảo trì một máy chủ như vậy là rất nhỏ so với việc không chạy thử nghiệm thường xuyên, miễn là mọi lỗi thử nghiệm thực sự được khắc phục nhanh chóng.

Đừng viết bài kiểm tra cho mã hiện có. Nó không đáng.

Những gì bạn thực hiện đã được kiểm tra phần nào theo cách hoàn toàn không chính thức - bạn đã thử nó bằng tay liên tục, mọi người đã thực hiện một số thử nghiệm không tự động, hiện đang được sử dụng. Điều đó có nghĩa là bạn sẽ không tìm thấy nhiều lỗi .

Những gì còn lại là những lỗi bạn không nghĩ đến. Nhưng đó chính xác là những bài bạn sẽ không nghĩ để viết bài kiểm tra đơn vị cho một trong hai, vì vậy bạn có thể vẫn không tìm thấy chúng.

Ngoài ra, một lý do cho TDD là để bạn suy nghĩ về những yêu cầu chính xác của một chút mã trước khi viết nó. Trong bất kỳ cách nào khác nhau, bạn đã làm điều đó.

Trong khi đó, việc viết các bài kiểm tra này vẫn còn nhiều việc phải làm trước đó. Nó sẽ tốn rất nhiều thời gian, vì lợi ích nhỏ.

Và thật vô cùng nhàm chán khi viết rất nhiều bài kiểm tra mà không có mã hóa ở giữa và hầu như không tìm thấy bất kỳ lỗi nào. Nếu bạn bắt đầu làm điều này, những người mới sử dụng TDD sẽ ghét nó.

Nói tóm lại, các nhà phát triển sẽ ghét nó và các nhà quản lý sẽ xem nó là tốn kém, trong khi không có nhiều lỗi được tìm thấy. Bạn sẽ không bao giờ có được phần TDD thực tế.

Sử dụng nó vào những thứ mà bạn muốn thay đổi, như một phần bình thường của quy trình.

Một bài kiểm tra là một phương tiện để truyền đạt sự hiểu biết.

Do đó, chỉ viết bài kiểm tra cho những gì bạn hiểu là đúng.

Bạn chỉ có thể hiểu những gì nên đúng khi bạn làm việc với nó.

Do đó, chỉ viết các bài kiểm tra cho mã mà bạn đang làm việc.

Khi bạn làm việc với mã bạn sẽ học.

Do đó, viết và viết lại các bài kiểm tra để nắm bắt những gì bạn đã học.

Rửa sạch và lặp lại.

Có một công cụ bảo hiểm mã chạy với các thử nghiệm của bạn và chỉ chấp nhận các cam kết với dòng chính không làm giảm phạm vi bảo hiểm. Cuối cùng, bạn sẽ đạt đến một mức độ bảo hiểm cao.

Nếu bạn đã không làm việc với mã trong một thời gian, một quyết định kinh doanh cần phải được đưa ra. Bây giờ nó hoàn toàn có thể là di sản đến nỗi không ai trong nhóm của bạn biết cách làm việc với nó. Nó có thể có các thư viện / trình biên dịch / tài liệu lỗi thời, đây là một trách nhiệm lớn về mọi mặt.

Hai lựa chọn:

1. Đầu tư thời gian để đọc nó, học hỏi từ nó, viết bài kiểm tra cho nó và cấu trúc lại nó. Bộ thay đổi nhỏ với bản phát hành thường xuyên.
2. Tìm cách bỏ phần mềm đó. Bạn không thể sửa đổi nó khi được yêu cầu.

(1) Vẫn còn ổn hay tốt để dừng hầu hết sự phát triển và bắt đầu viết toàn bộ các trường hợp thử nghiệm có thể ngay từ đầu, mặc dù mọi thứ đều hoạt động hoàn toàn OKAY (chưa!)?
(2) tốt hơn là chờ đợi điều gì đó xấu xảy ra và sau đó trong quá trình sửa lỗi, hãy viết các bài kiểm tra đơn vị mới

Một trong những mục đích chính của các thử nghiệm là đảm bảo rằng một sự thay đổi không phá vỡ bất cứ điều gì. Đây là một quá trình ba bước:

1. Xác nhận rằng các thử nghiệm thành công
2. Làm bạn thay đổi
3. Xác nhận rằng các bài kiểm tra vẫn thành công

Điều này có nghĩa là bạn cần phải có các bài kiểm tra làm việc trước khi bạn thực sự thay đổi điều gì đó. Nếu bạn chọn đường dẫn thứ hai, điều đó có nghĩa là bạn sẽ phải buộc các nhà phát triển của mình viết bài kiểm tra trước khi họ chạm vào mã. Và tôi cực kỳ nghi ngờ rằng khi đã phải đối mặt với sự thay đổi trong thế giới thực, các nhà phát triển sẽ không cung cấp cho đơn vị kiểm tra sự chú ý mà họ xứng đáng.

Vì vậy, tôi đề nghị tách các tác vụ viết thử và thay đổi để tránh các nhà phát triển hy sinh chất lượng của cái này cho cái kia.

mặc dù mọi thứ đang hoạt động hoàn toàn OKAY (chưa!)?

Chỉ cần chỉ ra điều này một cách cụ thể, đó là một quan niệm sai lầm phổ biến rằng bạn chỉ cần kiểm tra khi mã không hoạt động. Bạn cần kiểm tra khi mã cũng hoạt động, ví dụ để chứng minh với ai đó rằng [lỗi mới xảy ra] không phải do phần của bạn vì các kiểm tra vẫn đang qua.
Xác nhận rằng mọi thứ vẫn hoạt động như trước đây là một lợi ích quan trọng của việc kiểm tra mà bạn bỏ qua khi bạn ngụ ý rằng bạn không cần kiểm tra khi mã đang hoạt động.

(3) thậm chí quên các mã trước đó và chỉ viết các bài kiểm tra đơn vị cho các mã mới và hoãn mọi thứ cho bộ tái cấu trúc chính tiếp theo

Lý tưởng nhất là tất cả các mã nguồn hiện tại sẽ có được các bài kiểm tra đơn vị. Tuy nhiên, có một lập luận hợp lý rằng thời gian và công sức (và chi phí) cần thiết để làm điều đó chỉ đơn giản là không phù hợp với một số dự án nhất định.
Ví dụ: ứng dụng không còn được phát triển và dự kiến ​​sẽ không bị thay đổi nữa (ví dụ: máy khách không còn sử dụng ứng dụng đó nữa hoặc máy khách không còn là máy khách nữa), bạn có thể lập luận rằng nó không còn liên quan để kiểm tra mã này nữa .

Tuy nhiên, nó không rõ ràng như nơi bạn vẽ đường. Đây là điều mà một công ty cần xem xét trong phân tích lợi ích chi phí. Viết bài kiểm tra tốn thời gian và công sức, nhưng họ có mong đợi bất kỳ sự phát triển nào trong tương lai trên ứng dụng đó không? Do lợi ích từ việc kiểm tra đơn vị lớn hơn chi phí viết chúng?

Đây không phải là một quyết định mà bạn (với tư cách là một nhà phát triển) có thể đưa ra. Tốt nhất, bạn có thể đưa ra ước tính về thời gian cần thiết để thực hiện các thử nghiệm trên một dự án nhất định và tùy thuộc vào quản lý để quyết định xem có đủ kỳ vọng thực sự cần duy trì / phát triển dự án hay không.

và hoãn lại mọi thứ để tái cấu trúc chính tiếp theo

Nếu công cụ tái cấu trúc chính tiếp theo là nhất định, thì bạn thực sự cần phải viết các bài kiểm tra.

Nhưng đừng tắt nó cho đến khi bạn phải đối mặt với những thay đổi lớn. Điểm ban đầu của tôi (không kết hợp việc viết các bài kiểm tra và cập nhật mã) vẫn còn, nhưng tôi muốn thêm một điểm thứ hai ở đây: các nhà phát triển của bạn hiện biết cách của họ xung quanh dự án tốt hơn họ trong sáu tháng nếu họ dành thời gian đó để làm việc trên các dự án khác. Tận dụng khoảng thời gian mà các nhà phát triển đã được làm nóng và không cần phải tìm ra cách mọi thứ hoạt động trở lại trong tương lai.

Theo quan điểm của tôi:

Đợi một bản nâng cấp kỹ thuật lớn cho hệ thống và viết các bài kiểm tra sau đó ... chính thức với sự hỗ trợ của doanh nghiệp.

Ngoài ra, giả sử bạn là một cửa hàng SCRUM, khối lượng công việc của bạn được thể hiện theo năng lực và bạn có thể phân bổ% cho số đó cho thử nghiệm đơn vị, nhưng ...

Nói rằng bạn sẽ quay lại và viết các bài kiểm tra là ngây thơ, điều bạn thực sự sẽ làm là viết các bài kiểm tra, tái cấu trúc và viết thêm các bài kiểm tra sau khi trình tái cấu trúc đã làm cho mã dễ kiểm tra hơn, đó là lý do tại sao tốt nhất để bắt đầu với các bài kiểm tra như bạn đã biết, và ...

Tốt nhất là tác giả ban đầu viết các bài kiểm tra và cấu trúc lại mã mà họ đã viết trước đó, nó không lý tưởng, nhưng từ kinh nghiệm bạn muốn bộ tái cấu trúc làm cho mã tốt hơn không tệ hơn.