Nhận bóng lăn trên TDD


10

Tôi là thành viên của nhóm phát triển làm việc với nhiều nhóm khác để duy trì và cải thiện ứng dụng đã được sử dụng ít nhất 15 năm. Khi lần đầu tiên được xây dựng và thiết kế, TDD chưa từng nghe thấy.

Ứng dụng này khá ổn định và chúng tôi hiếm khi gặp lỗi dừng hiển thị, nhưng chúng tôi làm trung bình khoảng một hoặc hai lỗi mỗi tuần làm giảm nghiêm trọng chất lượng dịch vụ. Các lỗi này mất mãi mãi để tìm và sửa, phần lớn là do ngón tay trỏ và thử nghiệm duy nhất chúng tôi có là kiểm tra giao diện. Bởi vì có rất nhiều thời gian lãng phí để tìm ra lỗi ở đâu trước khi nó có thể được sửa, tôi và một nhà phát triển khác có kế hoạch đề xuất Phát triển hướng thử nghiệm. Sắp có một cuộc đại tu mới và chúng tôi muốn thấy thử nghiệm đơn vị gần hoàn thành được thực hiện trên các mô-đun mới, chúng tôi cũng có kế hoạch đề xuất xây dựng các đơn vị thử nghiệm cho bất kỳ mã nào chúng tôi phải thay đổi đó là kế thừa (ví dụ: sửa lỗi hoặc triển khai tính năng ), nhưng không dành thời gian phát triển các trường hợp thử nghiệm cho mã không gây ra sự cố.

Đối với tôi, điều này có vẻ hợp lý. Tháng này chúng tôi đã có một lỗi mất hơn hai tuần để sửa, nhưng có thể đã được xác định trước khi triển khai nếu thử nghiệm đơn vị đã được thực hiện. Nhưng đối với người quản lý của chúng tôi, có vẻ như họ sẽ chi nhiều tiền hơn.

Làm thế nào để tôi thuyết phục khách hàng của mình rằng họ muốn chi tiền cho thử nghiệm đơn vị và phát triển theo hướng thử nghiệm? Có nghiên cứu nào cho thấy ROI của thử nghiệm đơn vị không?


1
quá muộn cho TDD; xem "Làm việc với mã kế thừa" của Michael Feathers
Steven A. Lowe

Bước 1. Tìm kiếm Stack Overflow. Điều này đã được hỏi. Và trả lời. Ví dụ: stackoverflow.com/search?q=starting+tdd
S.Lott

Câu trả lời:


6

Kết hợp trực tiếp TDD toàn diện vào một mã kế thừa, dự án bảo trì là một việc rất khó bán. Một cách tiếp cận tôi đã thấy làm việc rất tốt là đây. Đối với mỗi lỗi xuất hiện, hãy tạo một thử nghiệm không đơn vị tự động để chứng minh lỗi đó. Theo "phi đơn vị", ý tôi là thứ gì đó có thể chạm vào nhiều phần của hệ thống, nhấn cơ sở dữ liệu và hệ thống tập tin, v.v. - nhưng với "tự động" tôi có nghĩa là chạy mà không có sự tương tác của con người. Đây là loại thử nghiệm mà bạn sẽ muốn trong bộ hồi quy của mình trong bất kỳ sự kiện nào. Viết nó hoàn thành rất nhiều thứ: nó làm cho bạn làm cho mã có thể kiểm tra được, ngay cả khi ở mức độ rất thô đó và nó đưa bạn đến chòm sao mã có thể có liên quan đến lỗi, vì vậy nó sẽ giáo dục và thông báo cho bạn về tài liệu rất cụ thể có liên quan.

Nhưng đó không phải là kết thúc của nó. Khi kiểm tra này đang chạy và chạy màu đỏ (thể hiện lỗi trong mã), hãy dành thời gian để tìm ra lỗi sai (bạn phải làm điều này, trong mọi trường hợp). Nhưng đừng sửa nó. Khi bạn đã cô lập những gì bạn nghĩ là vấn đề - hãy viết một đơn vịkiểm tra chứng minh vấn đề đó. Bây giờ bạn đã có một cái gì đó bạn có thể làm việc với (và, không phải ngẫu nhiên, bạn có thể phải cấu trúc lại một chút để có thể kiểm tra tốt hơn). Sửa lỗi. Xem vượt qua bài kiểm tra đơn vị. Có thể thịt nó ra với một số trường hợp cạnh; có được một đơn vị đó - đơn vị chỉ khiến bạn mất hai tuần thời gian - vững chắc và sạch sẽ và được kiểm tra tốt. Bây giờ hãy chạy thử nghiệm hồi quy và xem nó vượt qua (tất nhiên, nếu không, bạn đã có thêm một số công việc nghiên cứu và cấp độ đơn vị để thực hiện - lặp đi lặp lại cho đến khi nó cũng trôi qua). Kiểm tra tất cả trong. Bạn có gì? Kiểm tra hồi quy cho mã lỗi trước đó. Kiểm tra đơn vị cho mã lỗi trước đó. Mã làm việc đã thất bại. Mã được thiết kế tốt hơn, bởi vì bây giờ nó dễ kiểm tra hơn nó. Tự tin hơn về cơ sở mã của bạn,

Đó không phải là "thuần túy" TDD. Nhưng nó cho thấy kết quả, nhanh chóng và cải thiện chất lượng mã của bạn theo thời gian. Kết quả sẽ giúp bạn có được quản lý mua.


