Bạn có sử dụng bài kiểm tra đơn vị tại nơi làm việc? Những lợi ích nào bạn nhận được từ họ? [đóng cửa]


18

Tôi đã lên kế hoạch nghiên cứu và áp dụng thử nghiệm đơn vị cho mã của mình, nhưng sau khi nói chuyện với các đồng nghiệp của tôi, một số người trong số họ đề nghị với tôi rằng nó không cần thiết và nó có rất ít lợi ích. Họ cũng tuyên bố rằng chỉ có một vài công ty thực sự thử nghiệm đơn vị với phần mềm sản xuất.

Tôi tò mò về cách mọi người đã áp dụng thử nghiệm đơn vị tại nơi làm việc và những lợi ích họ nhận được từ việc sử dụng chúng, ví dụ, chất lượng mã tốt hơn, giảm thời gian phát triển trong dài hạn, v.v.


13
"Họ cũng tuyên bố rằng chỉ có vài công ty thực hiện kiểm thử đơn vị với phần mềm sản xuất." Điều đó có nghĩa là chỉ có một vài công ty sản xuất phần mềm chất lượng cao. Bạn muốn liên kết với nhóm nào? Làm thế nào "chỉ một vài công ty" có thể là một tuyên bố tiêu cực? Chỉ có một vài công ty có lợi nhuận cao; Điều đó làm cho nó xấu? Chỉ có một vài công ty là nơi thực sự thú vị để làm việc; Điều đó làm cho nó xấu? Chỉ có một vài công ty giảm thiểu việc tạo ra chất thải; Điều đó làm cho nó xấu? Nhận xét "chỉ một vài công ty" của họ là vô nghĩa.
S.Lott

2
điều này cũng có thể không chính xác, theo giai thoại, tôi chưa làm việc cho hoặc với một công ty ít nhất đã không thực hiện một số cấp độ thử nghiệm đơn vị
jk.

1
Tôi sẽ khẳng định rằng một lập trình viên nghĩ rằng kiểm thử đơn vị "có rất ít lợi ích" là thiếu kinh nghiệm hoặc đơn giản là không biết cách viết các bài kiểm tra đơn vị hiệu quả.
Toby

Các nhà phát triển của trang web này sử dụng bao nhiêu thử nghiệm đơn vị?
JeffO

1
@ S.Lott: vô nghĩa là có, tuy nhiên, nó vẫn được coi là một đối số không làm bài kiểm tra đơn vị bởi những người không muốn làm chúng. Tôi không bảo vệ quan điểm của họ ở đây, hoàn toàn ngược lại. Tuy nhiên, tuyên bố đó vẫn được đưa ra và những người đưa ra nó bị thuyết phục về giá trị của nó và vì đó là chúng tôi phải thuyết phục về lợi ích thực tế của việc thử nghiệm loại bỏ nó vì vô nghĩa sẽ không giúp ích nhiều cho nguyên nhân lớn hơn.
Newtopian

Câu trả lời:


20

một số trong số họ đề nghị với tôi rằng nó không cần thiết

Vâng, theo nghĩa chặt chẽ, họ đúng: kiểm tra, đánh giá mã, kiểm soát nguồn, v.v. cũng không thực sự cần thiết . Chỉ có rất ít nhà phát triển hợp lý làm việc mà không có những điều này trong dài hạn. Hầu hết chúng ta đã học (thường là cách khó khăn, từ những sai lầm của chính chúng ta) tại sao đây là những thực tiễn tốt nhất.

và nó có rất ít lợi ích.

Điều này không đúng trong hầu hết các trường hợp. Đó là, nếu chúng ta đang nói về phần mềm sản xuất được cho là đang sử dụng - do đó là trong bảo trì - trong nhiều năm tới.

Họ cũng tuyên bố rằng chỉ có vài công ty thực hiện kiểm tra đơn vị với phần mềm sản xuất.

