Kiểm tra đơn vị và tích hợp: Làm thế nào nó có thể trở thành một phản xạ

Tất cả các lập trình viên trong nhóm của tôi đều quen thuộc với thử nghiệm đơn vị và thử nghiệm tích hợp. Chúng tôi đã làm việc với nó. Chúng tôi có tất cả các bài kiểm tra bằng văn bản với nó. Một số người trong chúng ta thậm chí đã cảm thấy được cải thiện cảm giác tin tưởng vào mã của riêng mình.

Tuy nhiên, vì một số lý do, các bài kiểm tra đơn vị / tích hợp đã không trở thành một phản xạ cho bất kỳ thành viên nào trong nhóm. Không ai trong chúng ta thực sự cảm thấy tồi tệ khi không viết bài kiểm tra đơn vị cùng lúc với mã thực tế. Do đó, cơ sở mã của chúng tôi hầu hết không được phát hiện bởi các thử nghiệm đơn vị và các dự án được đưa vào sản xuất chưa được kiểm tra.

Tất nhiên, vấn đề với điều đó là một khi các dự án của bạn đang được sản xuất và đang hoạt động tốt, hầu như không thể có được thời gian và / hoặc ngân sách để thêm thử nghiệm đơn vị / tích hợp.

Các thành viên trong nhóm của tôi và bản thân tôi đã quen thuộc với giá trị của thử nghiệm đơn vị ( 1 , 2 ) nhưng dường như không giúp đưa thử nghiệm đơn vị vào quy trình làm việc tự nhiên của chúng tôi. Theo kinh nghiệm của tôi, việc thực hiện các bài kiểm tra đơn vị và / hoặc bảo hiểm mục tiêu bắt buộc chỉ dẫn đến các bài kiểm tra chất lượng kém và làm chậm các thành viên trong nhóm chỉ vì không có động lực tự tạo để tạo ra các bài kiểm tra này. Ngoài ra, ngay khi áp suất giảm, các bài kiểm tra đơn vị không được viết nữa.

Câu hỏi của tôi là như sau: Có phương pháp nào bạn đã thử nghiệm giúp xây dựng động lực / động lực trong nhóm, dẫn đến mọi người tự nhiên muốn tạo và duy trì các thử nghiệm đó không?

Không ai trong chúng ta thực sự cảm thấy tồi tệ khi không viết bài kiểm tra đơn vị cùng lúc với mã thực tế.

Đây là điểm bạn cần giải quyết. Văn hóa của nhóm của bạn cần thay đổi để không viết các bài kiểm tra trong giai đoạn nước rút (hoặc bất kỳ đơn vị thời gian nào bạn sử dụng) sẽ trở thành một mã giống như các giá trị mã hóa cứng. Phần lớn trong số đó liên quan đến áp lực ngang hàng. Không ai thực sự muốn được xem là không đạt tiêu chuẩn.

Tự làm các bài kiểm tra. Rõ ràng là tự mắng mình khi bạn không làm chúng. Chỉ ra nơi một lập trình viên "tốt" sẽ bắt lỗi đó nếu họ viết bài kiểm tra đơn vị. Không ai muốn xấu cả. Làm cho nó rằng hành vi không mong muốn này là xấu và mọi người sẽ làm theo.

Để toàn bộ một nhóm thực sự muốn điều tương tự có thể khá khó khăn. Thông thường, việc nhìn thấy giá trị trong một thứ gì đó không đủ để khuyến khích mọi người thay đổi hành vi ăn sâu. Ngay cả những người coi trọng sự thay đổi và đặc biệt muốn nó đôi khi cũng có thể chịu trách nhiệm cho tiềm thức chiến đấu với nó.

Vấn đề thực sự là một trong những động lực cá nhân và không phải động lực nhóm như vậy. Sẽ có lúc một khoảnh khắc rõ ràng đến với bạn, do kết quả của một điều gì đó mà bạn cảm thấy cuối cùng bạn đã hiểu, hoặc do một công cụ mới hoặc một số điều chủ quan khác làm cho lập trình viên trung bình ném mọi thứ vào và thay đổi hoàn toàn quy trình. Công việc của bạn - nếu bạn chọn ngoại trừ nó - là để xem liệu có cách nào để bạn hoặc nhóm tìm ra điều gì sẽ là yếu tố kích hoạt sự rõ ràng cho từng thành viên trong nhóm không.

