Làm thế nào để thúc đẩy đồng nghiệp viết bài kiểm tra đơn vị? [đóng cửa]

Chúng tôi đang làm việc trên một sản phẩm lớn đã được sản xuất khoảng 5 năm. Các codebase là .. erm .. làm việc. Không thực sự tốt nhưng nó đang làm việc. Các tính năng mới được đưa vào sản xuất và được thử nghiệm với một QA nhỏ. Lỗi là cố định, vv Nhưng không ai, ngoại trừ tôi, đang viết bài kiểm tra đơn vị. Không ai sử dụng sức mạnh của việc "theo dõi" các lỗi bằng cách viết các bài kiểm tra đơn vị để đảm bảo lỗi đặc biệt này (trường hợp kiểm thử) sẽ không bao giờ xảy ra nữa.

Tôi đã nói chuyện với quản lý. Tôi đã nói chuyện với các nhà phát triển. Tôi đã nói chuyện với tất cả mọi người trong toàn công ty. Mọi người nói: "Đúng, chúng ta phải viết thêm bài kiểm tra đơn vị!" Đó là khoảng một năm trước. Kể từ đó, tôi đã buộc phải giới thiệu đánh giá mã trước khi cam kết ( Gerrit ) và tích hợp liên tục ( Jenkins ).

Tôi đã tổ chức một số cuộc họp về bài kiểm tra đơn vị và tôi cũng cho thấy những lợi ích của việc viết bài kiểm tra đơn vị. Nhưng dường như không ai quan tâm.

Câu 1: Làm thế nào để tôi thúc đẩy các đồng nghiệp của mình viết bài kiểm tra đơn vị?

Câu 2: Làm thế nào để tôi có động lực tuân theo các tiêu chuẩn chất lượng mã cá nhân? (Đôi khi nó thực sự gây nản lòng!)

PS: Một số sự thật gây nản lòng (đạt được trong 1 năm):

• Tổng số bài kiểm tra đơn vị: 1693
• Tổng số "ví dụ đơn vị kiểm tra": khoảng 50
• Thực hiện bởi tôi: 1521

Chỉnh sửa: Tôi có mong đợi quá nhiều không? Đó là nơi làm việc đầu tiên của tôi và tôi đang cố gắng làm hết sức mình.

Chỉnh sửa 2: Dựa trên tất cả các câu trả lời Tôi đã tạo một danh sách kiểm tra nhỏ cho chính mình. Tôi đã nói chuyện riêng với hai nhà phát triển và chúng tôi đã có một cuộc nói chuyện tốt và trung thực.

Một trong số họ nói với tôi, như Telastyn nói, rằng anh ta thực sự không thoải mái với các bài kiểm tra đơn vị. Anh ấy nói rằng anh ấy muốn "chuyên nghiệp hơn" nhưng anh ấy cần một cú đá. Ông cũng nói rằng cuộc họp thử nghiệm đơn vị của chúng tôi với tất cả các nhà phát triển (khoảng 9-11) là tốt, nhưng nó quá đông. Meh. Một số nhà phê bình cho tôi, nhưng tôi sẽ học hỏi từ đó. (xem câu trả lời dưới đây về các cuộc họp tdd kata!)

Một người khác nói rằng anh ta không quan tâm đến việc viết bài kiểm tra đơn vị. Anh ấy nghĩ rằng công việc của anh ấy đủ tốt cho mức lương của anh ấy. Anh ấy không muốn nỗ lực nhiều hơn nữa. Tôi không nói nên lời. 9-5 "công nhân" điển hình.

Tuần tới tôi sẽ nói chuyện với các nhà phát triển khác.

Cảm ơn câu trả lời tuyệt vời của bạn (cho đến nay!) Và hỗ trợ của bạn. Tôi rất trân trọng điều này! Tôi đã học được rất nhiều, cảm ơn bạn rất nhiều!

Tôi nhận thấy rằng nói về TDD hầu như không hoạt động. Mọi người thích xem kết quả thô . Nói rằng "bài kiểm tra viết sẽ giảm thời gian phát triển" rất có thể đúng, nhưng nó có thể không đủ để khiến bất kỳ ai bị thuyết phục.