Điều này thể đúng (mặc dù theo kinh nghiệm của tôi ngày càng ít hơn), nhưng nó không có gì để nói về giá trị của thử nghiệm đơn vị. Trái ngược với câu nói đùa cũ "Chết tiệt là tốt - 50 tỷ con ruồi không thể sai!" ;-)

bạn đã áp dụng bài kiểm tra đơn vị tại nơi làm việc của bạn và bạn nhận được gì từ nó? (ví dụ: chất lượng mã tốt hơn, giảm thời gian trong dài hạn, v.v.)

Tôi đã áp dụng các bài kiểm tra đơn vị trong công việc của mình, bất cứ khi nào có thể, trong hơn 10 năm nay. Cảm giác tin tưởng vào mã của tôi, biết rằng nó hoạt động - và tôi có thể chứng minh nó mọi lúc, mọi nơi, trong vài giây, hết lần này đến lần khác, trái ngược với việc chỉ tin vào nó - là vô giá. Nó cho tôi can đảm để cấu trúc lại mã của mình, cải thiện thiết kế của nó hoặc sửa lỗi mà không sợ phá vỡ chức năng hiện có. Tôi sẽ không bao giờ quay lại những ngày xưa của "mật mã và cầu nguyện".


14

Tôi không quan tâm, nhưng không (hoặc ít) tại nơi làm việc

Những lợi ích chính của thử nghiệm tôi nhận được là, tái cấu trúc dễ dàng hơn rất nhiều và hồi quy (nghĩa là giới thiệu lại các lỗi đã được sửa) được chú ý.

Kiểm tra cuộc sống với 'bản dựng': bạn kiểm tra phần mềm với các bài kiểm tra đang chạy và bạn không kiểm tra cho đến khi tất cả các bài kiểm tra đang chạy với sửa đổi của bạn.

Vì vậy, theo kinh nghiệm của tôi, các bài kiểm tra viết gần như vô dụng khi được thực hiện theo kiểu đơn độc. Khi bạn luôn phải sửa các bài kiểm tra của mình để phù hợp với những thay đổi mà người khác đã thực hiện, khi các bài kiểm tra có thể bị xóa bởi đồng nghiệp của bạn (xin vui lòng trong các công việc trước đây của tôi) vì 'họ sẽ không cho tôi triển khai', v.v. những lợi ích ngay lập tức bị đốt cháy bởi phần còn lại của đội.

Khi toàn bộ nhóm đồng ý (và, trong nhóm 1 dễ dàng), theo kinh nghiệm của tôi, các bài kiểm tra là một lợi ích lớn cho chất lượng, kiểu dáng và sự mạnh mẽ của Dự án.

Nhưng trong một nhóm tin tưởng một cách trung thực rằng "chỉ có một vài công ty tự động kiểm tra mã của họ" và tin chắc rằng dù sao họ cũng lãng phí thời gian, dường như có rất ít hy vọng kiếm được lợi ích, nhưng khả năng lớn là bạn sẽ được tạo ra chịu trách nhiệm về việc "mất thời gian" khi chỉ ra lỗi.

Cơ hội tốt nhất để giới thiệu các bài kiểm tra sẽ là một dự án nhỏ thuộc trách nhiệm của bạn. Ở đó bạn sẽ có cơ hội để tỏa sáng và chứng minh giá trị của các bài kiểm tra.


1
Xin lỗi vì nghe có vẻ tiêu cực, nhưng tôi vẫn bị đốt cháy bởi 'làm thế nào để hoàn thành công việc như một người cằn nhằn';)
keppla

Lời khuyên rất tốt. Vấn đề là khi thực hiện đúng, bạn thực sự không thấy lợi ích của việc kiểm tra đơn vị. Bạn chỉ có khả năng thấy tác hại khi không thực hiện kiểm tra đơn vị. Vì vậy, nếu bạn cần thuyết phục người khác bằng các số liệu thống kê, thay vì lý thuyết, bạn sẽ gặp khá nhiều khó khăn.
Peter Kruithof

