it-swarm-vi.tech

Là một trong những phần mềm của họ

Tôi đang làm việc để tích hợp thử nghiệm đơn vị vào quá trình phát triển trong nhóm tôi làm việc và có một số người hoài nghi. 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ì? Trong trường hợp cụ thể của tôi, chúng tôi sẽ thêm Đơn vị kiểm tra khi chúng tôi thêm chức năng hoặc sửa lỗi. Thật không may, cơ sở mã của chúng tôi không cho vay để kiểm tra dễ dàng.

573
Ross Fuhrman

Mỗi ngày trong văn phòng của chúng tôi có một cuộc trao đổi diễn ra như thế này:

"Man, tôi chỉ thích thử nghiệm đơn vị, tôi vừa có thể thực hiện một loạt các thay đổi về cách thức hoạt động của một cái gì đó, và sau đó có thể xác nhận rằng tôi đã không phá vỡ bất cứ điều gì bằng cách chạy thử nghiệm lại ...

Các chi tiết thay đổi hàng ngày, nhưng tình cảm thì không. Các thử nghiệm đơn vị và phát triển dựa trên thử nghiệm (TDD) có rất nhiều lợi ích tiềm ẩn và cá nhân cũng như những lợi ích rõ ràng mà bạn không thể thực sự giải thích cho ai đó cho đến khi chính họ làm điều đó.

Nhưng, bỏ qua điều đó, đây là nỗ lực của tôi!

  1. Kiểm tra đơn vị cho phép bạn thực hiện các thay đổi lớn để mã nhanh chóng. Bạn biết nó hoạt động ngay bây giờ vì bạn đã chạy thử nghiệm, khi bạn thực hiện các thay đổi bạn cần thực hiện, bạn cần làm cho các thử nghiệm hoạt động trở lại. Điều này tiết kiệm hàng giờ.

  2. TDD giúp bạn nhận ra khi nào nên ngừng mã hóa. Các bài kiểm tra của bạn cho bạn sự tự tin rằng bạn đã thực hiện đủ cho đến bây giờ và có thể ngừng điều chỉnh và chuyển sang điều tiếp theo.

  3. Các thử nghiệm và mã làm việc cùng nhau để đạt được mã tốt hơn. Mã của bạn có thể là xấu/lỗi. KIỂM TRA của bạn có thể là xấu/lỗi. Trong TDD, bạn đang giao dịch với khả năng cả hai bị xấu/lỗi thấp. Thường thì đó là bài kiểm tra cần sửa nhưng đó vẫn là một kết quả tốt.

  4. TDD giúp chống táo bón mã hóa. Khi phải đối mặt với một công việc lớn và nan giải trước khi viết các bài kiểm tra sẽ giúp bạn di chuyển nhanh chóng.

  5. Kiểm thử đơn vị giúp bạn thực sự hiểu thiết kế mã bạn đang làm việc. Thay vì viết mã để làm một cái gì đó, bạn đang bắt đầu bằng cách phác thảo tất cả các điều kiện bạn đang tuân theo mã và những kết quả đầu ra mà bạn mong đợi từ đó.

  6. Bài kiểm tra đơn vị cung cấp cho bạn thông tin phản hồi trực quan ngay lập tức, tất cả chúng ta đều thích cảm giác của tất cả những đèn xanh khi chúng ta thực hiện. Nó rất thỏa mãn. Cũng dễ dàng hơn nhiều để chọn nơi bạn rời đi sau khi bị gián đoạn vì bạn có thể thấy nơi bạn đã đến - đèn đỏ tiếp theo cần sửa.

  7. Trái ngược với thử nghiệm đơn vị niềm tin phổ biến không có nghĩa là viết mã nhiều gấp đôi, hoặc mã hóa chậm hơn. Nó nhanh hơn và mạnh hơn mã hóa mà không cần kiểm tra một khi bạn đã hiểu rõ về nó. Bản thân mã kiểm tra thường tương đối tầm thường và không thêm chi phí lớn cho những gì bạn đang làm. Đây là một điều bạn sẽ chỉ tin khi bạn làm nó :)

  8. Tôi nghĩ rằng chính Fowler đã nói: "Các bài kiểm tra không hoàn hảo, chạy thường xuyên, tốt hơn nhiều so với các bài kiểm tra hoàn hảo không bao giờ được viết cả". Tôi diễn giải điều này như cho phép tôi viết các bài kiểm tra trong đó tôi nghĩ chúng sẽ hữu ích nhất ngay cả khi phần còn lại trong phạm vi bảo hiểm mã của tôi không đầy đủ.

  9. Kiểm tra đơn vị tốt có thể giúp tài liệu và xác định những gì cần phải làm

  10. Kiểm tra đơn vị giúp sử dụng lại mã. Di chuyển cả mã của bạn các thử nghiệm của bạn sang dự án mới của bạn. Tinh chỉnh mã cho đến khi các bài kiểm tra chạy lại.

Rất nhiều công việc tôi tham gia không phải là Kiểm tra đơn vị tốt (tương tác người dùng ứng dụng web, v.v.), nhưng ngay cả như vậy, tất cả chúng tôi đều kiểm tra bị nhiễm trong cửa hàng này và hạnh phúc nhất khi chúng tôi kiểm tra thử nghiệm. Tôi không thể đề nghị cách tiếp cận đủ cao.

722
reefnet_alex

Kiểm tra đơn vị rất giống với việc đi đến phòng tập thể dục. Bạn biết điều đó tốt cho bạn, tất cả các cuộc tranh luận đều có ý nghĩa, vì vậy bạn bắt đầu tập luyện. Có một Rush ban đầu, rất tuyệt, nhưng sau vài ngày bạn bắt đầu tự hỏi liệu nó có đáng để gặp rắc rối không. Bạn đang dành một giờ trong ngày để thay quần áo và chạy trên một chiếc bánh hamster và bạn không chắc mình có thực sự đạt được bất cứ thứ gì ngoài đau chân và tay.