Đối với cá nhân tôi, nó chỉ đơn giản là khám phá khung StoryQ cho BDD trong DotNet, điều này khiến cho việc bỏ qua quá dễ dàng và khiến tôi hoàn toàn vượt qua "rào cản" thử nghiệm đầu tiên và thử nghiệm đồng thời. Sau đó tôi đã xác nhận lại các lựa chọn của mình khi tôi tìm thấy NCrunch cho Visual Studio. Một nửa trận chiến đôi khi không bán ý tưởng, mà chỉ đơn giản là hạ thấp nỗ lực cần thiết để đưa ra sự thay đổi căn bản trong thói quen ... và thậm chí sau đó có thể mất một ít thời gian và công việc. Tuy nhiên, những kích hoạt cá nhân tương tự này không đủ để làm thay đổi cách tiếp cận của các đồng nghiệp của tôi vào thời điểm đó, những người vẫn đang viết nhiều mã thử nghiệm của họ đồng thời hoặc thậm chí sau mã thực thi của họ.

Đôi khi, có một sự miễn cưỡng thay đổi cách mọi thứ được thực hiện, do một nỗi sợ hãi vốn có, sự không tin tưởng hoặc quan điểm khó chịu về nỗ lực cần phải học để làm một cái gì đó khác nhau, ngay cả khi lý do cho sự thay đổi là âm thanh. Nếu toàn bộ nền tảng thử nghiệm của bạn được sử dụng để hoạt động theo một cách cụ thể, thật khó để biện minh cho việc thay đổi cách thức thực hiện và có khả năng thay đổi công cụ , đặc biệt là khi các thử nghiệm cũ và mới sẽ tiếp tục cùng tồn tại trong suốt vòng đời của dự án - và bạn chắc chắn sẽ không cần phải viết lại mọi bài kiểm tra bạn từng tạo. Điều kỳ lạ là đôi khi mọi người cảm thấy rằng đây là cách duy nhất để áp dụng một phương pháp thử nghiệm mới, và chính điều đó khiến những người đó khó chấp nhận thay đổi hợp lý hơn.

Thực sự, cách duy nhất để một thứ gì đó trở thành phản xạ là buộc bản thân phải làm đi làm lại nhiều lần cho đến khi bạn không còn nhận thấy bản thân cần phải tập trung quá nhiều vào cách làm. Đôi khi, cách duy nhất để làm điều này trong một nhóm là các chính sách thiết lập có thể nhìn thấy một chút hà khắc, và để thực hành cặp-lập trình và mã đánh giá, và bất cứ điều gì khác mà thành viên trong nhóm có thể giúp sao lưu từng lên khác và theo nghĩa đen buộc sự thay đổi trong hành vi xảy ra. Tuy nhiên, để chiến lược như vậy thực sự thành công, nó vẫn đòi hỏi một cam kết chắc chắn và trung thực từ mỗi thành viên trong nhóm để chấp nhận các biện pháp đó khi cần thiết và tham gia vào quá trình ... và rất nhiều sự kiên nhẫn từ tất cả những người liên quan .

Không ai trong chúng tôi thực sự cảm thấy tồi tệ khi không viết bài kiểm tra đơn vị cùng lúc với mã thực tế

Không chắc chắn ý của bạn là "cùng một lúc", nhưng viết về chúng trước mã thực tế thì sao?

Thật dễ hiểu từ góc độ tâm lý học tại sao bất kỳ con người nào cũng không muốn viết các bài kiểm tra đơn vị sau mã. Tại thời điểm đó, mã đã hoạt động, vậy tại sao chúng ta cần kiểm tra nó? Một số loại lười biếng tự động diễn ra bởi vì nó tẻ nhạt, dường như vô dụng và không viết bài kiểm tra dường như không nguy hiểm. Kết quả là, tôi không biết nhiều đội tiếp tục với cách tiếp cận thử nghiệm trong một khoảng thời gian dài.

Tuy nhiên, theo kinh nghiệm của tôi, thử nghiệm đầu tiên (kiểu TDD) là thứ bạn có thể nhanh chóng bị nghiện bởi vì có ít nhất 2 lợi ích ngay lập tức, hữu hình, giải phóng endorphin cho nó:

• Nó giúp bạn thiết kế mã mặt của bạn đối mặt với các yêu cầu thực thi cụ thể và làm cho thiết kế ngày càng tốt hơn khi bạn tái cấu trúc, điều này có mục đích và hài lòng hơn nhiều so với việc chỉ kiểm tra lại một cái gì đó đã hoạt động.