12
@keppla, tôi đã từng viết bài kiểm tra đơn vị trong các dự án mà các đồng đội của tôi thậm chí chưa từng nghe về bài kiểm tra đơn vị trước đây. Khi các bài kiểm tra của tôi có thể bắt được một vài lỗi có thể bị bỏ qua mà không được chú ý, những bài kiểm tra khác bắt đầu chú ý và chẳng mấy chốc họ muốn tự học kiểm tra đơn vị. Bằng chứng cụ thể là vua.
Péter Török

1
@keppla, đủ công bằng, nếu đồng đội bị thiên vị đến mức đánh mất ý thức chung, không có cách nào để thuyết phục họ bằng bằng chứng logic :-( Trong trường hợp như vậy, với sự hỗ trợ quản lý mạnh mẽ, bạn vẫn có thể thành công để vượt qua ý tưởng , nhưng không có điều đó, không có hy vọng.
Péter Török

3
Bạn 'phá vỡ' các bài kiểm tra thường xuyên bằng cách thay đổi giao diện, xóa Lớp học, v.v. Khi bạn thực hiện 'kiểm tra trước', bạn không trải nghiệm điều này như 'phá vỡ', mà là bước đầu tiên 'Đỏ'. Nhưng khi bạn ở trong 'Chỉ cần thêm một số dòng cho đến khi nó hoạt động', các bài kiểm tra chỉ là nhiều dòng hơn. Và khi 'cố định' bởi một người như thế này, các bài kiểm tra có xu hướng giảm dần về tính hữu dụng, cho đến khi chúng thực sự không phục vụ mục đích. Tiên tri Selffulfilling 4tw!
keppla

7

Tôi có xu hướng bên cạnh các đồng nghiệp của bạn, nhưng chỉ đến một điểm.

Vấn đề với các bài kiểm tra đơn vị là chúng được viết thường xuyên và không suy nghĩ về các trường hợp tầm thường trong đó việc điều tra mã hóa cho thấy rằng nó sẽ hoạt động bất kể là gì. Ví dụ:

def add(x, y)
  x + y
end

Cùng với một tá các thử nghiệm để đảm bảo rằng bổ sung sẽ thực sự hoạt động cho các trường hợp sử dụng được lựa chọn tùy ý. Tât nhiên...

Tiền đề chung đằng sau kiểm thử đơn vị là: nếu mã của bạn không có lỗi, đó là do bạn chưa kiểm tra đủ. Bây giờ, khi viết bài kiểm tra đơn vị thích hợp. Đáp án:

  1. Khi bạn đang thử nghiệm
  2. Khi bạn gỡ lỗi
  3. Khi bạn đang phát triển những thứ thực sự khó khăn

Chúng ta hãy đi qua từng cái, giả sử bạn đang phát triển một loại ứng dụng web nào đó.

Bạn viết một số mã cho chức năng mới và bây giờ nó sẽ hoạt động tốt. Sau đó, bạn tiếp cận với trình duyệt của mình và xác minh rằng nó hoạt động bằng cách kiểm tra chuyên sâu hơn, phải không? Bzzzt! ... Trả lời sai. Bạn viết một bài kiểm tra đơn vị. Nếu bạn không làm như vậy bây giờ, có lẽ bạn sẽ không bao giờ. Và đây là một trong những nơi mà các bài kiểm tra đơn vị hoạt động rất tốt: để kiểm tra chức năng cấp cao.

Sau đó, bạn phát hiện ra một lỗi (ai không bao giờ bỏ lỡ bất kỳ?). Điều này đưa chúng ta đến điểm hai. Bạn quay lại mã và bắt đầu làm theo các bước. Khi bạn làm như vậy, hãy viết các bài kiểm tra đơn vị tại các điểm ngắt quan trọng trong đó việc có dữ liệu phù hợp và chính xác là rất quan trọng.

Điểm cuối cùng là cách khác. Bạn đang thiết kế một số chức năng lông bao gồm vô số lập trình meta. Nó nhanh chóng sinh ra một cây quyết định với hàng ngàn kịch bản tiềm năng và bạn cần chắc chắn rằng mỗi một trong số chúng đều hoạt động. Khi viết những điều như vậy, một sự thay đổi tìm kiếm đơn giản ở đây hoặc ở đó có thể có những hậu quả không thể tưởng tượng hơn nữa trong chuỗi thức ăn. Giả sử, bạn đang thiết kế triển khai MPTT bằng các trình kích hoạt SQL - để nó có thể hoạt động với các câu lệnh nhiều hàng.

Trong loại môi trường chông gai này, thông thường bạn sẽ muốn tự động hóa cao các bài kiểm tra của mình. Vì vậy, bạn viết các kịch bản để tự động hóa việc tạo dữ liệu thử nghiệm và chạy một tải trọng các thử nghiệm đơn vị trên dữ liệu thử nghiệm này. Một điều quan trọng để không bị mất dấu khi bạn làm điều này, đó là bạn cũng cần phải viết bài kiểm tra đơn vị cho trình tạo thử nghiệm đơn vị của bạn.

Tóm lại: kiểm tra đơn vị, chắc chắn là có. Nhưng hãy dành cho mình những chức năng cơ bản - cho đến khi bạn thực sự cần chúng để gỡ lỗi, hoặc đảm bảo một số chức năng lông hoạt động đúng (bao gồm, trong trường hợp sau, chính các bài kiểm tra).


Như Kent Beck đã nói: "kiểm tra mọi thứ có thể phá vỡ."
Péter Török

1
Đồng ý hết lòng với anh. Hy vọng chính của tôi là OP sẽ lưu ý: đừng quên kiểm tra các bài kiểm tra khi áp dụng. :-)
Denis de Bernardy