Sau đó, có thể sau một hoặc hai tuần, ngay khi cơn đau nhức biến mất, một Hạn chót lớn bắt đầu đến gần. Bạn cần dành mỗi giờ thức dậy để cố gắng hoàn thành công việc "hữu ích", vì vậy bạn cắt bỏ những thứ không liên quan, như đi đến phòng tập thể dục. Bạn đã bỏ thói quen và đến khi Big Deadline kết thúc, bạn sẽ quay lại quảng trường. Nếu bạn cố gắng để trở lại phòng tập thể dục, bạn sẽ cảm thấy đau như lần đầu tiên bạn đi.

Bạn đọc một số thứ, để xem bạn có làm gì sai không. Bạn bắt đầu cảm thấy một chút bất hợp lý bất chấp tất cả sự phù hợp, những người hạnh phúc thể hiện những đức tính của tập thể dục. Bạn nhận ra rằng bạn không có nhiều điểm chung. Họ không phải lái xe 15 phút trên đường đến phòng tập thể dục; Có một cái trong tòa nhà của họ. Họ không phải tranh luận với bất kỳ ai về lợi ích của việc tập thể dục; nó chỉ là thứ mà mọi người làm và chấp nhận là quan trọng. Khi Hạn chót lớn đến gần, họ không nói rằng tập thể dục là không cần thiết nhiều hơn sếp của bạn sẽ yêu cầu bạn ngừng ăn.

Vì vậy, để trả lời câu hỏi của bạn, Kiểm thử đơn vị thường đáng nỗ lực, nhưng số lượng nỗ lực cần thiết sẽ không giống nhau đối với mọi người. Kiểm tra đơn vị có thể cần một nỗ lực rất lớn nếu bạn đang làm việc với cơ sở mã spaghetti trong một công ty không thực sự chất lượng mã giá trị . (Rất nhiều nhà quản lý sẽ hát những lời khen ngợi của Kiểm thử đơn vị, nhưng điều đó không có nghĩa là họ sẽ kiên trì thực hiện khi có vấn đề.)

Nếu bạn đang cố gắng giới thiệu Kiểm thử đơn vị vào công việc của mình và không thấy tất cả ánh nắng mặt trời và cầu vồng mà bạn đã được mong đợi, đừng tự trách mình. Bạn có thể cần tìm một công việc mới để thực sự làm cho Kiểm thử đơn vị làm việc cho bạn.

421
benzado

Cách tốt nhất để thuyết phục ... tìm một lỗi, viết một bài kiểm tra đơn vị cho nó, sửa lỗi.

Lỗi cụ thể đó khó có thể xuất hiện trở lại và bạn có thể chứng minh bằng thử nghiệm của mình.

Nếu bạn làm điều này đủ, những người khác sẽ nắm bắt nhanh chóng.

136
Ed Guiness

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ẽ chồng chất lên 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 với 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? 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ẽ 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à thế này:

  1. Họ có thể bỏ qua việc viết một bài kiểm tra cho một phương pháp 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à 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.

  2. 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.

Điều quan trọng để nhận ra các bài kiểm tra đơn vị không phải là viên đạn bạc và ở đó một điều như quá nhiều bài kiểm tra đơn vị. 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ĩ 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ọ.

69
Bert F

Tôi đã chơi với đơn vị thử nghiệm nhiều lần, và tôi vẫn tin chắc rằng đó là giá trị của nỗ lực cho tình huống của tôi.

Tôi phát triển các trang web, nơi phần lớn logic liên quan đến việc tạo, truy xuất hoặc cập nhật dữ liệu trong cơ sở dữ liệu. Khi tôi đã cố gắng "chế nhạo" cơ sở dữ liệu cho mục đích thử nghiệm đơn vị, nó đã trở nên rất lộn xộn và có vẻ hơi vô nghĩa.

Khi tôi đã viết các bài kiểm tra đơn vị xung quanh logic kinh doanh, nó chưa bao giờ thực sự giúp tôi về lâu dài. Bởi vì tôi chủ yếu làm việc trên các dự án một mình, tôi có xu hướng biết bằng trực giác những lĩnh vực mã nào có thể bị ảnh hưởng bởi thứ gì đó tôi đang làm và tôi kiểm tra các khu vực này bằng tay. Tôi muốn cung cấp một giải pháp cho khách hàng của mình càng nhanh càng tốt và việc kiểm tra đơn vị thường có vẻ lãng phí thời gian. Tôi liệt kê các bài kiểm tra thủ công và tự mình đi qua chúng, đánh dấu chúng khi tôi đi.

Tôi có thể thấy rằng nó có thể có ích khi một nhóm các nhà phát triển đang làm việc trên một dự án và cập nhật mã của nhau, nhưng ngay cả khi đó tôi nghĩ rằng nếu các nhà phát triển có chất lượng cao, giao tiếp tốt và mã được viết tốt thường là đủ .

38
Ronnie

Một điều tuyệt vời về các bài kiểm tra đơn vị là chúng đóng vai trò là tài liệu cho cách mã của bạn có nghĩa là hành xử. Các bài kiểm tra tốt giống như một triển khai tham chiếu và các đồng đội có thể nhìn vào chúng để xem cách tích hợp mã của họ với mã của bạn.

31
pkaeding

Thử nghiệm đơn vị là giá trị đầu tư ban đầu. Kể từ khi bắt đầu sử dụng thử nghiệm đơn vị một vài năm trước đây, tôi đã tìm thấy một số lợi ích thực sự:

  • kiểm tra hồi quy loại bỏ nỗi sợ thực hiện thay đổi mã (không có gì giống như ánh sáng ấm áp khi thấy mã hoạt động hoặc phát nổ mỗi khi thay đổi được thực hiện)
  • ví dụ mã thực thi cho các thành viên khác trong nhóm (và chính bạn sau sáu tháng nữa ..)
  • không thương tiếc tái cấu trúc - đây là phần thưởng đáng kinh ngạc, hãy thử nó!