Tôi đã ở vị trí tương tự (tốt, không tệ như của bạn) và nó đã tự giải quyết khi mọi người bắt đầu làm việc với mã của tôi (lưu ý: mã của tôi đã được kiểm tra đơn vị, những người khác không quá nhiều). Khi một cái gì đó ngừng hoạt động, theo dõi tự nhiên sau khi điều tra địa phương là để hỏi tôi lý do có thể là gì . Sau đó chúng tôi ngồi, chúng tôi chạy thử nghiệm đơn vị và xem những gì đã xảy ra. Nếu các bài kiểm tra đã qua, hầu hết các vấn đề về thời gian nằm ở mã mới, chưa được kiểm tra. Nếu không, các bài kiểm tra thường có thể phát hiện ra vấn đề (hoặc ít nhất là chỉ cho chúng tôi đi đúng hướng). Chúng tôi đã sửa lỗi, các bài kiểm tra đã hoạt động trở lại, mọi người đều vui vẻ.

Tóm lại, một vài tình huống như thế này đã xảy ra và thêm 2 nhà phát triển đã trở thành những người đam mê thử nghiệm TDD (vẫn còn một vài điều nữa để thực hiện, nhưng có vẻ đầy hứa hẹn).

Về lời khuyên, bạn có thể thử đi với TDD kata; nhiệm vụ đơn giản để thực hiện bằng cách sử dụng phương pháp thử nghiệm đầu tiên thay vì không thử nghiệm . Tùy thuộc vào mức độ phức tạp của nhiệm vụ, cách tiếp cận không kiểm tra thường sẽ chậm hơn, đặc biệt là với các thay đổi bắt buộc gia tăng:

• Máy tính chuỗi của Roy
• Ngân hàng OCR

Chỉnh sửa : Nhận xét của OP khiến tôi nhận ra có tranh luận thậm chí còn mạnh mẽ hơn theo ý của mình - hồi quy hay trả lại lỗi . Những tình huống đó là những ví dụ hoàn hảo chứng minh các bài kiểm tra đơn vị có lợi như thế nào. Những người thích những con số - như tôi đã nói, nói "kiểm tra đơn vị là tốt" có thể không thuyết phục, nhưng sắp xếp dữ liệu như dưới đây chắc chắn có thể là:

• dành thời gian để thực hiện tính năng (không có bài kiểm tra nào được viết; tôi cho rằng điều này xảy ra thường xuyên nên việc tìm ví dụ như vậy tương đối dễ dàng)
• thời gian ước tính để thực hiện tính năng với TDD (hoặc thậm chí các thử nghiệm sau khi tiếp cận; không quan trọng - điều quan trọng là sự hiện diện của các thử nghiệm đơn vị)
• đã dành thời gian để giải quyết lỗi trên mã chưa được kiểm tra so với mã đã kiểm tra

Một điều cần cảnh báo bạn (sự di chuyển này là rõ ràng nhưng đáng chú ý): kết quả thiên vị - đảm bảo bạn không chọn ví dụ trong đó cách duy nhất để phát hiện lỗi với kiểm tra là viết thử nghiệm cho lỗi đó. Thông thường, không ai biết lỗi sẽ xảy ra trước mắt, nhưng thật hấp dẫn khi nói rằng "con người lỗi này sẽ tầm thường nếu chúng ta thử nghiệm X" - thật dễ dàng để tìm ra chiến thuật chiến thắng cho một cuộc chiến sau khi nó kết thúc.

Kết quả của những ví dụ đó là câu hỏi đơn giản - nếu bạn có thể dành x giờ để phát triển tính năng Y, tại sao lại khăng khăng làm điều đó trong 2 lần ?

Trước tiên, bạn phải biết lý do tại sao họ không viết bài kiểm tra.

Lịch trình chặt chẽ thường là lý do, nhưng bạn nói rằng bạn không có điều đó.

Lý do tiếp theo là với một cơ sở mã chưa được kiểm tra lớn, các bài kiểm tra viết có thể dường như quá sức - một công việc không bao giờ kết thúc (như giặt ủi và thú vị như vậy). Vì vậy, bản chất của con người là nghĩ rằng quá nhiều thứ phải đối mặt, vì vậy tôi sẽ bỏ qua nó.

Một lý do khác có thể là trong khi họ nghĩ rằng các bài kiểm tra là một ý tưởng tốt, họ không tự tin về cách bắt đầu viết chúng đặc biệt là nếu họ chưa bao giờ làm việc ở bất cứ nơi nào đã viết chúng.

Một khả năng mạnh mẽ khác là bởi vì họ thực sự không thấy bất kỳ giá trị nào cho công việc nhiều hơn mặc dù họ đang cung cấp dịch vụ môi cho ý tưởng.