7

Tất cả các mã phải được kiểm tra. Không có lựa chọn về điều đó.

Mã chưa được kiểm tra là vô ích: không thể tin tưởng để làm bất cứ điều gì.

Bạn có thể viết bài kiểm tra đơn vị hoặc bạn có thể hy vọng viết bài kiểm tra tích hợp cấp cao hơn hoặc bài kiểm tra chấp nhận.

Các bài kiểm tra đơn vị dễ viết hơn, dễ gỡ lỗi hơn và dễ quản lý hơn.

Kiểm tra tích hợp dựa trên các giả định rằng các đơn vị thực sự làm việc. Không có bài kiểm tra đơn vị, làm thế nào để bạn biết các đơn vị làm việc? Làm thế nào bạn có thể gỡ lỗi kiểm tra tích hợp nếu bạn không biết các đơn vị riêng lẻ được tích hợp thực sự hoạt động?

Kiểm tra chấp nhận, tương tự, phụ thuộc vào tất cả các phần và các bộ phận làm việc. Làm thế nào bạn có thể biết các phần và các bộ phận hoạt động mà không có một bộ các bài kiểm tra đơn vị?

Kiểm tra là bắt buộc. Tất cả các bài kiểm tra cấp cao hơn phụ thuộc vào các đơn vị thực sự làm việc.

Điều đó làm cho thử nghiệm đơn vị là một sự cần thiết hợp lý. Không còn lựa chọn nào khác.


1
Không có lựa chọn nào khác ... nếu bạn quan tâm đến chất lượng. Hầu hết các tổ chức phần mềm không thực sự quan tâm đến chất lượng (cho đến nay họ từ chối vận chuyển phần mềm được biết là bị hỏng).
Joeri Sebrechts

@Joeri Sebrechts: Đây không phải là vấn đề chất lượng. Đó là một vấn đề "đã xong". Ngay cả phần mềm xấu cũng cần được kiểm tra để chứng minh rằng nó làm được điều gì đó - bất cứ điều gì. Logic đơn giản chỉ ra rằng phải có một thử nghiệm để chứng minh rằng nó hoạt động. Ngay cả một bài kiểm tra xấu là một bài kiểm tra. Logic đơn giản chỉ ra rằng một bài kiểm tra tổng thể phải bao gồm các bài kiểm tra của các bộ phận. Kiểm thử đơn vị được yêu cầu đơn giản bằng logic, không có gì khác. Không phải cân nhắc chất lượng, nhưng theo định nghĩa của "thực hiện".
S.Lott