Đoạn mã có thể là một trợ giúp tuyệt vời trong việc giảm chi phí tạo ra các bài kiểm tra. Không khó để tạo các đoạn mã cho phép tạo ra một phác thảo lớp và một vật cố kiểm tra đơn vị liên quan trong vài giây.

26
Jonathan Webb

Bạn nên kiểm tra càng ít càng tốt!

có nghĩa là, bạn nên viết bài kiểm tra đơn vị vừa đủ để tiết lộ ý định. Điều này thường được che đậy hơn. Đơn vị kiểm tra chi phí bạn. Nếu bạn thực hiện thay đổi và bạn phải thay đổi các bài kiểm tra, bạn sẽ kém nhanh nhẹn hơn. Giữ bài kiểm tra đơn vị ngắn và ngọt ngào. Sau đó, họ có rất nhiều giá trị.

Tôi thường thấy rất nhiều bài kiểm tra sẽ không bao giờ bị phá vỡ, lớn và vụng về và không mang lại nhiều giá trị, chúng chỉ khiến bạn chậm lại.

25
Keith Nicholas

Tôi không thấy điều này trong bất kỳ câu trả lời nào khác, nhưng một điều tôi nhận thấy là tôi có thể gỡ lỗi nhanh hơn rất nhiề. Bạn không cần đi sâu vào ứng dụng của mình chỉ với một chuỗi các bước phù hợp để tìm mã sửa lỗi, chỉ để thấy bạn đã mắc lỗi boolean và cần phải thực hiện lại. Với bài kiểm tra đơn vị, bạn có thể chỉ cần bước trực tiếp vào mã bạn đang gỡ lỗi.

23
John MacIntyre

[Tôi có một điểm để làm cho tôi không thể thấy ở trên]

"Mọi người kiểm tra đơn vị, họ không nhất thiết phải nhận ra điều đó - SỰ THẬT"

Hãy suy nghĩ về nó, bạn viết một hàm để có thể phân tích một chuỗi và xóa các ký tự dòng mới. Là một nhà phát triển người mới, bạn có thể chạy một vài trường hợp thông qua nó từ dòng lệnh bằng cách triển khai nó trong Main () hoặc bạn kết hợp một mặt trước trực quan bằng một nút, gắn chức năng của bạn vào một vài hộp văn bản và một nút và xem chuyện gì xảy ra.

Đó là kiểm thử đơn vị - cơ bản và kết hợp kém nhưng bạn kiểm tra đoạn mã cho một vài trường hợp.

Bạn viết một cái gì đó phức tạp hơn. Nó ném lỗi khi bạn ném một vài trường hợp (kiểm tra đơn vị) và bạn gỡ lỗi vào mã và theo dõi mặc dù. Bạn nhìn vào các giá trị khi bạn trải qua và quyết định xem chúng đúng hay sai. Đây là thử nghiệm đơn vị ở một mức độ nào đó.

Kiểm thử đơn vị ở đây thực sự thực hiện hành vi đó, chính thức hóa nó thành một mô hình có cấu trúc và lưu nó để bạn có thể dễ dàng chạy lại các thử nghiệm đó. Nếu bạn viết trường hợp kiểm tra đơn vị "phù hợp" thay vì kiểm tra thủ công, sẽ mất cùng một khoảng thời gian hoặc có thể ít hơn khi bạn có kinh nghiệm và bạn có sẵn để lặp lại nhiều lần

21
Chris Gill

Trong nhiều năm, tôi đã cố gắng thuyết phục mọi người rằng họ cần viết bài kiểm tra đơn vị cho mã của họ. Cho dù họ đã viết các bài kiểm tra trước (như trong TDD) hoặc sau khi họ mã hóa chức năng, tôi luôn cố gắng giải thích cho họ tất cả các lợi ích của việc kiểm tra đơn vị cho mã. Hầu như không ai đồng ý với tôi. Bạn không thể không đồng ý với điều gì đó hiển nhiên và bất kỳ người thông minh nào cũng sẽ thấy lợi ích của bài kiểm tra đơn vị và TDD.

Vấn đề với kiểm tra đơn vị là nó đòi hỏi phải thay đổi hành vi và rất khó thay đổi hành vi của mọi người. Với lời nói, bạn sẽ có rất nhiều người đồng ý với bạn, nhưng bạn sẽ không thấy nhiều thay đổi trong cách họ làm việc.

Bạn phải thuyết phục mọi người bằng cách làm. Thành công cá nhân của bạn sẽ thu hút nhiều người hơn tất cả những lý lẽ bạn có thể có. Nếu họ thấy bạn không chỉ nói về bài kiểm tra đơn vị hoặc TDD, mà bạn đang làm những gì bạn giảng, và bạn thành công, mọi người sẽ cố gắng bắt chước bạn.

Bạn cũng nên đảm nhận vai trò lãnh đạo vì không ai viết bài kiểm tra đơn vị ngay lần đầu tiên, vì vậy bạn có thể cần hướng dẫn họ cách làm, chỉ cho họ cách và các công cụ có sẵn cho họ. Giúp họ trong khi họ viết bài kiểm tra đầu tiên, xem lại bài kiểm tra mà họ tự viết và chỉ cho họ các mẹo, thành ngữ và mẫu bạn đã học được qua kinh nghiệm của chính mình. Sau một thời gian, họ sẽ bắt đầu tự mình nhìn thấy những lợi ích và họ sẽ thay đổi hành vi của mình để kết hợp các bài kiểm tra đơn vị hoặc TDD vào hộp công cụ của họ.

Những thay đổi sẽ không xảy ra trong đêm, nhưng với một chút kiên nhẫn, bạn có thể đạt được mục tiêu của mình.

16
Curro

