thetalkingwalnut hỏi:
Một số cách tốt để thuyết phục các nhà phát triển hoài nghi về nhóm giá trị của Kiểm thử đơn vị là gì?
Mọi người ở đây sẽ tập trung vào rất nhiều lý do vì lý do tại sao thử nghiệm đơn vị là tốt. Tuy nhiên, tôi thấy rằng thường thì cách tốt nhất để thuyết phục ai đó về điều gì đó là lắng nghe lập luận của họ và giải quyết từng điểm một. Nếu bạn lắng nghe và giúp họ kiểm chứng bằng lời nói của họ, bạn có thể giải quyết từng vấn đề và có thể chuyển đổi chúng theo quan điểm của bạn (hoặc ít nhất, để chúng không có chân để đứng lên). Ai biết? Có lẽ họ sẽ thuyết phục bạn tại sao các bài kiểm tra đơn vị không phù hợp với tình huống của bạn. Không có khả năng, nhưng có thể. Có lẽ nếu bạn đăng các đối số của họ chống lại các bài kiểm tra đơn vị, chúng tôi có thể giúp xác định các phản biện.
Điều quan trọng là lắng nghe và hiểu cả hai mặt của tranh luận. Nếu bạn cố gắng áp dụng các bài kiểm tra đơn vị quá nhiệt tình mà không quan tâm đến mối quan tâm của mọi người, bạn sẽ kết thúc bằng một cuộc chiến tôn giáo (và có lẽ là các bài kiểm tra đơn vị thực sự vô giá trị). Nếu bạn áp dụng nó từ từ và bắt đầu bằng cách áp dụng nó ở nơi bạn sẽ thấy lợi ích cao nhất với chi phí thấp nhất, bạn có thể chứng minh giá trị của các bài kiểm tra đơn vị và có cơ hội thuyết phục mọi người tốt hơn. Tôi nhận ra điều này không dễ như nghe - nó thường đòi hỏi một chút thời gian và số liệu cẩn thận để đưa ra một lập luận thuyết phục.
Các bài kiểm tra đơn vị là một công cụ, giống như bất kỳ công cụ nào khác, và nên được áp dụng theo cách sao cho lợi ích (bắt lỗi) vượt xa chi phí (nỗ lực viết chúng). Đừng sử dụng chúng nếu / nơi chúng không có ý nghĩa và hãy nhớ rằng chúng chỉ là một phần trong kho công cụ của bạn (ví dụ: kiểm tra, xác nhận, phân tích mã, phương pháp chính thức, v.v.). Những gì tôi nói với các nhà phát triển của tôi là:
Họ có thể bỏ qua việc viết một bài kiểm tra cho một phương thức nếu họ có một lý lẽ tốt tại sao nó không cần thiết (ví dụ: quá đơn giản để có giá trị hoặc quá khó để có giá trị) và cách thức phương thức sẽ được xác minh (ví dụ: kiểm tra, xác nhận , phương pháp chính thức, kiểm tra tương tác / tích hợp). Họ cần xem xét rằng một số xác minh như kiểm tra và bằng chứng chính thức được thực hiện tại một thời điểm và sau đó cần phải được lặp lại mỗi khi mã sản xuất thay đổi, trong khi kiểm tra đơn vị và xác nhận có thể được sử dụng làm kiểm tra hồi quy (được viết một lần và được thực hiện lặp đi lặp lại sau đó ). Đôi khi tôi đồng ý với họ, nhưng thường thì tôi sẽ tranh luận về việc một phương pháp thực sự quá đơn giản hay quá khó để kiểm tra đơn vị.
Nếu một nhà phát triển lập luận rằng một phương pháp dường như quá đơn giản để thất bại, thì có đáng để mất 60 giây cần thiết để viết bài kiểm tra đơn vị 5 dòng đơn giản cho nó không? 5 dòng mã này sẽ chạy mỗi đêm (bạn thực hiện các bản dựng hàng đêm, phải không?) Cho năm tới hoặc hơn và sẽ đáng nỗ lực nếu chỉ một lần xảy ra để bắt gặp sự cố có thể mất 15 phút hoặc lâu hơn để xác định và gỡ lỗi. Bên cạnh đó, việc viết các bài kiểm tra đơn vị dễ dàng làm tăng số lượng bài kiểm tra đơn vị, điều này làm cho nhà phát triển trông ổn.
Mặt khác, nếu một nhà phát triển lập luận rằng một phương pháp có vẻ quá khó để kiểm tra đơn vị (không xứng đáng với nỗ lực đáng kể), có lẽ đó là một dấu hiệu tốt cho thấy phương pháp cần được chia ra hoặc tái cấu trúc để kiểm tra các phần dễ dàng. Thông thường, đây là các phương thức dựa vào các tài nguyên bất thường như singletons, thời gian hiện tại hoặc các tài nguyên bên ngoài như tập kết quả cơ sở dữ liệu. Các phương thức này thường cần được cấu trúc lại thành một phương thức lấy tài nguyên (ví dụ: gọi getTime ()) và một phương thức lấy tài nguyên làm đối số (ví dụ: lấy dấu thời gian làm tham số). Tôi để họ bỏ qua việc kiểm tra phương thức lấy tài nguyên và thay vào đó họ viết một bài kiểm tra đơn vị cho phương thức hiện lấy tài nguyên làm đối số. Thông thường, điều này làm cho việc viết bài kiểm tra đơn vị đơn giản hơn nhiều và do đó đáng để viết.
Nhà phát triển cần vẽ một "đường thẳng trên cát" trong việc kiểm tra đơn vị của họ toàn diện như thế nào. Sau này trong quá trình phát triển, bất cứ khi nào chúng tôi tìm thấy một lỗi, họ nên xác định xem các bài kiểm tra đơn vị toàn diện hơn có bắt được vấn đề không. Nếu vậy và nếu các lỗi như vậy lặp đi lặp lại, chúng cần chuyển "dòng" sang viết các bài kiểm tra đơn vị toàn diện hơn trong tương lai (bắt đầu bằng việc thêm hoặc mở rộng kiểm tra đơn vị cho lỗi hiện tại). Họ cần tìm sự cân bằng phù hợp.
Quan trọng của nó để nhận ra các bài kiểm tra đơn vị không phải là một viên đạn bạc và có là một điều chẳng hạn như kiểm tra đơn vị quá nhiều. Tại nơi làm việc của tôi, bất cứ khi nào chúng tôi làm một bài học kinh nghiệm, tôi chắc chắn nghe thấy "chúng tôi cần phải viết nhiều bài kiểm tra đơn vị hơn". Ban quản lý gật đầu đồng ý vì nó đã đập vào đầu họ rằng "kiểm tra đơn vị" == "tốt".
Tuy nhiên, chúng ta cần hiểu tác động của "nhiều bài kiểm tra đơn vị hơn". Một nhà phát triển chỉ có thể viết ~ N dòng mã một tuần và bạn cần tìm ra bao nhiêu phần trăm của mã đó nên là mã kiểm tra đơn vị so với mã sản xuất. Một nơi làm việc lỏng lẻo có thể có 10% mã khi kiểm tra đơn vị và 90% mã là mã sản xuất, dẫn đến sản phẩm có rất nhiều tính năng (mặc dù rất có lỗi) (nghĩ là MS Word). Mặt khác, một cửa hàng nghiêm ngặt với 90% đơn vị kiểm tra và 10% mã sản xuất sẽ có một sản phẩm rắn với rất ít tính năng (nghĩ "vi"). Bạn có thể không bao giờ nghe báo cáo về sự cố sản phẩm sau, nhưng điều đó có thể có liên quan đến sản phẩm không bán chạy nhiều như chất lượng của mã.
Tệ hơn nữa, có lẽ điều chắc chắn duy nhất trong phát triển phần mềm là "thay đổi là không thể tránh khỏi". Giả sử cửa hàng nghiêm ngặt (90% đơn vị kiểm tra / 10% mã sản xuất) tạo ra một sản phẩm có đúng 2 tính năng (giả sử 5% mã sản xuất == 1 tính năng). Nếu khách hàng xuất hiện và thay đổi 1 trong số các tính năng, thì thay đổi đó sẽ bỏ qua 50% mã (45% kiểm tra đơn vị và 5% mã sản xuất). Cửa hàng lax (10% đơn vị kiểm tra / 90% mã sản xuất) có một sản phẩm với 18 tính năng, không có tính năng nào hoạt động tốt. Khách hàng của họ hoàn toàn sửa đổi các yêu cầu cho 4 tính năng của họ. Mặc dù thay đổi lớn gấp 4 lần, chỉ một nửa số cơ sở mã bị vứt bỏ (~ 25% = ~ 4,4% đơn vị kiểm tra + 20% mã sản xuất).
Quan điểm của tôi là bạn phải thông báo rằng bạn hiểu sự cân bằng giữa quá ít và quá nhiều thử nghiệm đơn vị - về cơ bản là bạn đã nghĩ qua cả hai mặt của vấn đề. Nếu bạn có thể thuyết phục đồng nghiệp và / hoặc quản lý của bạn về điều đó, bạn có được sự tín nhiệm và có lẽ có cơ hội tốt hơn để chiến thắng họ.