1
Sử dụng phần mềm là một thử nghiệm của chính nó. Rất nhiều tổ chức rất vui khi khiến người dùng thực hiện thử nghiệm. Tôi không nói rằng đó là một điều tốt, nhưng nó là như vậy. Bạn thực sự có thể chọn không kiểm tra trước khi giao hàng, giảm tải thử nghiệm cho người dùng cuối. Bạn có thể, nhưng bạn không nên.
Joeri Sebrechts

1
@Joeri Sebrechts: Thật ra, bạn không thể. Bạn không thể chuyển phần mềm - một cách ngẫu nhiên - cho người dùng để kiểm tra chấp nhận. Bạn phải chạy phần mềm ít nhất một lần để chắc chắn rằng nó có vẻ hoạt động. Đó là một bài kiểm tra - một bài kiểm tra tồi - nhưng là một bài kiểm tra. Theo logic, kiểm tra xấu đó kết hợp kiểm tra đơn vị xấu. Họ tồn tại, mặc dù họ rất xấu.
S.Lott

định nghĩa của bạn về một bài kiểm tra đơn vị là vô ích cho cuộc thảo luận này. Một bài kiểm tra đơn vị là một bài kiểm tra được mã hóa và hoàn toàn không cần thiết để gửi phần mềm. (nhưng tốt để làm trong nhiều trường hợp)
Martin Ba

6

Tôi sử dụng các bài kiểm tra đơn vị cho tất cả mọi thứ tôi viết và tôi không để bất kỳ mã chưa được kiểm tra nào vượt qua đánh giá mà không có trường hợp kiểm tra. (Nhưng tôi thiếu một công cụ bảo hiểm, vì vậy tôi phải suy luận về phạm vi kiểm tra. Một điều tại một thời điểm ...)

Điều này khá đơn giản: nếu bạn không thể chứng minh rằng mã của bạn hoạt động (và cách nào tốt hơn một đặc tả thực thi dưới dạng thử nghiệm?) Thì nó không hoạt động .

Điều này mang lại cho tôi:

  • Yên tâm: máy chủ CI của tôi cho tôi biết toàn bộ hoạt động của cơ sở mã.
  • Khả năng cải thiện mã của tôi: Tôi có thể cơ cấu lại mã của mình - tái cấu trúc mã - biết rằng sau khi tái cấu trúc tôi không bị hỏng gì.

2
Tôi đã thêm một cảnh báo rất quan trọng vào đó - kiểm tra đơn vị sẽ không đảm bảo rằng "toàn bộ cơ sở mã của bạn hoạt động". Nó sẽ đảm bảo rằng tất cả các đơn vị mã hoạt động độc lập, nhưng vẫn có khả năng lớn xảy ra lỗi tích hợp, lỗi khi trình bày dữ liệu trực quan, v.v.
Ryan Brunner

Trừ khi môi trường của bạn trôi qua "nếu bạn không thể chứng minh rằng mã của bạn không hoạt động thì nó vẫn hoạt động." : p
Davy8

@Ryan: Tất nhiên các bài kiểm tra tích hợp của bạn sẽ thúc đẩy toàn bộ dự án. Câu hỏi là về các bài kiểm tra đơn vị vì vậy tôi đã nói về các bài kiểm tra đơn vị, nhưng tất nhiên bạn nên chứng minh sự cần thiết của một đoạn mã bằng cách kiểm tra tích hợp không thành công. Và tất nhiên, bạn nên có một máy chủ CI tự động triển khai cơ sở mã của bạn và chạy tất cả các thử nghiệm
Frank Shearar

@ Davy8: Trong trường hợp nào bạn gặp vấn đề nghiêm trọng hơn "làm bài kiểm tra đơn vị có hiệu quả không?".
Frank Shearar

4

Kiểm tra đơn vị là một kỷ luật. Bởi vì mã không cần thiết để làm việc, nó thường bị loại bỏ.