Một phần chính của sự phát triển dựa trên thử nghiệm thường bị che đậy là việc viết mã thử nghiệm. Ban đầu có vẻ như là một sự thỏa hiệp nào đó, nhưng bạn sẽ khám phá ra rằng mã có thể kiểm tra được cuối cùng cũng là mô-đun, có thể duy trì và có thể đọc được. Nếu bạn vẫn cần trợ giúp để thuyết phục mọi người này là một bài thuyết trình đơn giản về những lợi thế của kiểm tra đơn vị.

12
Tom Martin

Nếu cơ sở mã hiện tại của bạn không cho vay để thử nghiệm đơn vị và nó đã được sản xuất, bạn có thể tạo ra nhiều vấn đề hơn bạn giải quyết bằng cách cố gắng cấu trúc lại tất cả mã của mình để có thể kiểm tra được đơn vị.

Thay vào đó, bạn có thể nên nỗ lực cải thiện thử nghiệm tích hợp của mình. Có rất nhiều mã ngoài đó đơn giản hơn để viết mà không cần kiểm tra đơn vị, và nếu QA có thể xác nhận chức năng đối với tài liệu yêu cầu, thì bạn đã hoàn thành. Vận chuyển nó.

Ví dụ kinh điển về điều này trong tâm trí tôi là một SqlDataReader được nhúng trong một trang ASPX được liên kết với GridView. Mã này là tất cả trong tệp ASPX. SQL là trong một thủ tục được lưu trữ. Bạn làm bài kiểm tra gì? Nếu trang thực hiện những gì nó phải làm, bạn có thực sự nên thiết kế lại thành nhiều lớp để bạn có thể tự động hóa không?

11
Eric Z Beard

Một trong những điều tốt nhất về kiểm thử đơn vị là mã của bạn sẽ trở nên dễ kiểm tra hơn khi bạn thực hiện. Mã có sẵn được tạo mà không có kiểm tra luôn là một thách thức bởi vì chúng không có nghĩa là được kiểm tra đơn vị, nên không có mức độ khớp nối cao giữa các lớp, các đối tượng khó định cấu hình trong lớp của bạn - như email gửi tài liệu tham khảo - và như vậy. Nhưng đừng để điều này làm bạn thất vọng! Bạn sẽ thấy rằng thiết kế mã tổng thể của bạn sẽ trở nên tốt hơn khi bạn bắt đầu viết bài kiểm tra đơn vị, và bạn càng kiểm tra, bạn sẽ càng tự tin hơn khi thực hiện nhiều thay đổi hơn cho nó mà không sợ làm hỏng ứng dụng hoặc giới thiệu lỗi .

Có một số lý do để kiểm tra đơn vị mã của bạn, nhưng khi thời gian trôi qua, bạn sẽ thấy rằng thời gian bạn tiết kiệm để kiểm tra là một trong những lý do tốt nhất để thực hiện. Trong một hệ thống tôi vừa giao, tôi khăng khăng thực hiện kiểm tra đơn vị tự động bất chấp các tuyên bố rằng tôi dành nhiều thời gian hơn để thực hiện các kiểm tra so với kiểm tra hệ thống theo cách thủ công. Với tất cả các thử nghiệm đơn vị của tôi đã được thực hiện, tôi đã chạy hơn 400 trường hợp thử nghiệm trong vòng chưa đầy 10 phút và mỗi lần tôi phải thực hiện một thay đổi nhỏ trong mã, tất cả tôi phải chắc chắn rằng mã vẫn hoạt động mà không có lỗi là mười phút Bạn có thể tưởng tượng thời gian người ta sẽ dành để chạy hơn 400 trường hợp thử nghiệm đó không?

Khi nói đến thử nghiệm tự động - có thể là thử nghiệm đơn vị hoặc thử nghiệm chấp nhận - mọi người đều nghĩ rằng thật lãng phí khi viết mã những gì bạn có thể làm thủ công và đôi khi điều đó đúng - nếu bạn dự định chỉ chạy thử nghiệm một lần. Phần tốt nhất của kiểm tra tự động là bạn có thể chạy chúng nhiều lần mà không cần nỗ lực và sau lần chạy thứ hai hoặc thứ ba, thời gian và công sức bạn đã lãng phí đã được trả tiền cho.

Một lời khuyên cuối cùng là không chỉ đơn vị kiểm tra mã của bạn, mà hãy bắt đầu thực hiện kiểm tra trước (xem TDDBDD để biết thêm)

10
Alexandre Brasil

Các bài kiểm tra đơn vị cũng đặc biệt hữu ích khi tái cấu trúc hoặc viết lại một đoạn mã. Nếu bạn có phạm vi kiểm tra đơn vị tốt, bạn có thể tự tin tái cấu trúc. Nếu không có bài kiểm tra đơn vị, thường rất khó để đảm bảo rằng bạn đã không phá vỡ bất cứ điều gì.

8
killdash10

Tôi đang làm việc như một kỹ sư bảo trì của một cơ sở mã kém, tệ hại và tài liệu lớn. Tôi muốn những người đã viết mã đã viết các bài kiểm tra đơn vị cho nó.
[.__.] Mỗi lần tôi thực hiện thay đổi và cập nhật mã sản xuất, tôi sợ rằng tôi có thể đưa ra một lỗi vì đã không xem xét một số điều kiện.
[.__.] Nếu họ viết bài kiểm tra, việc thay đổi cơ sở mã sẽ dễ dàng và nhanh hơn. (Đồng thời cơ sở mã sẽ ở trạng thái tốt hơn) ..

Tôi nghĩ các bài kiểm tra đơn vị chứng minh rất hữu ích khi viết api hoặc các khung phải tồn tại trong nhiều năm và được sử dụng/sửa đổi/phát triển bởi những người khác ngoài các lập trình viên gốc.

7
mic.sca