Vậy làm thế nào để bạn xử lý các lý do khác nhau?

Lý do một là đơn giản, chỉ cho họ một ví dụ về cách nó tiết kiệm thời gian phát triển.

Lý do hai - cho họ thấy bạn đã viết bao nhiêu bài kiểm tra trong một năm và bao nhiêu phần trăm cơ sở mã mà nó bao gồm. Làm toán để chỉ ra có bao nhiêu bài kiểm tra mà họ có thể có vào thời điểm này vào năm tới nếu họ làm điều này. Một khi họ thấy rằng một chút tiến bộ trên cơ sở hàng ngày thực sự cộng lại, toàn bộ ý tưởng không quá áp đảo. Nếu bạn có thể rút dữ liệu ra khỏi hệ thống, hãy cho họ biết có bao nhiêu lỗi đã lặp lại lỗi trong các phần chưa được kiểm tra của mã và có bao nhiêu lỗi lặp lại xuất hiện trong mã với các bài kiểm tra đơn vị.

Lý do 3 là đào tạo, không chỉ hiển thị. Làm cho họ viết bài kiểm tra trong một lớp đào tạo.

Lý do 4, đây là mấu chốt của vấn đề. Đầu tiên, chọn một điểm đau, một trong những lỗi đã quay trở lại nhiều lần. Khi điều đó đến, đây là lúc để đề xuất với ban quản lý rằng nếu họ có các bài kiểm tra đơn vị cho mặt hàng này, nó sẽ không quay trở lại như một đồng xu xấu.

Một cách khác để giải quyết lý do 4 là quản lý làm cho nó trở thành một phần của quy trình và mã không vượt qua đánh giá mã trừ khi các kiểm tra cũng vượt qua đánh giá mã. Tốt nhất nên tiếp cận họ với việc biến điều này thành một chính sách ngay sau một trong những điểm đau đớn đó hoặc tốt nhất là ngay sau khi bạn đã có vài lần trong vài ngày.

Tất cả chúng ta đều muốn nghĩ rằng với tư cách là nhà phát triển chúng ta tự quản lý (LOL), nhưng người tham vọng sẽ quan tâm đến những gì quản lý nhấn mạnh với họ rằng họ nên quan tâm và các chuyên gia thực sự tự quản lý đã viết bài kiểm tra. Nếu họ không quan tâm đến việc chuyên nghiệp và thực hiện các thực tiễn tốt nhất vì họ cải thiện sản phẩm hoặc quan tâm đến việc gây ấn tượng với các nhà quản lý để được thăng chức (hoặc không bị sa thải), thì bạn có thể cân nhắc nếu đây là nơi phù hợp với bạn. Nếu bạn không thể quản lý để quan tâm đến các thực tiễn tốt nhất, thì bạn sẽ chiến đấu một trận chiến khó khăn hết lần này đến lần khác, bạn có thể đánh giá xem đây có phải là văn hóa doanh nghiệp phù hợp với bạn không. Mặc dù mọi nơi làm việc đều có vấn đề của nó (và chạy trốn không phải lúc nào cũng là câu trả lời), nơi này dường như không phù hợp với mức độ chuyên nghiệp của bạn.

Tôi sẽ bắt đầu bằng cách chứng minh những lợi ích của TDD. Cố gắng thể hiện lợi ích của thử nghiệm đơn vị.

Là con người bình thường, các nhà phát triển được thúc đẩy bởi lợi ích. Họ không muốn làm những việc chỉ tạo ra nhiều việc hơn. Kiểm tra đơn vị có nghĩa là công việc ít hơn . Nó có nghĩa là đi chơi với bạn bè nhiều hơn. Điều đó có nghĩa là có nhiều niềm vui hơn vì bạn không phải mất hàng đêm để viết mã đến 11 giờ tối. Nó có nghĩa là đi nghỉ nhiều hơn với sự yên tâm.

Một trong những lợi ích lớn nhất của TDD là bạn có thể cấu trúc lại chương trình của mình thành một thiết kế tốt hơn hoặc chỉ thay đổi tên của một thứ gì đó ... và miễn là thiết kế đó không phá vỡ các thử nghiệm, bạn có thể tin tưởng 100% rằng thay đổi của mình không phá vỡ bất cứ điều gì.