Tuy nhiên, đó là một phương pháp đã được chứng minh dẫn đến mã mạnh mẽ và ít lỗi hơn. Tôi không nghĩ rằng tôi cần phải giải thích những lợi ích cho bạn, như bạn đã đề cập đến một số. Nếu bạn xem xét một số dự án nguồn mở hàng đầu, cho dù chúng là thư viện javascript, khung công tác toàn ngăn xếp hoặc ứng dụng đơn mục đích, tất cả đều sử dụng thử nghiệm đơn vị.

Tôi nghi ngờ các đồng nghiệp của bạn khuyên không nên sử dụng nó không phải là lập trình viên. Nếu đúng như vậy, hãy nói rằng không có nhiều người tôi đánh giá cao hơn những người như Martin Fowler hay Kent Beck ;).

Giống như hầu hết các thực tiễn tốt nhất, lợi ích là lâu dài, bạn cần đầu tư một chút thời gian vào nó. Bạn có thể viết một đoạn mã dài của mã thủ tục, nhưng tất cả chúng ta đều biết rằng bạn ước mình đã viết nó theo kiểu hướng đối tượng khi bạn cần cấu trúc lại mã sau 2 năm.

Điều tương tự cũng xảy ra đối với thử nghiệm đơn vị. Nếu bạn viết các bài kiểm tra đơn vị cho các phần quan trọng trong ứng dụng của mình, bạn có thể chắc chắn rằng nó hoạt động như dự định, mọi lúc, ngay cả sau khi tái cấu trúc mã. Có thể bạn viết mã tốt đến mức bạn không bao giờ có lỗi hồi quy. Nhưng nếu bạn không, hoặc một lập trình viên mới gia nhập nhóm của bạn, bạn muốn chắc chắn rằng các lỗi của quá khứ sẽ không xảy ra lần nữa. Tôi nghĩ rằng ông chủ của bạn cũng sẽ hài lòng với điều đó, trái ngược với việc phải nộp báo cáo lỗi mà ông nghĩ đã được giải quyết nửa năm trước.


3

Kiểm tra đơn vị yêu cầu ngôn ngữ thân thiện kiểm tra đơn vị, thiết kế thân thiện kiểm tra đơn vị và vấn đề thân thiện kiểm tra đơn vị.

C ++, thiết kế đa luồng và GUI sẽ là một cơn ác mộng và phạm vi bảo hiểm sẽ rất kinh khủng.

.NET, lắp ráp dll đơn luồng có thể tái sử dụng, logic tính toán thuần túy sẽ dễ dàng.

Có đáng không, tôi thực sự không thể nói.

Bạn có tái cấu trúc nhiều không? Bạn có thấy "lỗi ngu ngốc" như "tắt bởi một" trong mã của bạn nhiều không?

Dù bạn làm gì, đừng trở thành kẻ chỉ trích người khác bằng cách "bạn không có bài kiểm tra đơn vị, do đó bạn rất tệ". Nếu các bài kiểm tra giúp bạn, hãy làm điều đó, nếu không, nó không giống như chúng là một viên đạn bạc.


1
Tại sao thiết kế đa luồng sẽ là một cơn ác mộng? Thiết kế cho các điểm đồng bộ hóa, và thử nghiệm ở đó.
Frank Shearar

1
Bởi vì thời gian phụ thuộc vào các giai đoạn mặt trăng, xung nhịp CPU, rác và khá nhiều thứ. Trong một lần kiểm tra, bài kiểm tra có thể thất bại, nếu bạn may mắn, trên 1000 người khác thì không.
Coder

1
Tôi đã viết công cụ đa luồng hướng kiểm tra. Đó chắc chắn là có thể làm được.
Frank Shearar

4
rác, bạn có thể kiểm tra đơn vị bằng bất kỳ ngôn ngữ nào.
jk.