Tóm lại - có. Họ đáng giá từng ounce nỗ lực ... đến một điểm. Các thử nghiệm, vào cuối ngày, vẫn là mã, và giống như sự tăng trưởng mã thông thường, các thử nghiệm của bạn cuối cùng sẽ cần phải được cấu trúc lại để có thể duy trì và bền vững. Có một tấn GOTCHAS! khi nói đến thử nghiệm đơn vị, nhưng người đàn ông ơi, không có gì, và ý tôi là KHÔNG NÊN trao quyền cho nhà phát triển thực hiện các thay đổi một cách tự tin hơn một bộ thử nghiệm đơn vị phong phú.

Tôi đang làm việc trên một dự án ngay bây giờ .... nó có phần TDD và chúng tôi có phần lớn các quy tắc kinh doanh được mã hóa dưới dạng thử nghiệm ... hiện tại chúng tôi có khoảng 500 thử nghiệm đơn vị. Lần lặp lại trước đây tôi đã phải tân trang lại nguồn dữ liệu của chúng tôi và cách giao diện ứng dụng máy tính để bàn của chúng tôi với nguồn dữ liệu đó. Mất vài ngày, tôi chỉ chạy thử nghiệm đơn vị để xem những gì tôi đã phá vỡ và sửa nó. Tạo sự thay đổi; Xây dựng và chạy thử nghiệm của bạn; sửa chữa những gì bạn đã phá vỡ. Rửa, rửa, lặp lại khi cần thiết. Theo truyền thống, những gì sẽ mất nhiều ngày của QA và vô số căng thẳng thay vào đó là một trải nghiệm ngắn và thú vị.

Chuẩn bị trước, một chút nỗ lực thêm và sẽ trả tiền gấp 10 lần sau khi bạn phải bắt đầu lừa đảo với các tính năng/chức năng cốt lõi.

Tôi đã mua cuốn sách này - đó là một cuốn Kinh thánh về xUnit Kiểm tra kiến ​​thức - đây có lẽ là một trong những cuốn sách được tham khảo nhiều nhất trên kệ của tôi và tôi tham khảo nó hàng ngày: liên kết văn bản

7
cranley

Thỉnh thoảng, bản thân tôi hoặc một trong những đồng nghiệp của tôi sẽ mất vài giờ để tìm ra lỗi của một chút tối nghĩa và một khi nguyên nhân của lỗi được tìm thấy 90% thời gian mà mã không được kiểm tra. Kiểm tra đơn vị không tồn tại vì nhà phát triển đang cắt góc để tiết kiệm thời gian, nhưng sau đó mất điều này và gỡ lỗi nhiều hơn.

Dành một lượng nhỏ thời gian để viết một bài kiểm tra đơn vị có thể tiết kiệm hàng giờ để gỡ lỗi trong tương lai.

7
Jon Cahill

Khi bạn nói, "cơ sở mã của chúng tôi không cho vay để kiểm tra dễ dàng" là dấu hiệu đầu tiên của mùi mã. Kiểm tra đơn vị viết có nghĩa là bạn thường viết mã khác nhau để làm cho mã dễ kiểm tra hơn. Đây là một điều tốt theo quan điểm của tôi vì những gì tôi đã thấy trong nhiều năm qua khi viết mã mà tôi phải viết bài kiểm tra, nó buộc tôi phải đưa ra một thiết kế tốt hơn.

6
Keith Elder

Tôi không biết. Rất nhiều nơi không làm bài kiểm tra đơn vị, nhưng chất lượng của mã là tốt. Microsoft thực hiện bài kiểm tra đơn vị, nhưng Bill Gates đã đưa ra một màn hình màu xanh trong bài thuyết trình của mình.

6
BigTiger

Kiểm thử đơn vị chắc chắn là giá trị nỗ lực. Thật không may, bạn đã chọn một kịch bản khó (nhưng không may phổ biến) để thực hiện nó.

Lợi ích tốt nhất từ ​​kiểm thử đơn vị mà bạn sẽ nhận được là khi sử dụng nó từ đầu - trên một số dự án nhỏ, tôi đã may mắn viết bài kiểm tra đơn vị của mình trước khi triển khai các lớp của mình (giao diện đã hoàn tất điểm). Với các bài kiểm tra đơn vị phù hợp, bạn sẽ tìm và sửa các lỗi trong các lớp của mình trong khi chúng vẫn còn ở giai đoạn sơ khai và không ở bất kỳ nơi nào gần hệ thống phức tạp mà chắc chắn chúng sẽ được tích hợp trong tương lai.

Nếu phần mềm của bạn được định hướng đối tượng vững chắc, bạn sẽ có thể thêm kiểm tra đơn vị ở cấp lớp mà không cần quá nhiều nỗ lực. Nếu bạn không may mắn, bạn vẫn nên cố gắng kết hợp kiểm tra đơn vị bất cứ nơi nào bạn có thể. Hãy chắc chắn rằng khi bạn thêm chức năng mới, các phần mới được xác định rõ ràng với các giao diện rõ ràng và bạn sẽ thấy việc kiểm tra đơn vị giúp cuộc sống của bạn dễ dàng hơn nhiều.

6
Matt

Tôi đã viết một bài blog rất lớn về chủ đề này. Tôi thấy rằng việc kiểm tra đơn vị một mình không đáng để thực hiện và thường bị cắt giảm khi thời hạn đến gần hơn.

Thay vì nói về kiểm thử đơn vị theo quan điểm xác minh "kiểm tra sau", chúng ta nên xem giá trị thực được tìm thấy khi bạn bắt đầu viết một thông số/kiểm tra/ý tưởng trước khi thực hiện.

Ý tưởng đơn giản này đã thay đổi cách tôi viết phần mềm và tôi sẽ không quay lại cách "cũ".

Cách thử nghiệm phát triển đầu tiên đã thay đổi cuộc đời tôi

5
Toran Billups