Một trường hợp tuyệt vời khác cho TDD là tạo các bài kiểm tra đơn vị cho mã kế thừa . Điều này sẽ đại diện cho một trong những cách tốt nhất để bắt đầu tái cấu trúc tà ác. Về lâu dài, điều này sẽ phục vụ để nâng cao kiến ​​thức của bạn về cơ sở mã, hiểu được điểm mạnh và sai sót của nó, phát hiện logic kinh doanh được mã hóa cứng trong mã và cho bạn một khởi đầu tốt để cải thiện chất lượng tiến về phía trước!

Tài liệu tham khảo tốt để đọc thêm:

• Tại sao bạn nên viết bài kiểm tra đơn vị
• Tầm nhìn động lực và kiểm tra đơn vị
• Nghệ thuật thử nghiệm đơn vị, theo Roy Osherove

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-wr-unit-tests-first

Tôi nghĩ rằng tôi đã đánh dấu liên kết đó từ một bài viết của Jeff Atwood một thời gian trước đây [sửa: vâng, đây là] . Cũ nhưng có liên quan. Do những lợi ích này và những lợi ích khác chắc chắn sẽ được nêu ra trong các câu trả lời khác, các lập trình viên của bạn sẽ có thể tự thúc đẩy mình ! Nó sẽ cho phép họ làm việc hiệu quả hơn và do đó làm cho công việc của họ dễ dàng hơn một chút. Ai không muốn điều đó?

Liên quan đến câu hỏi thứ 2 của bạn: ý thức về quyền sở hữu và niềm tự hào về các tiêu chuẩn chất lượng mã của bạn sẽ giúp bạn tiếp tục với chúng . Hãy suy nghĩ về những gì bạn muốn đạt được bằng cách có những tiêu chuẩn như vậy và ai được hưởng lợi từ chúng. Các tiêu chuẩn mã cá nhân của tôi cũng có thể gây nản lòng, nhưng tôi luôn cảm thấy như tôi đang làm cho thế giới / công ty / nhóm ủng hộ bằng cách thực hiện chúng. Vì vậy, tôi không nghĩ rằng bạn đang cố gắng làm quá nhiều - kết quả sẽ thay đổi theo từng nơi nhưng ít nhất bạn đang nỗ lực.

Đây có vẻ như là một trường hợp lớn của chì .

Có hai khía cạnh vốn có của bản chất con người bạn đang chiến đấu:

• Những người sáng tạo không thích quá trình.
• Hầu hết mọi người không thích những đánh giá tiêu cực bên ngoài về chất lượng của họ.

Rất khó để chống lại điều này bằng các bài giảng, tuyên bố quản lý hoặc thậm chí logic. Bạn phải giành chiến thắng bằng cách tận dụng một khía cạnh khác của bản chất con người.

• Mọi người bắt chước hành vi của những nhân viên giỏi nhất

Nếu những nhân viên giỏi nhất sử dụng TDD và nó hoạt động, quy trình sẽ mở rộng. Nếu họ không, nó sẽ không. Nếu bạn cần thuyết phục bất cứ ai, đó là 1 hoặc 2 nhân viên hàng đầu.

Hỏi họ.

Bạn nói rằng mọi người đã được nói, và đồng ý rằng họ nên viết nhiều bài kiểm tra hơn. Tại sao họ không?

Nó có thể không (thường không phải là) một vấn đề của động lực đơn giản. Họ có thể quên chúng. Họ có thể cảm thấy dưới áp lực thời gian. Họ có thể không biết làm thế nào để viết bài kiểm tra tốt. Họ có thể nghĩ rằng bạn tốt đến mức họ không cần phải làm điều đó. Biết nguyên nhân gốc rễ sẽ giúp bạn giải quyết vấn đề tốt hơn.

Bạn sẽ nghĩ các bài kiểm tra đơn vị sẽ là bán chính họ. Tôi không biết công ty của bạn hoạt động như thế nào, nhưng khi có vấn đề trong quá trình sản xuất, chúng tôi sẽ làm việc cho đến khi nó được khắc phục. Sẽ không có vấn đề gì nếu nó xảy ra lúc 2 giờ sáng vào Chủ nhật. Điều này rất hiếm đối với chúng tôi, nhưng khi nó xảy ra, nó hút.

Tôi sẽ bắt đầu bằng cách hỏi họ bao nhiêu lần họ phải thức dậy vào giữa đêm để khắc phục một số vấn đề lớn có thể dễ dàng được tìm thấy thử nghiệm tự động. Điều đó không có nghĩa là kiểm tra tự động sẽ khắc phục mọi thứ, nhưng nó sẽ giúp giảm bớt điều đó.