1
Đó là bài kiểm tra đơn vị viết khó cho các tương tác GUI, nhưng đó là lý do tại sao chúng tôi tách biệt mọi thứ (mã công cụ của chúng tôi) không liên quan đến GUI. Nó giúp chúng tôi đưa ra quyết định tốt khi tách công cụ khỏi GUI, cộng với, Kiểm tra đơn vị hoạt động như giao diện của chúng tôi thay cho GUI, hỏi và cung cấp thông tin mà chúng tôi thường cần.
Cơ hội

3

Tôi muốn , nhưng tôi đã gặp bất hạnh khi gần như hoàn toàn làm việc tại các công ty không quan tâm đến chất lượng và tập trung hơn vào việc vứt rác cùng nhau mà có thể là nếu bạn có thể nheo mắt. Tôi đã đề cập đến các bài kiểm tra đơn vị và tôi nhận được "Huh?" Kiểu giao diện (giao diện giống như tôi nhận được khi tôi đề cập đến các nguyên tắc RẮN hoặc ORM hoặc các mẫu thiết kế ngoài "lớp với tất cả các phương thức tĩnh" hoặc theo các quy ước đặt tên .NET). Tôi chỉ từng ở một công ty hiểu điều đó, và không may đó là một hợp đồng ngắn hạn và bộ phận này đã cắt giảm chi phí để không có đủ thời gian để thực sự học hỏi.

Tôi đã tham gia các bài kiểm tra đơn vị trong các dự án giả, nhưng tôi chưa thực sự hiểu về TDD / BDD, và không có một người cố vấn nào có thể giúp đỡ để làm điều đó khó hơn nhiều.


2

Chung tôi sử dụng chung. Một lợi ích lớn mà chúng tôi nhận được là kiểm tra khung kiểm tra đơn vị của chúng tôi để kiểm tra rò rỉ bộ nhớlỗi phân bổ . Đôi khi vấn đề nằm ở chính mã kiểm tra đơn vị, nhưng thường là do mã sản xuất.

Đó là một cách tuyệt vời để tìm thấy những điều bị bỏ qua trong đánh giá mã.

Các bài kiểm tra đơn vị (nên) cũng chạy rất nhanh và có thể chạy như một phần của tích hợp liên tục của bạn sau mỗi lần cam kết duy nhất và cũng bởi các nhà phát triển trước khi cam kết. Chúng tôi có hơn 1.000 mà chỉ mất chưa đến 20 giây để chạy.

So sánh với hơn 40 phút cho các thử nghiệm tự động hóa ở cấp hệ thống và giờ / ngày để thử nghiệm thủ công. Tất nhiên, kiểm tra đơn vị không phải là thử nghiệm duy nhất bạn nên thực hiện, nhưng ở cấp độ mã tốt, chúng có thể giúp tìm lỗi và kiểm tra các trường hợp cạnh mà thử nghiệm tích hợp / hệ thống không thể chạm tới. Mã của chúng tôi phải được kiểm tra với độ bao phủ quyết định trên 75% và phạm vi bảo hiểm chức năng 100%, sẽ rất khó đạt được nếu không có kiểm tra đơn vị.


2

Tôi muốn nói các bài kiểm tra đơn vị làm tăng giá trị, nhưng tôi không phải là môn đệ TDD lớn. Tôi thấy lợi ích nhất với các bài kiểm tra đơn vị khi tôi thực hiện các công cụ calc, hoặc bất kỳ loại động cơ nào thực sự và sau đó các lớp tiện ích, kiểm tra đơn vị là rất hữu ích sau đó.

Tôi thích kiểm tra tích hợp tự động cho các khối phụ thuộc dữ liệu nhiều hơn, nhưng tất cả phụ thuộc vào tôi trong ngành kinh doanh dữ liệu, vì vậy nhiều lỗi liên quan đến dữ liệu trong môi trường của chúng tôi hơn bất kỳ điều gì khác và để kiểm tra tích hợp tự động hoạt động tốt. Kiểm tra dữ liệu trước và sau và tạo báo cáo ngoại lệ từ các thử nghiệm đó.