Một điều chưa ai nhắc đến là nhận được cam kết của tất cả các nhà phát triển để thực sự chạy và cập nhật bất kỳ thử nghiệm tự động hiện có nào. Các thử nghiệm tự động mà bạn quay lại và thấy bị hỏng vì sự phát triển mới làm mất rất nhiều giá trị và làm cho thử nghiệm tự động thực sự đau đớn. Hầu hết các thử nghiệm đó sẽ không chỉ ra lỗi do nhà phát triển đã kiểm tra mã theo cách thủ công, vì vậy thời gian cập nhật chúng chỉ là lãng phí.

Thuyết phục những người hoài nghi không phá hủy công việc mà những người khác đang làm trong bài kiểm tra đơn vị là rất quan trọng để nhận được giá trị từ thử nghiệm và có thể dễ dàng hơn.

Dành hàng giờ để cập nhật các bài kiểm tra đã bị hỏng do các tính năng mới mỗi khi bạn cập nhật từ kho lưu trữ là không hiệu quả cũng không thú vị.

3
Samuel Åslund

Tôi đã phát hiện ra TDD một vài năm trước đây và kể từ đó đã viết tất cả các dự án thú cưng của tôi bằng cách sử dụng nó. Tôi đã ước tính rằng TDD phải mất khoảng thời gian tương đương với dự án TDD khi cùng với cao bồi, nhưng tôi đã tăng sự tự tin vào sản phẩm cuối cùng đến mức tôi không thể giúp cảm giác hoàn thành.

Tôi cũng cảm thấy rằng nó cải thiện phong cách thiết kế của tôi (theo định hướng giao diện nhiều hơn trong trường hợp tôi cần phải chế giễu mọi thứ cùng nhau) và, như bài đăng màu xanh lá cây ở trên cùng, nó giúp "táo bón mã hóa": khi bạn không biết gì để viết tiếp, hoặc bạn có một nhiệm vụ khó khăn trước mặt, bạn có thể viết nhỏ.

Cuối cùng, tôi thấy rằng cho đến nay, ứng dụng hữu ích nhất của TDD là trong việc gỡ lỗi, nếu chỉ vì bạn đã phát triển một khung công tác thẩm vấn mà bạn có thể thúc đẩy dự án tạo ra lỗi theo cách lặp lại.

3
Kaz Dragon

Có - Kiểm tra đơn vị chắc chắn là đáng nỗ lực nhưng bạn nên biết đó không phải là viên đạn bạc. Kiểm thử đơn vị là công việc và bạn sẽ phải làm việc để giữ cho bài kiểm tra được cập nhật và có liên quan khi thay đổi mã nhưng giá trị được cung cấp xứng đáng với công sức bạn phải bỏ ra. Khả năng tái cấu trúc không bị trừng phạt là một lợi ích rất lớn vì bạn luôn có thể xác thực chức năng bằng cách chạy thử nghiệm của bạn sau khi bất kỳ mã thay đổi. Mẹo nhỏ là đừng quá bận tâm vào chính xác đơn vị công việc bạn đang kiểm tra hoặc cách bạn yêu cầu kiểm tra giàn giáo và khi kiểm tra đơn vị thực sự là một thử nghiệm chức năng, v.v. Mọi người sẽ tranh luận về công cụ này trong nhiều giờ cuối cùng và thực tế là bất kỳ thử nghiệm nào bạn làm như mã viết của bạn tốt hơn là không làm nó. Tiên đề khác là về chất lượng chứ không phải số lượng - Tôi đã thấy các cơ sở mã với 1000 bài kiểm tra về cơ bản là vô nghĩa vì phần còn lại không thực sự kiểm tra bất kỳ thứ gì hữu ích hoặc bất kỳ thứ gì cụ thể như quy tắc kinh doanh, v.v. của tên miền cụ thể. Tôi cũng đã thấy các cơ sở mã với độ bao phủ mã 30% nhưng các thử nghiệm có liên quan, có ý nghĩa và thực sự tuyệt vời khi họ đã kiểm tra chức năng cốt lõi của mã được viết và thể hiện cách sử dụng mã.

Một trong những thủ thuật yêu thích của tôi khi khám phá các khung hoặc cơ sở mã mới là viết các bài kiểm tra đơn vị cho 'nó' để khám phá cách mọi thứ hoạt động. Đó là một cách tuyệt vời để tìm hiểu thêm về một cái gì đó mới thay vì đọc một tài liệu khô khan :)

3
Vinny Carpenter

Gần đây tôi đã trải qua cùng một trải nghiệm tại nơi làm việc của tôi và thấy hầu hết trong số họ biết lợi ích lý thuyết nhưng phải được bán về lợi ích cho họ một cách cụ thể, vì vậy đây là những điểm tôi đã sử dụng (thành công):

  • Chúng tiết kiệm thời gian khi thực hiện kiểm tra âm tính, trong đó bạn xử lý các đầu vào không mong muốn (con trỏ null, ngoài các giá trị giới hạn, v.v.), vì bạn có thể thực hiện tất cả những điều này trong một quy trình.
  • Họ cung cấp phản hồi ngay lập tức tại thời điểm biên dịch liên quan đến tiêu chuẩn của các thay đổi.
  • Chúng rất hữu ích để kiểm tra các biểu diễn dữ liệu nội bộ có thể không bị lộ trong thời gian chạy bình thường.

và cái lớn ...

  • Bạn có thể không cần thử nghiệm đơn vị, nhưng khi có người khác đến và sửa đổi mã mà không hiểu đầy đủ, nó có thể bắt được rất nhiều lỗi ngớ ngẩn mà họ có thể mắc phải.
3
dlanod

Từ kinh nghiệm của tôi, kiểm tra đơn vị và kiểm tra tích hợp là một "PHẢI CÓ" trong môi trường phần mềm phức tạp.

Để thuyết phục các nhà phát triển trong nhóm của bạn viết bài kiểm tra đơn vị, bạn có thể muốn xem xét tích hợp phân tích hồi quy kiểm tra đơn vị trong môi trường phát triển của mình (ví dụ: trong quy trình xây dựng hàng ngày của bạn).