Người bán lớn thứ hai là chu kỳ QA. Trước khi bắt đầu TDD trong công ty của tôi, chúng tôi sẽ đẩy các bản phát hành mới đến QA để kiểm tra mỗi tuần. Họ sẽ tạo ra một đống lỗi phát hành, chúng tôi sửa những lỗi đó và đẩy một bản phát hành khác. Lặp lại cho đến khi hoàn thành. Dự án đầu tiên chúng tôi đã thực hiện TDD không yêu cầu đẩy ra QA cho đến vài tuần sau đó. Và số lượng lỗi được tìm thấy là rất, rất nhỏ. 10% so với một dự án tương tự. Bạn có cách nào để biên dịch các số liệu thống kê cho nhóm của bạn không?

Điểm bán hàng lớn khác là cách mã được chăm sóc TDD, nó dễ đọc hơn, vì chúng tôi muốn làm cho nó dễ kiểm tra hơn. Hiển thị so sánh giữa mã được viết cho các bài kiểm tra đơn vị và mã không được viết.

Cuối cùng, chỉ cho họ cách họ có thể cấu trúc lại mã một cách tự tin.

Hãy ghi nhớ tất cả những điều đó khi bạn không muốn viết bài kiểm tra. :)

Tôi muốn mở rộng theo câu trả lời của HLGEM , đặc biệt là phần này:

Lý do tiếp theo là với một cơ sở mã chưa được kiểm tra lớn, các bài kiểm tra viết có thể dường như quá sức - một công việc không bao giờ kết thúc (như giặt ủi và thú vị như vậy). Vì vậy, bản chất của con người là nghĩ rằng quá nhiều thứ phải đối mặt, vì vậy tôi sẽ bỏ qua nó.

Tôi đã thấy rằng mã tôi viết với ý định viết các bài kiểm tra là mã tốt hơn đáng kể so với mã tôi viết mà không có ý định viết các bài kiểm tra; Tự hỏi Làm thế nào tôi sẽ kiểm tra chức năng này? buộc một thiết kế tốt hơn của mỗi và mọi chức năng. (Ít phụ thuộc vào dữ liệu toàn cầu hoặc bán toàn cầu; IO tách khỏi tính toán; các hàm chỉ làm một việc; xử lý lỗi nhất quán, v.v.)

Cố gắng đưa các bài kiểm tra vào mã cũ không được viết với kiểm tra trong tâm trí có thể vượt quá sự bực bội.

Tôi đã sử dụng một vài kỹ thuật:

a) thiết lập một bản dựng tự động. Khi ai đó phá vỡ thứ gì đó mà bạn đã kiểm tra, hãy cho họ thấy thử nghiệm đã phát hiện ra nó và lỗi nghiêm trọng như thế nào.

b) Làm các dự án phức tạp với các bài kiểm tra (bạn lái xe). Điều này sẽ cho thấy có bao nhiêu lỗi tồn tại trong dự án đó. Tôi đã có một dự án tương tác máy chủ phức tạp bắt đầu hoạt động hoàn hảo. Nó không bao giờ thất bại QA và tất cả các bài kiểm tra tích hợp đã diễn ra suôn sẻ 100%. Hệ thống đó được biết đến như là sự ổn định cao và quản lý tổng thể hài lòng với nó. Những gì bạn làm trong những tình huống này là trình bày cách kiểm tra đơn vị cho phép điều đó.

c) Kéo một người tại một thời điểm. Người lắng nghe bạn. Nhận lỗi và cho thấy các bài kiểm tra phơi bày các vấn đề sâu sắc và khó khăn như thế nào. Điều này có ích. Nó không bao giờ là một điều dễ dàng. Nhưng một khi bạn có được một người hâm mộ, anh ấy sẽ chỉ giúp đỡ. Đó là hiệu ứng domino.

Nướng thử nghiệm đơn vị trong quá trình. Nếu một lỗi hiển thị trong sản xuất quá rõ ràng để bắt trong bài kiểm tra đơn vị thì anh chàng này sẽ nhận lỗi. Chỉ định mọi người viết mỗi bài kiểm tra họ thực hiện. Chọn ngẫu nhiên các trường hợp và xem việc thực hiện vài trường hợp mỗi tuần. Bằng cách thực hiện các bài kiểm tra đơn vị, mọi người sẽ hỏi về các yêu cầu và cuối cùng gắn các yêu cầu để phát triển và hy vọng phát triển phần mềm vừa yêu cầu vừa hoạt động :)