Gợi ý tuyệt vời, nhưng tôi nghĩ OP đang tìm kiếm một lập luận thuyết phục hơn để biện minh cho việc có thêm thời gian cần thiết để thực hiện kiểu tiếp cận này.
Bernard

Có lẽ tôi cần phải điều chỉnh lại nó. Điều tôi cố gắng bày tỏ là hầu hết những nỗ lực được mô tả là cần thiết dù sao đi nữa - thời gian làm thêm rất khiêm tốn, vì lợi ích đáng kể. Tôi xin lỗi nếu điều đó không rõ ràng.
Carl Manaster

Rõ ràng với tôi là một nhà phát triển, nhưng tôi biết rằng quản lý thường cần một lập luận rất thuyết phục (tức là biện minh cho chi phí).
Bernard

Đó là những gì tôi đề nghị trong đoạn thứ hai của mình trong câu hỏi. Chúng tôi sẽ viết TDD cho "mã mới" và viết các trường hợp thử nghiệm cho bất kỳ mã kế thừa nào mà chúng tôi đã thay đổi bởi lỗi hoặc yêu cầu tính năng.
Malfist

3

Tại công ty của tôi, tôi chỉ sử dụng phương pháp "chỉ một tiếng cằn nhằn" từ JoelOnSoftware và bắt đầu viết các bài kiểm tra đơn vị bất cứ khi nào tôi thường đơn giản là đã hack một số ứng dụng bảng điều khiển vứt đi. Tôi bắt đầu hoàn thành công việc nhanh hơn rất nhiều với các bản phát hành ổn định hơn và được chú ý vì nó. Khi được hỏi tôi đang làm gì, tôi đã giải thích rằng tôi đã bắt đầu sử dụng TDD và viết các bài kiểm tra đơn vị bất cứ khi nào tôi sửa đổi mã cũ hoặc viết bất kỳ mã mới nào. Các nhà phát triển đồng nghiệp của tôi bắt đầu tò mò và bắt đầu sử dụng các bài kiểm tra đơn vị tích hợp. Tôi không nghĩ rằng có một lập luận tốt về việc viết các bài kiểm tra để viết mã kế thừa, nhưng nếu bạn có thể làm cho trường hợp viết bài kiểm tra tự động nhanh hơn và thuận tiện hơn so với viết spaghetti hack console, thì các nhà phát triển thông minh sẽ làm theo.Những lợi ích khác dẫn đến phần mềm chất lượng cao hơn cũng sẽ có, nhưng chìa khóa để có được nhà phát triển đăng nhập là cho thấy rằng nó làm cho cuộc sống của họ dễ dàng hơn. Theo như doanh nghiệp ký, thực tế là nó sẽ mang lại phần mềm tốt hơn và có thể mất ít thời gian hơn để vận chuyển so với trước đây là quá đủ để thuyết phục họ.


0

Trước hết, cần đánh giá cao thái độ và ý thức chân thành của bạn đối với giá trị chất lượng vào tiền của khách hàng. Và đây là suy nghĩ của tôi về cách bạn có thể thuyết phục người quản lý và khách hàng của mình:

  • Thu thập số liệu về các lỗi mà bạn đã sửa trong 6 tháng qua và thời gian tối thiểu, trung bình và tối đa mà bạn mất để sửa lỗi.
  • Đối với tất cả các lỗi mà bạn đã sửa hoặc có bối cảnh, hãy thử viết bài kiểm tra đơn vị bao gồm các khu vực đó.
  • Đối với các lỗi mà bạn đang làm việc và những lỗi bạn sẽ làm việc, hãy thử viết bài kiểm tra đơn vị xung quanh các khu vực đó ngay cả trước khi bạn thực hiện bất kỳ thay đổi nào. Sau đó viết mã để tìm ra nguyên nhân và khắc phục nó. Xem nếu nó phá vỡ bất kỳ trường hợp thử nghiệm hiện tại của bạn. Nếu có, sau đó giải thích và giúp các đồng nghiệp của bạn hiểu tầm quan trọng của Bài kiểm tra đơn vị.
  • Khi tất cả các nhà phát triển hiểu tầm quan trọng của Bài kiểm tra đơn vị, hãy yêu cầu họ tiếp tục làm những gì bạn đã làm trong nhiều ngày / tuần.
  • Khi thời gian trôi qua, năng suất của các nhóm sẽ cải thiện đến mức cả người quản lý và khách hàng của bạn sẽ ngạc nhiên về tốc độ cải thiện năng suất và chất lượng mã. Nó hơi tốn thời gian, nhưng đáng để thử.

Có một cách khác, và đó là thử tham gia với người quản lý của bạn để tham dự Hội nghị Agile diễn ra xung quanh. Nó chắc chắn nên có giá trị tham dự.

Nếu bạn nghĩ rằng không có gì hoạt động, sau đó di chuyển ... tham gia vào nơi phù hợp với bạn. Ứng cử viên, đây là những gì tôi đã làm. Khi mọi thứ thất bại, tôi tiếp tục;)

Và biết những gì Đơn vị kiểm tra sau khi viết mã không thực sự là TDD, nhưng sau đó luôn có thể là bước đầu tiên. Nó phù hợp rất tốt ở đây ít nhất.

Chúc bạn may mắn và thành công!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.