Khi các nhà phát triển biết rằng nếu thử nghiệm đơn vị thất bại, họ không phải mất quá nhiều thời gian để gỡ lỗi để tìm ra vấn đề, họ sẽ được khuyến khích viết chúng hơn.

Đây là một công cụ cung cấp chức năng như vậy:

công cụ phân tích hồi quy đơn vị kiểm tra

2
Liorp

Nếu bạn đang sử dụng NUnit, một bản demo đơn giản nhưng hiệu quả là chạy (các) bộ thử nghiệm riêng của NUnit trước chúng. Nhìn thấy một bộ thử nghiệm thực sự cho một cơ sở mã hóa tập luyện có giá trị hàng ngàn từ ...

2
Garth Gilmour

Một điều cần lưu ý về thử nghiệm đơn vị là nó mang lại sự thoải mái cho nhà phát triển.

Ngược lại, kiểm tra chức năng là dành cho người dùng: bất cứ khi nào bạn thêm kiểm tra chức năng, bạn đang kiểm tra một cái gì đó mà người dùng sẽ thấy. Khi bạn thêm một bài kiểm tra đơn vị, bạn chỉ làm cho cuộc sống của mình trở thành một nhà phát triển dễ dàng hơn. Đó là một chút xa xỉ trong khía cạnh đó.

Hãy ghi nhớ sự phân đôi này khi bạn phải lựa chọn giữa việc viết một đơn vị hoặc kiểm tra chức năng.

2
Cedric Beust

Tôi đồng ý với quan điểm trái ngược với đa số ở đây: Không ổn khi viết bài kiểm tra đơn vị Lập trình đặc biệt nặng về nguyên mẫu (ví dụ AI) rất khó kết hợp với kiểm thử đơn vị.

2
DSblizzard

Kiểm thử đơn vị giúp rất nhiều trong các dự án lớn hơn bất kỳ nhà phát triển nào có thể giữ trong đầu. Chúng cho phép bạn chạy bộ kiểm tra đơn vị trước khi đăng ký và khám phá nếu bạn đã phá vỡ thứ gì đó. Điều này cắt giảm rất nhiề trong trường hợp phải ngồi và vặn ngón tay cái trong khi chờ người khác sửa lỗi mà họ đã đăng ký hoặc gặp rắc rối trong việc hoàn nguyên thay đổi của họ để bạn có thể nhận được một số công việc làm xong. Nó cũng vô cùng có giá trị trong việc tái cấu trúc, vì vậy bạn có thể chắc chắn rằng mã được cấu trúc lại vượt qua tất cả các thử nghiệm mà mã gốc đã làm.

2
Max Rible Kaehn

Với bộ kiểm thử đơn vị, người ta có thể thay đổi mã trong khi vẫn giữ nguyên các tính năng còn lại. Đó là một lợi thế lớn. Bạn có sử dụng bộ kiểm tra đơn vị kiểm tra và hồi quy đơn vị khi bạn hoàn thành mã hóa tính năng mới.

2
Shinwari

Toàn bộ quan điểm của kiểm thử đơn vị là làm cho kiểm tra dễ dàng. Nó tự động. "làm bài kiểm tra" và bạn đã hoàn thành. Nếu một trong những vấn đề bạn gặp phải là khó kiểm tra mã, đó là lý do tốt nhất để sử dụng thử nghiệm đơn vị.

1
Deathbob

Mới hôm nay, tôi đã phải thay đổi một lớp mà bài kiểm tra đơn vị đã được viết trước đó.
[.__.] Bản thân bài kiểm tra đã được viết tốt và bao gồm các kịch bản kiểm tra mà tôi thậm chí không nghĩ tới.
[.__.] May mắn thay, tất cả các bài kiểm tra đã được thông qua và sự thay đổi của tôi đã nhanh chóng được xác minh và đưa vào môi trường kiểm tra một cách tự tin.

1
crowne

Khi bạn kiểm tra phần mềm theo cách thủ công, thông thường bạn có một bộ kiểm tra/hành động nhỏ mà bạn sử dụng. Cuối cùng, bạn sẽ tự động điều chỉnh dữ liệu hoặc hành động đầu vào của mình để bạn tự điều hướng xung quanh các vấn đề đã biết. Các bài kiểm tra đơn vị nên có mặt để nhắc nhở bạn rằng mọi thứ không hoạt động chính xác.

Tôi khuyên bạn nên viết thử nghiệm trước khi mã, thêm các thử nghiệm/dữ liệu mới để phát triển chức năng của mã chính!

1
Ray Hayes

Là một sinh viên vật lý, tôi rất muốn thực sự chứng minh rằng mã của tôi hoạt động như mong muốn. Bạn có thể chứng minh điều này một cách hợp lý, điều này làm tăng khó khăn một cách quyết liệt khi việc triển khai trở nên phức tạp hơn hoặc bạn có thể đưa ra một bằng chứng thực nghiệm (càng gần càng tốt) về chức năng thông qua thử nghiệm tốt.

Nếu bạn không cung cấp bằng chứng logic về chức năng, bạn phải kiểm tra. Thay thế duy nhất là nói "Tôi nghĩ rằng mã hoạt động ...."

1
Fredrik

@George Stocker "Thật không may, cơ sở mã của chúng tôi không cho vay để kiểm tra dễ dàng." Mọi người đều đồng ý rằng có những lợi ích đối với thử nghiệm đơn vị nhưng có vẻ như đối với mã này, chi phí rất cao. Nếu chi phí lớn hơn lợi ích thì tại sao họ phải nhiệt tình với nó? Lắng nghe đồng nghiệp của bạn; có thể đối với họ nỗi đau nhận thức của các bài kiểm tra đơn vị lớn hơn giá trị cảm nhận của các bài kiểm tra đơn vị.