Vì vậy, kiểm tra đơn vị thực sự làm tăng giá trị, đặc biệt nếu đơn vị bạn đang kiểm tra có thể được cung cấp tất cả các đầu vào mà nó cần và tự hoạt động với đầu vào đã cho. Một lần nữa trong trường hợp của tôi, các công cụ calc và các lớp tiện ích là những ví dụ hoàn hảo về những điều này.


2

Chi phí: Làm chậm mã, Học đường cong, Quán tính của nhà phát triển

Lợi ích: Nói chung tôi thấy mình viết mã tốt hơn khi tôi thử nghiệm đầu tiên - RẮN khôn ngoan ...

Nhưng IMHO, lợi ích lớn nhất tôi nghĩ, là độ tin cậy trong các hệ thống lớn hơn thay đổi thường xuyên. Kiểm tra đơn vị tốt sẽ tiết kiệm mông của bạn (đã khai thác) khi bạn phát hành nhiều phiên bản và có thể loại bỏ một lượng lớn chi phí liên quan đến các quy trình QA thủ công. Tất nhiên nó sẽ không đảm bảo mã miễn phí lỗi nhưng nó sẽ bắt được một số mã khó dự đoán. Trong các hệ thống phức tạp lớn, đây thực sự có thể là một lợi ích rất lớn.


0

Tôi làm một số bài kiểm tra đơn vị tại nơi làm việc khi tôi có cơ hội, và tôi cố gắng thuyết phục các đồng nghiệp của mình làm điều tương tự.

Tôi không tôn giáo về điều đó, nhưng kinh nghiệm cho thấy các phương pháp kinh doanh và tiện ích đã được thử nghiệm đơn vị rất mạnh mẽ và có xu hướng có ít hoặc không có lỗi xuất hiện trong giai đoạn thử nghiệm, điều này giúp giảm chi phí cho dự án.


0

Tôi thấy lợi thế thực sự của việc mã hóa Bài kiểm tra đơn vị và biến phần thực thi kiểm tra đơn vị thành một phần của quá trình xây dựng hàng ngày là trên một dự án với hơn 30 nhà phát triển làm việc ở 3 châu lục khác nhau. Trường hợp các bài kiểm tra đơn vị thực sự tỏa sáng là khi ai đó sẽ tinh tế thay đổi một lớp mà họ duy trì mà không hiểu cách mọi người sử dụng lớp đó. Thay vì chờ đợi mã đến nhóm thử nghiệm, đã có phản hồi ngay lập tức khi các thử nghiệm đơn vị của người khác bắt đầu không thành công do thay đổi. [Đó là lý do tại sao tất cả các bài kiểm tra đơn vị cần phải được chạy thường xuyên, không chỉ các bài kiểm tra bạn đã viết cho mã của mình.]

Hướng dẫn của tôi để kiểm tra đơn vị là:

  1. Kiểm tra mọi điều kiện bạn có thể nghĩ về mã của mình, bao gồm đầu vào xấu, ranh giới, v.v.
  2. Tất cả các bài kiểm tra đơn vị cho tất cả các mô-đun nên được thực hiện thường xuyên (nghĩa là một phần của các bản dựng hàng đêm)
  3. Kiểm tra kết quả kiểm tra đơn vị!
  4. Nếu ai đó tìm thấy một lỗi trong mã của bạn đã vượt qua các bài kiểm tra của bạn, hãy viết một bài kiểm tra mới cho nó!

0

Gần đây tôi đã học TDD và thấy rằng nó rất hữu ích. Nó mang lại sự tự tin hơn rằng mã của tôi đang hoạt động như tôi mong đợi. Cùng với việc thực hiện bất kỳ bao thanh toán lại mà tôi muốn làm dễ dàng hơn. Bất cứ khi nào một lỗi được tìm thấy, bạn có thể đảm bảo rằng thông qua thử nghiệm mà nó sẽ không xuất hiện lại.

Phần khó nhất là viết bài kiểm tra đơn vị tốt .

Nó là một điểm chuẩn tốt cho mã của bạn.

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.