• Chu trình TDD được nhấn mạnh bằng những khoảnh khắc "thanh màu xanh" thường xuyên, nơi bạn có thể tận hưởng hương vị của thành công ngay lập tức. Nó liên tục giữ cho tâm trí của bạn hài lòng và sẵn sàng cho các tính năng tiếp theo để thực hiện.

Vì vậy, tôi sẽ không làm cho nhóm của bạn cảm thấy tồi tệ khi họ không viết bài kiểm tra. Thay vào đó, tôi sẽ cố gắng làm cho họ cảm thấy tốt như họ làm. TDD là một cách để làm điều này.

trước tiên bạn sẽ cần đảm bảo rằng viết một bài kiểm tra và chạy nó thật dễ dàng, hãy thiết lập khung trong các dự án hiện tại và làm cho quy trình thiết lập đó trở nên đơn giản để đưa vào các dự án trong tương lai

theo cách này khi một lập trình viên muốn hủy bỏ một tính năng mới mà anh ta đang cố gắng gỡ lỗi, anh ta không phải nhảy qua hàng tá vòng để các bài kiểm tra chạy đúng

càng làm điều gì đó càng tệ thì càng ít khả năng bạn sẽ tạo thói quen từ nó

Một điều tôi đã làm là phần nào thành công trong việc thúc đẩy thay đổi văn hóa là thiết lập một cuộc hội thảo hàng tuần, "hội thảo kiểm tra đơn vị". Mục đích chính thức của việc này là giúp cho bộ thử nghiệm đơn vị hoạt động nhanh và cập nhật, nhưng mục đích quan trọng hơn, trong suy nghĩ của tôi, là cung cấp cho mọi người một cách áp lực thấp để thả vào, đặt câu hỏi và kiểm tra thực hành . Thực tế là bạn sẵn sàng dành một giờ hoặc bất cứ điều gì mỗi tuần cho các bài kiểm tra cũng gửi thông điệp rằng điều này rất quan trọng.

Tôi nghĩ rằng bạn có một chút thay đổi văn hóa theo cách này và bạn bắt đầu xóa bỏ rào cản để thực hiện nó "theo phản xạ", như bạn đã nói. Mọi người sẽ có xu hướng trở lại thói quen cũ ở dấu hiệu đầu tiên của nghịch cảnh - có một cuộc họp như thế này sẽ không khắc phục được điều đó trong một cú trượt ngã, nhưng tôi nghĩ rằng nó sẽ bắt đầu thay đổi văn hóa và xóa bỏ rào cản không thực sự xảy ra biết những gì bạn đang làm.

Để có một nhóm lập trình viên trong đó tất cả đều muốn làm một cái gì đó một cách tự nhiên (đặc biệt là khi nói về một nhóm lớn).

Kiểm tra đơn vị và tích hợp là một điều của tiêu chuẩn . Bạn tạo một tiêu chuẩn cho một quy trình làm việc và mỗi thành viên trong nhóm nên tôn trọng nó. Các tiêu chuẩn nên được thực hiện với sự trợ giúp của các chuyên gia QA, bởi vì họ biết nó tốt hơn. Một lập trình viên nên tôn trọng các tiêu chuẩn. Những gì bạn có thể làm là làm cho các tiêu chuẩn sạch sẽ, dễ hiểu và làm theo.

Đó không phải là sự tin tưởng vào mã của riêng bạn và mong muốn sử dụng, mà là cần phải có các tiêu chuẩn kiểm tra và mã hóa mà mọi người sử dụng để tạo ra những điều tốt, và bất kỳ lập trình viên nào cũng nên hiểu điều này.

Khi bạn khiến mọi người ngay từ đầu tuân theo tiêu chuẩn, nó sẽ trở thành một phản xạ và nó sẽ được tuân theo. Làm cho nó trở thành một quy tắc rằng không có mã nào có thể được đưa vào cơ sở mã mà không có bài kiểm tra đơn vị sẽ thuyết phục mọi người rằng họ phải làm điều đó. Đối với các kho dự án thậm chí còn có các quy tắc hạn chế hơn. Ví dụ, các công ty thực hiện kiểm tra đơn vị trước khi thực sự mã hóa đơn vị (khi họ thực hiện đặc tả mô-đun) và đây là một phương pháp rất tốt. Nếu một lập trình viên đặt mã trong dự án / cơ sở mã, mã sẽ được chạy qua mô-đun kiểm tra và nếu kiểm thử đơn vị không vượt qua, họ sẽ quay lại làm việc.

Nếu hiện tại khó có thể thêm các tiêu chuẩn và quy tắc, ít nhất hãy nghĩ đến việc thêm chúng vào các dự án trong tương lai.