Cụ thể, hãy cố gắng đạt được giá trị càng sớm càng tốt, và không phải giá trị nào đó "xUnit là màu xanh lá cây", mà là mã sạch mà người dùng và người bảo trì đánh giá cao. Có lẽ bạn phải ủy thác các bài kiểm tra đơn vị cho một lần lặp và sau đó thảo luận xem nó có đáng để nỗ lực hay không.

1
Trystan Spangler

Làm những điều đầu tiên bạn kiểm tra không liên quan đến kiểm tra đơn vị. Tôi làm việc chủ yếu ở Perl, vì vậy đây là những ví dụ cụ thể về Perl, nhưng bạn có thể thích nghi.

  • Có phải mọi mô-đun tải và biên dịch chính xác? Trong Perl, đây là vấn đề tạo Foo.t cho mỗi Foo.pm trong cơ sở mã thực hiện:

    use_ok( 'Foo' );
    
  • Tất cả các POD (Tài liệu của Ol ') có được định dạng đúng không? Sử dụng Test :: Pod để xác thực tính hợp lệ của định dạng của tất cả POD trong tất cả các tệp.

Bạn có thể không nghĩ rằng đây là những điều lớn lao, và chúng không phải, nhưng tôi có thể đảm bảo bạn sẽ bắt được một số trượt. Khi các thử nghiệm này chạy mỗi giờ một lần và nó bắt được cam kết sớm của ai đó, bạn sẽ có người nói "Này, điều đó thật tuyệt."

1
Andy Lester

Một trong những lợi ích của kiểm tra đơn vị là dự đoán.

Trước khi thử nghiệm đơn vị, tôi có thể dự đoán mức độ chính xác cao sẽ mất bao lâu để viết mã một cái gì đó, nhưng không phải tôi cần bao nhiêu thời gian để gỡ lỗi.

Ngày nay, vì tôi có thể lên kế hoạch cho những bài kiểm tra nào tôi sẽ viết, tôi biết việc viết mã sẽ mất bao lâu và khi kết thúc mã hóa, hệ thống đã được gỡ lỗi! Điều này mang lại khả năng dự đoán cho quá trình phát triển, giúp loại bỏ rất nhiều áp lực nhưng vẫn giữ được tất cả niềm vui !!.

1
Raz

Kiểm thử đơn vị là một trong những phương pháp được áp dụng nhiều nhất cho mã chất lượng cao. Đóng góp của nó cho một mã ổn định hơn, độc lập và tài liệu được chứng minh tốt. Mã kiểm tra đơn vị được coi và xử lý như một phần không thể thiếu trong kho lưu trữ của bạn và do đó yêu cầu phát triển và bảo trì. Tuy nhiên, các nhà phát triển thường gặp phải tình huống mà các tài nguyên được đầu tư vào các bài kiểm tra đơn vị không đạt được kết quả như mong đợi. Trong một thế giới lý tưởng, mọi phương thức mà chúng ta viết mã sẽ có một loạt các thử nghiệm bao gồm mã Mã hóa và xác thực tính chính xác của nó. Tuy nhiên, thông thường do giới hạn thời gian, chúng tôi hoặc bỏ qua một số bài kiểm tra hoặc viết những bài kiểm tra kém chất lượng. Trong thực tế như vậy, trong khi ghi nhớ số lượng tài nguyên đầu tư vào phát triển và bảo trì thử nghiệm đơn vị, người ta phải tự hỏi mình, trong thời gian có sẵn, mã nào xứng đáng được thử nghiệm nhất? Và từ các bài kiểm tra hiện có, bài kiểm tra nào thực sự đáng để giữ và duy trì? Xem tại đây

0
RoiG

Kiểm thử đơn vị giúp bạn phát hành phần mềm với ít lỗi hơn trong khi giảm chi phí phát triển tổng thể. Bạn có thể nhấp vào liên kết để đọc thêm về lợi ích của kiểm tra đơn vị

0
Steve_0

Ai là bạn cố gắng để thuyết phục? Kỹ sư hay quản lý? Nếu bạn đang cố gắng thuyết phục đồng nghiệp kỹ sư của mình, tôi nghĩ rằng cách tốt nhất của bạn là thu hút mong muốn của họ để tạo ra một phần mềm chất lượng cao. Có rất nhiều nghiên cứu cho thấy nó tìm thấy lỗi và nếu họ quan tâm đến việc làm tốt công việc, điều đó là đủ cho họ.

Nếu bạn đang cố gắng thuyết phục quản lý, rất có thể bạn sẽ phải thực hiện một số loại lý do chi phí/lợi ích nói rằng chi phí cho các khiếm khuyết sẽ không bị phát hiện là lớn hơn chi phí viết bài kiểm tra. Hãy chắc chắn bao gồm các chi phí không thể vượt qua, chẳng hạn như mất niềm tin của khách hàng, vv.

0
Craig H

Điều này rất .Net-centric, nhưng có ai đã thử Pex?

Tôi đã vô cùng hoài nghi cho đến khi tôi thử nó - và wow, thật là một màn trình diễn. Trước khi tôi nghĩ rằng "Tôi sẽ không bị thuyết phục bởi khái niệm này cho đến khi tôi hiểu những gì nó thực sự làm để mang lại lợi ích cho tôi". Phải mất một lần chạy để tôi thay đổi suy nghĩ và nói "Tôi không quan tâm làm thế nào bạn biết có nguy cơ xảy ra ngoại lệ nghiêm trọng ở đó, nhưng ở đó và bây giờ tôi biết tôi phải đối phó với nó "

Có lẽ nhược điểm duy nhất của hành vi này là nó sẽ gắn cờ mọi thứ và cung cấp cho bạn tồn đọng sáu tháng. Nhưng, nếu bạn có nợ mã, bạn luôn có nợ mã, bạn không biết nó. Nói với một PM có khả năng thất bại hai trăm nghìn điểm khi trước khi bạn nhận ra vài chục là một viễn cảnh khó chịu, điều đó có nghĩa là điều quan trọng là khái niệm này là giải thích trước.

0
Tom W