Nếu thử nghiệm đơn vị là tuyệt vời như vậy, tại sao nhiều công ty không làm điều đó? [đóng cửa]


103

Công ty phần mềm thực sự đầu tiên mà tôi làm việc là về kiểm thử đơn vị (NUnit). Tôi không biết rằng hồi đó chúng tôi là những người gắn bó thực sự với nó - tôi không biết độ phủ mã của chúng tôi như thế nào và tôi đã viết hầu hết các bài kiểm tra đơn vị. Kể từ đó, tôi đã gặp một số công ty thực hiện rất nhiều thử nghiệm, nhưng đó là thử nghiệm chủ tọa: dựa vào một người ở đó, có độ lặp lại thấp và khả năng bắt lỗi thấp. Thái độ khác là: đó là thứ họ muốn tiếp tục "trong tương lai"; về cơ bản khi tiền từ trên trời rơi xuống.

Tôi bỏ lỡ thử nghiệm đơn vị - nó chỉ làm cho cuộc sống dễ dàng hơn. Nhưng tôi nhận thấy rằng khi tôi tìm kiếm một công việc mới, thử nghiệm đơn vị là thứ mà các công ty muốn "bắt tay vào làm" trong tương lai hoặc là thứ mà họ không làm gì cả (uhh, nó đã xuất hiện được một thời gian rồi hiện nay!). Tôi muốn nói rằng 60-75% yêu cầu công việc mà tôi đã xem trong 2 năm qua không hề liệt kê unit testing. Tôi chỉ có thể nghĩ đến một hoặc hai người đã có kinh nghiệm kiểm thử đơn vị như một yêu cầu (đối với vị trí nhà phát triển cấp trung).

Vì vậy, câu hỏi là, những gì còn thiếu ? Tôi nghĩ nó giúp mọi người làm việc hiệu quả hơn, nhưng đó chỉ là sau khi dành một khoảng thời gian dài để thực sự làm việc đó. Không có bất kỳ nghiên cứu tốt nào về tiết kiệm chi phí của thử nghiệm đơn vị? Đó có phải là loại hình công ty tôi đang xem xét không?

Chỉnh sửa: mặc dù tiêu đề có một chút ủng hộ quỷ, tôi tự coi mình là người đề xuất thử nghiệm đơn vị.


Bạn đang làm việc trong lĩnh vực nào? Tôi luôn gặp phải các bài kiểm tra đơn vị, với mức độ hoàn chỉnh khác nhau, ở bất cứ nơi nào tôi làm việc. Nhưng kinh nghiệm của tôi trong những lời dối trá hình ảnh y tế và công nghiệp, do đó có thể là lý do tại sao ...
Kena

Vâng, tôi nghi ngờ bạn đúng. Miền của tôi thường là các ứng dụng dòng doanh nghiệp; không có ai trong cuộc sống cân bằng. Nhưng đôi khi một số hóa đơn trong số dư và điều đó có thể tốn kém.
jcollum

11
Kiểm tra chủ tọa: người ngồi trên ghế, điều khiển ứng dụng, báo cáo lỗi.
jcollum

3
@Darknight nên có 50k lượt ủng hộ vì sự trung thực của anh ấy. Thôi những cái đầu cũ, hãy bắt kịp thời đại ngày nay. Giữ cho đơn vị thử nghiệm tào lao đó trở lại những năm 90 nơi nó thuộc về. Lãng phí thời gian lớn nhất. Nó chỉ là một cái gì đó để giới thiệu để bạn có thể trông quan trọng, nhưng hoàn toàn không có tác dụng gì trong hầu hết các trường hợp. Ngày nay, chúng tôi có một thứ gọi là IDE, chúng tôi không lập trình bằng bảng điều khiển hoặc trong notepad nữa. Chúng tôi biết mã của chúng tôi là chính xác vì chúng tôi có thể trỏ chuột qua văn bản và xem các giá trị. Giữ thử nghiệm đơn vị trong quá khứ với tất cả các bộ đếm thời gian cũ khác.
portfoliobuilder

1
@portfoliobuilder Vâng, việc di chuyển qua các giá trị trong IDE của bạn sẽ thực sự giúp cải thiện chất lượng mã. Bởi vì trạng thái sẽ luôn giống nhau, và mã sẽ không bao giờ thay đổi. Đúng rồi! Và chúc may mắn.
Franz D.

Câu trả lời:


112

Theo kinh nghiệm của tôi, có một vài yếu tố liên quan đến việc này:

  1. Ban quản lý không thực sự hiểu thử nghiệm đơn vị thực sự là gì, hoặc tại sao nó có giá trị nội tại thực sự đối với họ.
  2. Ban lãnh đạo có xu hướng quan tâm hơn đến việc phân phối sản phẩm nhanh chóng và (không chính xác) coi thử nghiệm đơn vị là phản tác dụng đối với mục tiêu đó.
  3. Có một nhận thức sai lầm rằng kiểm tra chỉ thuộc về mục đích của QA. Các nhà phát triển là những lập trình viên và không thể viết các bài kiểm tra.
  4. Có một quan niệm sai lầm phổ biến rằng ban quản lý sẽ phải chi tiền để thực hiện kiểm tra đơn vị một cách chính xác, mặc dù thực tế là các công cụ này được cung cấp miễn phí. (Tất nhiên, nhà phát triển tăng thời gian để xem xét, nhưng nó không thực sự bị cấm.)
  5. Câu trả lời của Will sẽ làm tròn câu trả lời này: Rất khó để xác định giá trị của mã kiểm tra (sửa jcollum)

Đương nhiên, có những yếu tố khác, nhưng đó chỉ là những gì tôi gặp phải cho đến nay.


Vâng, đã mô tả khá nhiều về cách quản lý của tôi và chúng tôi không có thử nghiệm.
Ty.

Và hỗ trợ cho nó trong một số ngôn ngữ phổ biến (C / C ++) là kém.
Martin Beckett 17/02/09

@mgb - CxxUnit hoạt động khá tốt đối với tôi ...
Dominic Rodger

2
CxxTest cũng rất tốt. Do cơ chế phản xạ kém trong C ++, có vẻ như có nhiều "giải pháp" đa dạng hơn được trình bày; CxxTest yêu cầu một bước tiền xử lý trong hệ thống xây dựng, trong khi các công cụ như TUT hoàn toàn hỗ trợ thời gian biên dịch và ngôn ngữ, nhưng rất khó sử dụng.
Tom

2
Tôi nhận thấy rằng người dùng trên stackoverflow.com có ​​xu hướng đổ lỗi cho ban quản lý vì rất nhiều vấn đề như thế này. Khi tôi hỏi những người bạn ngoài đời của mình về 'vấn đề quản lý' của họ phát sinh, tôi thường thấy rằng họ thậm chí chưa bao giờ nói lên mối quan tâm của mình với ban quản lý, ít phải bắt tay vào chiến dịch thay đổi quan điểm của mọi người. Thay vì nói rằng 'quản lý không ...', tôi cố gắng và nghĩ cách có thể giúp ban quản lý thấy được quan điểm của tôi và thuyết phục họ rằng quan điểm của tôi là đúng. Tôi nghĩ đây là một vấn đề bởi vì các nhà phát triển không giỏi trong việc bán thử nghiệm đơn vị.
Brian Stinar

87

1) Khó
2) Cần thời gian
3) Rất khó xác định giá trị của mã kiểm tra

Điểm 3 là một điểm dính. Kiểm tra đơn vị tốt sẽ giảm lỗi. Nhưng mã sản xuất tốt cũng vậy. Làm cách nào để bạn xác định có bao nhiêu lỗi không tồn tại do các bài kiểm tra đơn vị của bạn? Bạn không thể đo lường những gì không tồn tại. Bạn có thể chỉ đến các nghiên cứu, nhưng chúng không vừa vặn trên bảng tính của người quản lý doanh nghiệp của bạn.


11
"Kiểm tra đơn vị tốt sẽ giảm lỗi. Nhưng mã sản xuất tốt cũng vậy." - Kiểm tra đơn vị tốt giúp cải tiến mã sản xuất. Ngay cả khi mã lúc đầu không tốt, nhưng bạn có khả năng kiểm tra tốt, bạn có thể tự tin cấu trúc lại hệ thống cho đến khi mã tốt.
Esko Luontola 17/02/09

1
Esko ngoài khả năng che phủ tốt, bạn còn phải có những bài test tốt, thực sự kiểm tra một thứ gì đó. Bạn có thể có độ phủ mã 100% và thực sự chỉ đang thử nghiệm rất ít
Jacob Adams

Câu trả lời xuất sắc! Bạn đã nói điều tương tự như câu trả lời của tôi với ít từ hơn nhiều.
Wedge

2
Có, các bài kiểm tra đơn vị mất thời gian. Nhưng "sửa lỗi ngẫu nhiên" cũng vậy. Phát triển theo hướng kiểm tra thích hợp có "tất cả" các tính năng "được ghi lại" trong các thử nghiệm. Nếu các bài kiểm tra có màu xanh lục, sản phẩm hoạt động như dự kiến ​​(ngoại trừ các vấn đề về khả năng sử dụng, v.v.). Kinh nghiệm của tôi là tổng thời gian phát triển hầu như không bị ảnh hưởng gì cả. Bạn dành nhiều thời gian hơn cho mọi thứ và làm đúng ngay lần đầu tiên thay vì dành thời gian sửa lỗi.
Arve Systad

Và khá nhiều nghiên cứu cho thấy rằng kiểm thử đơn vị có giá trị âm. Vì vậy, việc chỉ ra các nghiên cứu là rất khó kết luận và do đó nên đưa ra một số phản đối quản lý cho đến khi có thể đưa ra khả năng là đối với cửa hàng được đề cập, giá trị là dương
Rune FS

70

Thật dễ dàng đổ lỗi cho “quản lý”. Nhưng ban quản lý có thực sự nói với bạn rằng không thực hiện bất kỳ thử nghiệm đơn vị nào không?

Quản lý nói chung không (và có lẽ không nên) cho bạn biết cách thực hiện công việc của mình, cho dù đó là mô-đun hóa, kiểu dữ liệu trừu tượng, mẫu thiết kế hay kiểm thử đơn vị. Đây là những công cụ thương mại mà một kỹ sư phần mềm thành công, có năng lực áp dụng, nhưng một kỹ sư kém thì không.

Tôi nghĩ câu trả lời thực sự cho câu hỏi của bạn là: kiểm tra đơn vị thực sự khó và sinh viên khoa học máy tính không được đào tạo cho nó.

Thật dễ dàng khi bạn đang viết lớp chuỗi của riêng mình. Khi bạn đang thử nghiệm một sản phẩm ngoài đời thực, bạn sẽ gặp phải những thách thức mà không ai nói với bạn trong slide powerpoint:

  • Tương tác người dùng. Một nửa ứng dụng của bạn là logic giao diện người dùng. Làm cách nào để bạn kiểm tra nó theo cách tự động, nó không bị hỏng nếu bạn di chuyển một nút?
  • Tương tác với các API và khuôn khổ bên ngoài. Nếu bạn đang viết một trình điều khiển nhân Windows, bạn kiểm tra nó như thế nào? Bạn có viết sơ khai cho mọi IRP và chức năng hạt nhân mà bạn sử dụng, tạo hiệu quả mô phỏng hạt nhân hệ điều hành không?
  • Truyền thông mạng là thứ của thế kỷ 21. Làm thế nào để bạn điều phối một bài kiểm tra đơn vị bao gồm một số thành phần phân tán?
  • Làm thế nào để bạn chọn các trường hợp thử nghiệm tốt? Tôi thường thấy mọi người thử cách tiếp cận "làm những việc ngẫu nhiên trong một vòng lặp 1000 lần và xem liệu nó có bị phá vỡ hay không". Khi bạn làm điều này, nỗ lực cao hơn lợi nhuận, các lỗi quan trọng bị bỏ qua và thử nghiệm đơn vị bị bỏ qua.
  • Làm thế nào để bạn kiểm tra xem các yêu cầu về hiệu suất được đáp ứng?
  • Kiến thức về các mẫu trong kiểm thử rất khan hiếm: sơ khai, phản hồi soạn trước, kiểm tra hồi quy là những khái niệm mà hầu hết mọi người không biết. Có bao nhiêu người ở nơi làm việc của bạn thực sự đọc một cuốn sách về kiểm thử đơn vị?

Một điều mà chúng tôi có thể đổ lỗi cho ban quản lý là các thông số kỹ thuật yêu cầu hiếm khi chứa bất kỳ yêu cầu nào về mức chất lượng của sản phẩm có thể phân phối.

Lần tới khi sếp yêu cầu bạn ước tính thời gian, hãy bao gồm thời gian viết bài kiểm tra đơn vị và xem điều gì sẽ xảy ra.


2
Ý tưởng tốt. Nhưng đừng gọi thời gian để tạo các bài kiểm tra đơn vị tách biệt với thời gian tạo mã "sản phẩm"!
Jeff Kotula

3
Đọc câu trả lời này khiến tôi nhận ra rằng, Mặc dù tôi đã quen thuộc với khái niệm và những điều cơ bản về kiểm thử đơn vị, nhưng tôi thực sự không biết làm thế nào để thực hiện nó một cách hiệu quả. Bạn có thể giới thiệu một cuốn sách hay về chủ đề này không?
Breton

1
Trên một trình điều khiển hạt nhân mà tôi đã làm việc, tôi đã cấu trúc lại một loạt mã vào một thư viện mà tôi đã liên kết với khai thác kiểm tra chế độ người dùng. Mã cụ thể này là bất khả tri về môi trường, vì vậy nó đủ dễ dàng. Tôi chưa thử, nhưng IRP, như hệ thống tệp và cơ sở dữ liệu, nên có thể giả lập được.
George V. Reilly

1
Với Bochs hoặc QEMU, bạn có thể viết mô phỏng thiết bị của mình để trình điều khiển hạt nhân của bạn nói chuyện.
Zan Lynx

2
@floding, câu trả lời hấp dẫn. Tôi nghĩ tôi sẽ phải đọc một cuốn sách về thử nghiệm đơn vị.
Dan Rosenstark

28

Hầu hết các bài kiểm tra không kiểm tra bất cứ điều gì.
Bạn viết một hàm fileopen () và một hàm duy nhất không thành công nếu tệp không tồn tại và thành công nếu tệp tồn tại. Tuyệt quá! Bây giờ bạn đã kiểm tra xem nó có hoạt động với tên tệp bằng tiếng Trung BIG5 không? trên một chia sẻ NFS? trên vista với tệp trên khóa USB và UAC được BẬT?

Vấn đề là các bài kiểm tra đơn vị được viết bởi cùng một lập trình viên đã viết hàm, với cùng một tập hợp các giả định và với cùng một mức độ kỹ năng. Để thực sự hoạt động, các bài kiểm tra phải được viết bởi người khác, chỉ với các thông số kỹ thuật đã xuất bản mà họ không nhìn thấy mã. - Ở hầu hết các công ty, chỉ cần nhận được thông số kỹ thuật bằng văn bản sẽ là một bước đột phá!

Kiểm thử đơn vị kiểm tra lỗi trong mã của các chức năng riêng lẻ. Chúng có thể làm việc cho các lớp truy cập dữ liệu, thư viện toán học, v.v. nơi các đầu vào / đầu ra đã biết rõ và cấu trúc bên trong phức tạp nhưng đối với nhiều trường hợp, chúng chỉ lãng phí thời gian.
Chúng không thành công khi lỗi là do tương tác giữa các phần mã khác nhau hoặc với Hệ điều hành và người dùng. Các vấn đề như cài đặt DPI cao / thấp làm rối hộp thoại hoặc cài đặt ngôn ngữ nước ngoài hoán đổi dấu '.' và ',' thường không được tìm thấy.


15
Tôi nghĩ câu trả lời này hơi thiếu sót. Kiểm thử đơn vị và kiểm thử chức năng không và không nên giống nhau.
Wedge

4
Một yếu tố bạn đang thiếu là các bài kiểm tra đơn vị không chỉ là một việc làm một lần và làm. Nếu sau này tôi phát hiện ra rằng tôi cần sửa lỗi với fileopen () trên chia sẻ NFS, thì tôi có thể thêm một bài kiểm tra vào bộ kiểm tra của mình cho vấn đề này. Sau đó, khi tôi phát triển thêm trong tương lai, tôi có thử nghiệm hồi quy tại chỗ.
Paul Osborne

2
Nhiều lỗi hình thành các tương tác bên ngoài mã mà các lập trình viên không nghĩ đến và không thể tìm thấy bằng cách đơn giản kiểm tra mã. Một vấn đề phổ biến là máy có cài đặt DPI rất cao / thấp - bạn có thể đơn vị kiểm tra chức năng hộp thoại tùy thích nhưng sẽ không phát hiện ra điều này.
Martin Beckett

5
đó không phải là chức năng của kiểm thử đơn vị và tương tác giữa các phần khác nhau của mã rất có thể kiểm tra đơn vị và thực sự, nếu các phần đó được viết bởi các nhóm riêng biệt, đơn vị kiểm tra mã của bạn dựa trên giao diện được chia sẻ và chế nhạo thành phần của nhóm khác thực hành tốt.
Steven Evers

1
TDD xử lý vấn đề kiểm tra gian lận của "lập trình viên đã viết mã sau đó viết các bài kiểm tra" bằng cách yêu cầu bạn viết các bài kiểm tra trước khi bạn viết mã.
Ophidian


15

Tôi đã tìm thấy rất nhiều nhà phát triển không quan tâm đến thử nghiệm đơn vị. Có vẻ như luôn luôn có rất nhiều công việc với ít thành quả khi bạn bắt đầu. Không ai muốn đăng ký làm thêm và vì vậy họ chống lại. Một khi mọi người bắt đầu, họ thường nhiệt tình gắn bó với nó, nhưng để bắt đầu có thể rất khó.


12

Ngoài vấn đề áp dụng kiểm thử đơn vị, kiểm thử đơn vị không phải lúc nào cũng đáng giá, mặc dù nói chung, tôi nghĩ nó là như vậy, khi được áp dụng đúng cách. Không có gì đặc biệt về các bài kiểm tra đơn vị giúp chúng không bị tổn thương do xây dựng kém.

Kiểm thử đơn vị có chi phí (tạo, bảo trì và chạy) và chỉ đáng giá nếu chúng mang lại lợi ích lớn hơn những chi phí đó. Tạo thử nghiệm là một kỹ năng giống như bất kỳ kỹ năng nào khác, nó đòi hỏi kinh nghiệm và kiến ​​thức cụ thể để thành công. Nếu không có đủ kinh nghiệm, ngay cả các nhà phát triển có kinh nghiệm cũng rất dễ tạo ra các bài kiểm tra đơn vị chất lượng thấp, giá trị thấp và / hoặc chi phí cao không đáng giá. Đặc biệt là do rất khó để đánh giá giá trị của một bài kiểm tra đơn vị.

Ngoài ra, kiểm thử đơn vị chỉ là một cách để cải thiện chất lượng mã, nhưng nó không phải là cách duy nhất. Trong một số trường hợp và với một số nhóm, nó có thể không phải là cách hiệu quả nhất để tăng chất lượng của phần mềm.

Hãy nhớ rằng bỏ nhiều công sức vào kiểm thử đơn vị không đảm bảo chất lượng phần mềm. Và, cũng có thể tạo ra phần mềm có chất lượng cao nhất mà không cần bất kỳ đơn vị kiểm tra nào.


Những gì bạn đang nói là đúng trong các ngôn ngữ được nhập tĩnh. Trong các ngôn ngữ được nhập động, chúng hoàn toàn rất quan trọng. Tôi có nghĩa là mã của bạn gần như được đảm bảo là không có kiểm tra. Tôi nhận thấy đây là một phần lớn lý do tại sao một số người dường như đánh giá cao các bài kiểm tra đơn vị đến vậy.
Bill K

11

Chà, công ty của tôi chưa sử dụng TDD hoặc Unit Testing. Thành thật mà nói, chúng tôi không chắc phải làm như thế nào. Rõ ràng chúng ta có thể làm điều đó đối với các hàm ngu ngốc như CapitalizeString (), v.v., nhưng chúng ta không biết cách thực hiện đối với các hệ thống có độ phức tạp cao với các đối tượng phức tạp. Hơn nữa, hầu hết những người được phỏng vấn đều không có kinh nghiệm hoặc kinh nghiệm hạn chế. Có vẻ như Unit Testing lớn từ đám đông SO, nhưng không đặc biệt lớn trong nhóm công việc có sẵn.

TDD là một chủ đề riêng biệt. Chúng tôi phản đối TDD về mặt đạo đức. Chúng tôi không phải là những lập trình viên cao bồi, nhưng chúng tôi tin rằng nó thúc đẩy sự sáng tạo và tính linh hoạt trong một dự án. Hơn nữa, có lập trình viên đã viết chức năng kiểm thử đơn vị không có ý nghĩa gì. Khi tôi làm điều gì đó, tôi viết mã cho tất cả các trường hợp phức tạp mà tôi có thể nghĩ đến. Điều tôi cần là một bộ não khác để tìm kiếm những thứ mà tôi có thể đã bỏ lỡ. Chúng tôi không có điều đó. Các đội nhỏ và khép kín.

Tóm lại, chúng tôi không tin vào TDD, nhưng chúng tôi muốn Unit Test. Chúng tôi chỉ không có kinh nghiệm để làm như vậy và chúng tôi không thể tìm thấy nó một cách dễ dàng.


Trở lại khi nơi tôi làm việc có đủ người viết mã cho nó, chúng tôi đã lập trình cặp. Tôi thấy nó rất hiệu quả cho một người viết các bài kiểm tra như người kia được mã hóa. Nó cũng dẫn đến những câu hỏi rất thông minh về mã.
Zan Lynx

4
Điểm mà bạn có vẻ còn thiếu ở TDD là bạn viết tất cả các trường hợp cạnh vào bài kiểm tra đơn vị của mình. Đối với mỗi trường hợp, bạn viết một khẳng định trong bài kiểm tra đơn vị của bạn. Sau đó, nếu mã thực của bạn không xác nhận được, bạn biết rằng mã của bạn có lỗi và bạn đã triển khai sai logic của mình. Vì các đơn vị nhỏ và xác nhận của bạn kiểm tra mã cụ thể trong đơn vị, nên dễ dàng xác định lỗi logic của bạn ở đâu. Điều quan trọng là bạn viết các khẳng định của mình trước. Sau đó làm cho mã của bạn vượt qua. Bạn có thể chỉ ra nơi mà quá trình này gây nguy hiểm cho bất cứ điều gì ngoài sự phát triển của lỗi không?
Christopher Parker

2
Để thử và kiểm tra đơn vị mà không viết các bài kiểm tra trước sẽ rất khó. Điều này là do mã của bạn sẽ khó đi vào bộ khai thác thử nghiệm một cách hồi tố. Đây là một trong những lợi ích chính của việc thử nghiệm trước: thiết kế có thể thử nghiệm ngay từ đầu vì các thử nghiệm đã thúc đẩy thiết kế.
Alan Christensen

3
Làm thế nào có thể là bạn "không chắc chắn làm thế nào" để kiểm tra đơn vị nhưng lại tin rằng TDD đánh lừa sự sáng tạo và linh hoạt?
jcorcoran

1
@ Đã 6 năm trôi qua, thật tuyệt nếu biết liệu bạn đã bao giờ giới thiệu thử nghiệm đơn vị (hoặc thậm chí là TDD) và liệu bạn có tiếp tục với nó hay không.
Luke Puplett

11

Có rất nhiều công ty thực sự không làm gì cả theo các phương pháp hay nhất. Không có đánh giá mã, không thử nghiệm đơn vị, không có kế hoạch thử nghiệm, không có gì cả, chỉ bằng cái ghế của họ.

Hãy coi đây là cơ hội để giúp họ sử dụng nền tảng Tích hợp liên tục và phát triển các bài kiểm tra đơn vị! Cách dễ dàng để gây ấn tượng với sức mạnh và tăng chất lượng và độ ổn định của mã của bạn cùng một lúc

Chỉnh sửa: Về lý do, tôi nghĩ rằng họ chỉ đơn giản là không biết về các công cụ hiện tại có giúp CI và kiểm tra đơn vị trở nên dễ dàng một cách phi thường.


Tôi thường ở vị trí mà tôi không có ảnh hưởng gì đến các quyết định chính sách như thế này; Tôi là thượng nghị sĩ cấp dưới đang bị các chủ tịch ủy ban kiểm soát.
jcollum

Phải mất vài phút để khởi động Hudson và viết các bài kiểm tra đơn vị. Nếu các bài kiểm tra đơn vị đã có trong danh sách "CẦN LÀM" của bạn, thì bạn chỉ đang thực hiện công việc của mình. Các ủy ban thường bị ấn tượng bởi các biểu đồ và hình ảnh lạ mắt, vì vậy hãy cho họ xem một số biểu đồ xu hướng đẹp từ Hudson;)
Allen Rice

Vâng! Hãy nghe nó để biết sự thật. Bất chấp thời gian mà các nhà phát triển chúng tôi dành để nghiên cứu về phương pháp hay nhất, nó không phải lúc nào cũng được sử dụng trong thế giới thực. Thật tội nghiệp.
NeedHack

6

Tôi không nghĩ rằng sự lười biếng là nguyên nhân gốc rễ của việc kiểm thử đơn vị tồi. Đối với công ty của tôi, hạn chế về thời gian và thái độ "cứ làm cho xong việc" là những yếu tố cản trở lớn nhất để thực hiện kiểm thử đơn vị. Ngoài ra, những nơi mà hệ thống của chúng tôi bị lỗi có xu hướng nhiều hơn ở cấp độ tích hợp (dịch vụ, truy cập cơ sở dữ liệu, truy vấn phức tạp yêu cầu dữ liệu cụ thể để kiểm tra), không phải ở "cấp độ đơn vị". Những thứ này chỉ khó kiểm tra hơn và nếu bạn hầu như không có đủ thời gian để hoàn thành tính năng, có thể bạn sẽ không có thời gian để thực hiện bất kỳ bài kiểm tra hữu ích nào cùng một lúc.


Điều này là phổ biến. Tôi nghĩ lập luận là nếu bạn nghĩ rằng bạn sẽ thay đổi nó trong tương lai thì bạn nên có một bài kiểm tra để đảm bảo rằng nó hoạt động sau khi nó thay đổi.
jcollum

6

Kiểm thử đơn vị chỉ nên là một phần tự nhiên của quy trình phát triển mã, giống như trình biên dịch.

Tuy nhiên, điều này đòi hỏi phải giáo dục quản lý về lợi ích của thử nghiệm đơn vị. Tuy nhiên, các nhà phát triển nhỏ tuổi có cơ hội tương đối thấp để có được ảnh hưởng như vậy. Do đó, liệu một công ty có phải là người đề xuất thử nghiệm đơn vị hay không phụ thuộc vào việc họ có nhà phát triển hoặc kiến ​​trúc sư cấp cao là người ủng hộ thử nghiệm đơn vị hay không.

Tôi tin rằng đây là câu trả lời cho câu hỏi của bạn "điều gì còn thiếu và tại sao không có nhiều công ty làm thử nghiệm đơn vị hơn" . :-)


1
+1 cho "phải là một phần tự nhiên của quy trình phát triển mã". Mọi nhà phát triển chuyên nghiệp nên thực hiện thử nghiệm đơn vị riêng của mình bất kể quy trình chính thức. Lập luận chính đáng duy nhất về vấn đề này là định nghĩa của một đơn vị .
Dunk

1
@Dunk Nếu bạn không định nghĩa "đơn vị" thì bạn chỉ đang nói rằng "các nhà phát triển chuyên nghiệp nên thực hiện thử nghiệm của riêng họ".
ChrisW

1
@ChrisW - Có, các nhà phát triển chuyên nghiệp nên thực hiện thử nghiệm của riêng họ. Không có lý do gì để một nhà phát triển phải nộp mã mà họ chưa kiểm tra đủ để cảm thấy tự tin rằng nó hoạt động chính xác. Thật không may, điều này dường như là quá nhiều yêu cầu của nhiều nhà phát triển.
Dunk

1
Khi tôi nói định nghĩa của một đơn vị là một lập luận chính đáng, tôi đang nói về mức độ chi tiết của một đơn vị. Nó là một lớp học? Nó có phải là một tập hợp các lớp không? Nó là một thành phần? Tôi nghĩ rằng kiểm tra đơn vị cấp độ lớp (với một số ngoại lệ) tốn kém nhiều hơn lợi ích của nó và dẫn đến nhiều bài kiểm tra vô nghĩa ...
Dunk

mà những người khác đã chỉ ra trong chủ đề này. Trong khi đó, nếu người ta xác định một tập hợp các lớp hoạt động cùng nhau như một đơn vị thì bạn vẫn có thể thực hiện kiểm thử tự động và các bài kiểm tra của bạn thường có ý nghĩa hơn vì chúng có thể tập trung nhiều hơn vào chức năng được yêu cầu ở mức cao hơn.
Dunk

5

Nó có thể là sự kết hợp của một vài điều bạn đã đề cập. Khó đo lường tiết kiệm chi phí TDD của nó. Nếu bạn muốn thuê ngoài CNTT của mình, bạn có thể hiển thị số tiền bạn phải trả mỗi năm cho những người bạn có trong nhân viên so với chi phí hợp đồng; nó rất cụ thể. Làm thế nào để bạn nói, "Ồ, thử nghiệm này đã gặp một lỗi khiến tôi phải mất 4 giờ để gỡ lỗi và sửa chữa ..."?


Làm thế quái nào mà bạn có thể đoán được lỗi sẽ mất bao lâu để gỡ lỗi và sửa chữa. Nói chung, gỡ lỗi ngẫu nhiên hơn so với kinh nghiệm của tôi - tôi tình cờ có ý tưởng vấn đề nằm ở đâu hoặc tôi không.
Dominic Rodger

1
Vâng, đó là lý do tại sao tôi nói rất khó để định lượng lợi ích của việc thử nghiệm.
Ovi Tisler 17/02/09

5

Lý do một số nơi không sử dụng nó đơn giản là vì phải mất rất nhiều công sức để bắt đầu và tiếp tục. Thực tế là việc viết các bài kiểm tra đơn vị mất nhiều thời gian như việc viết chức năng thực tế có vẻ như đối với một số nhà quản lý như bạn đang cắt giảm một nửa năng suất của nhà phát triển.

Trên hết, bạn xây dựng đội (hoặc ai đó) cần đặt cơ sở hạ tầng tại chỗ và duy trì nó.

Và như Alan nói, rất nhiều nơi chỉ đơn giản là không sử dụng các phương pháp hay nhất - họ chỉ muốn thấy một cái gì đó hữu hình.


5

Từ những gì tôi đã thấy, rất nhiều công ty có cơ sở mã khổng lồ, có tính kết hợp cao mà thực tế không thể kiểm tra đơn vị. Chúng cũng không có các yêu cầu có thể kiểm tra tốt, vì vậy các bài kiểm tra đơn vị sẽ kiểm tra dựa trên các yêu cầu trên thực tế "như được xây dựng".


5

Tôi nghĩ rằng lập trình viên phải bắt đầu làm điều đó. Một vài thử nghiệm đơn giản để bắt đầu rất dễ được coi là một phần của quá trình phát triển.

Một cái gì đó giống như kiểm tra đơn vị hầu như luôn luôn cần thiết để gỡ lỗi nhanh chóng. Chỉ cần giải thích việc khởi chạy thử nghiệm nhanh hơn bao nhiêu so với việc sắp xếp đầu vào chính xác, đặt điểm ngắt của trình gỡ lỗi, khởi chạy ứng dụng, v.v.

Ghi lại bài kiểm tra vào mã của bạn. Chỉ cần đặt một bình luận giải thích vị trí của bài kiểm tra và cách chạy nó. Các lập trình viên tương lai sẽ thấy nó và hy vọng thử nghiệm sẽ lan rộng!


4

Kiểm thử đơn vị là một trong những thuật ngữ hộp đen mà hầu hết mọi người đã nghe, nhưng không biết chính xác điều gì tạo nên kiểm thử đơn vị, bắt đầu từ đâu, viết chúng như thế nào, thực sự chạy kiểm thử như thế nào, chính xác thì chúng nên kiểm thử điều gì, v.v. . Vân vân.

Trong nhiều trường hợp, nhà phát triển không chắc chắn sẽ dễ dàng loại bỏ chúng là không cần thiết hoặc một số đóng băng mà chỉ "nhà phát triển cấp doanh nghiệp" mới cần.


4

Tôi là một người rất yêu thích các bài kiểm tra đơn vị và tôi cũng là đối tác trong một công ty thực hiện các dự án phát triển hợp đồng cho nhiều loại khách hàng khác nhau. Trong một tháng, chúng tôi sẽ chạm vào 3-4 dự án khác nhau với quy mô khác nhau.

Nếu một dự án dường như chỉ là một kết quả, tôi sẽ không đầu tư nhiều vào thử nghiệm đơn vị vì thử nghiệm đơn vị đó không mang lại lợi ích cho doanh nghiệp của tôi. Trong các loại dự án đó, tôi sẽ kiểm tra đơn vị những thứ mà tôi không chắc chắn / không quen thuộc hoặc có thể thay đổi thường xuyên (chẳng hạn như trình phân tích cú pháp cho nguồn dữ liệu mà tôi không kiểm soát.)

Trong khi nếu tôi đang xây dựng thứ gì đó mà tôi biết là sẽ có tuổi thọ cao, là một công việc lớn hơn, mà tôi sẽ làm việc với nhiều lần lặp lại hoặc sẽ có tác động lớn đến khách hàng của tôi nếu xảy ra lỗi , Tôi sẽ đầu tư vào thử nghiệm đơn vị nhiều hơn. Một lần nữa ưu tiên của các bài kiểm tra xoay quanh mã không chắc chắn / không quen thuộc / thay đổi.

Tôi nghĩ các bài kiểm tra đơn vị phải xoay quanh mức độ phức tạp của một nhiệm vụ, cũng như liệu chúng có thành công hay không. Không có ý nghĩa gì khi viết thêm mã sẽ không được sử dụng.


3

Theo kinh nghiệm của tôi, nó thực sự phụ thuộc vào phần mềm bạn đang viết. Tôi nhận thấy việc viết các bài kiểm tra đơn vị cho một giao diện người dùng là vô cùng khó. Tôi chỉ sử dụng các bài kiểm tra đơn vị cho các phần của hệ thống có xác định vào / ra.


Tôi đồng ý. Nếu bạn sử dụng model / view / controller thì việc kiểm tra đơn vị mô hình và bộ điều khiển sẽ rất hợp lý. Giao diện người dùng hầu như luôn được kiểm tra tốt nhất bởi con người.
Zan Lynx

3

Tôi bỏ lỡ thử nghiệm đơn vị - nó chỉ làm cho cuộc sống dễ dàng hơn.

Đó không phải thực sự lý do đủ để một công ty áp dụng thử nghiệm đơn vị.

Một lý do đủ có thể là "rẻ hơn" (và / hoặc, "tốt hơn"): điều này không dễ chứng minh về thử nghiệm đơn vị.

Lý do chính đáng duy nhất có thể là "viết bài kiểm tra đơn vị là cách sử dụng tốt nhất thời gian của các nhà phát triển", điều này thực sự khó chứng minh IMO: và nó có thể đúng ở một số nơi, đối với một số phần mềm, với một số nhà phát triển và không đúng ở một số nơi khác.

Có rất nhiều nhà phát triển không nghĩ rằng thế giới của các bài kiểm tra đơn vị: bao gồm một số người nghĩ rằng các hình thức kiểm thử khác (ví dụ: kiểm tra tích hợp / chức năng tự động) có thể rẻ hơn và có giá trị hơn, chẳng hạn như tôi có phải là nhà phát triển duy nhất không ' t thích các bài kiểm tra đơn vị?


3

Tất nhiên, trong thế giới lý tưởng, bạn không thể phản đối việc có một bài kiểm tra đơn vị.

Tuy nhiên, bạn có viết một bài kiểm tra đơn vị hay không phụ thuộc vào một số điều:

  • Phần mềm sẽ được sử dụng như thế nào. Nếu bạn đang viết phần mềm cho riêng mình, bạn có viết các bài kiểm tra đơn vị không? Chắc là không. Nếu bạn đang viết phần mềm đóng gói sẵn để bán thương mại, có lẽ là có.

  • Có bao nhiêu người duy trì mã .... nếu chỉ có bạn, thì bạn có thể biết rõ điều đó để đủ tự tin sau khi thực hiện thay đổi rằng việc chạy nhanh qua mã là đủ để đảm bảo không có gì bị hỏng. Nếu những người khác không viết mã ban đầu phải duy trì nó thì một bài kiểm tra đơn vị sẽ giúp họ tin tưởng rằng khi họ cập nhật mã để sửa lỗi lớn (điều đó rõ ràng là không được nắm bắt trong bài kiểm tra đơn vị!), Họ không bị hỏng bất cứ điều gì .

  • độ phức tạp của mã: chỉ mã kiểm tra cần kiểm tra. Phương pháp gán biến một dòng không cần thử nghiệm. Phương thức 50 dòng với nhiều đường dẫn thực thi có thể làm được.

  • Cân nhắc thương mại thương mại thực tế: Thực tế là việc viết các bài kiểm tra đơn vị mất nhiều thời gian hơn là không làm như vậy. Nếu bạn đang viết phần mềm nguyên mẫu, có một tương lai thương mại không chắc chắn, thì việc có mã nhanh chóng, ngay bây giờ, nó hoạt động đủ tốt so với việc có mã được kiểm tra đơn vị trong 2 tuần sẽ hoạt động tốt hơn. Đôi khi phải trả tiền để tìm ra nhanh chóng (nhu cầu của người tiêu dùng) nếu phần mềm sẽ có thời hạn sử dụng ngắn và chuyển sang dự án tiếp theo.

và như những người khác đã chỉ ra, một bài kiểm tra chỉ tốt như người đã viết nó.


3

Lý do chính là nhiều nhà phát triển và nhà quản lý phát triển không có manh mối rằng các bài kiểm tra đơn vị tồn tại hoặc cách sử dụng chúng.

Lý do thứ hai là các bài kiểm tra đơn vị chỉ có thể được sử dụng (theo cách hợp lý) với mã đã đáp ứng một số tiêu chuẩn chất lượng. Rất có thể, một số cơ sở mã hiện có không thuộc danh mục đó.

Lý do thứ ba là sự lười biếng và / hoặc ham rẻ.


3

Bởi vì các bài kiểm tra đơn vị chỉ hữu ích nếu bạn viết mã có thể kiểm tra. Và viết mã có thể kiểm tra được là một việc khó. Và mọi người lười biếng và / hoặc rẻ tiền.

EDIT: sắc thái "lười biếng" là "lười biếng và / hoặc rẻ tiền"; trong một số trường hợp hiếm hoi, mọi người thực sự có kỹ năng, năng lực và ý chí để viết các bài kiểm tra, nhưng họ có việc khác để làm điều đó ảnh hưởng trực tiếp hơn đến điểm mấu chốt.


Tôi ủng hộ điều này, ngoại trừ tôi không nghĩ rằng mọi người 'lười biếng'. Hãy nghĩ 'lập trình', tức là 'ngôn ngữ lập trình phổ biến của bạn và các công cụ, tài liệu, đào tạo, quy trình làm việc, nội dung liên quan' không bao giờ được thiết kế theo cách có thể dễ dàng viết mã có thể kiểm tra. Vì vậy, để viết mã có thể kiểm tra, bạn luôn phải đi thêm một dặm. Không có phần thưởng nào 'vì nó đã hoạt động' vào thời điểm đó (để việc viết thử nghiệm trước, viết mã sau, TDD, có ý nghĩa thực tế). Hãy nghĩ rằng đây là một khuynh hướng nhận thức không chỉ đánh lừa các lập trình viên hiện tại, mà còn lừa các tác giả của các công cụ 'lập trình' mà các lập trình viên hiện đang xây dựng.
n611x007

1
Vâng, chắc chắn rồi, đôi khi mọi người rẻ tiền / hỏng việc / có những thứ tốt hơn để làm (hoặc như chúng tôi nói một cách lịch sự là "có sự đánh đổi để thực hiện.") Đã được chỉnh sửa để phản ánh điều đó. (Tôi sắp sửa jockingly thêm rằng, bên cạnh đó, hầu hết các mã là vô ích, vì vậy thử nghiệm nó là vô dụng, quá, nhưng đó chỉ là thiếu ngủ nói chuyện;))
phtrivier

2

Tôi nghĩ một phần của vấn đề là các nhà phát triển đang mong đợi những người kinh doanh có cùng một bộ giá trị và thực sự quan tâm đến câu trả lời cho "chúng ta có nên thử nghiệm đơn vị hay không?". Chúng tôi không nhận được sự chấp thuận trước từ doanh nghiệp để sử dụng một ngôn ngữ cấp cao hơn là ngôn ngữ hợp ngữ - đó thường là cách hợp lý để hoàn thành công việc.

Vấn đề là, chúng tôi là những người duy nhất đủ điều kiện để thực hiện cuộc gọi (không có nghĩa là tất cả chúng tôi đều có cùng kiến ​​thức về chủ đề này). Hơn nữa, ngay cả khi nhóm của bạn không thực hiện kiểm tra đơn vị (hoặc đặt tên-phương-pháp-trong-ngày) của bạn, thì điều đó thường không có nghĩa là bạn không thể làm điều đó.

Sự thật là chúng tôi không thể thực sự chứng minh ROI trên hầu hết các công việc chúng tôi làm ở mức độ chi tiết quá tốt. Tại sao thử nghiệm đơn vị được tổ chức theo tiêu chuẩn chứng minh bất hợp lý / không điển hình này nằm ngoài tôi ...


Tuy nhiên, bạn cần có sự tham gia của ban quản lý vì bạn phải đưa các đồng phát triển của mình vào cuộc và cách tốt nhất để điều đó xảy ra là yêu cầu từ trên xuống.
John

2

Mọi người lười biếng và chỉ chấp nhận sự thay đổi khi bị bắt buộc.


2

2 xu của tôi:

  • Nó đòi hỏi một số giáo dục và kỷ luật, nhưng sinh viên mới tốt nghiệp đã có kiến ​​thức phù hợp.
  • Chi phí kiểm tra có thể được giảm bớt với các công cụ tốt hơn và điều này cũng đang xảy ra (tái cấu trúc, v.v.)

Vì vậy, đó chỉ là vấn đề thời gian.

Có cuộc tranh luận Martin-Coplien, trong đó Bob Martin khẳng định rằng:

"Ngày nay, việc một nhà phát triển gửi một dòng mã mà anh ta chưa thực thi trong một thử nghiệm đơn vị là vô trách nhiệm."

[ http://www.infoq.com/interviews/coplien-martin-tdd]


2
Tôi không tin vào sự tồn tại của một hệ thống phức tạp trong thế giới thực, trong đó mọi dòng mã đều được bao phủ bởi các bài kiểm tra đơn vị.
quant_dev

2

Nếu bạn muốn bán cho mọi người đang thử nghiệm, hãy làm như sau:

  1. Viết một loạt các bài kiểm tra.
  2. Thông báo cho các nhà phát triển khác thay đổi mã và không đạt (các) bài kiểm tra của bạn.
  3. Họ sẽ sửa mã của họ.
  4. Bây giờ bạn có thể phát hành mà không có những lỗi cụ thể.

Ngay cả một người quản lý cũng có thể hiểu điều này.


Kiểm tra đơn vị sẽ không làm cho bản phát hành của bạn không có lỗi. Nó có thể làm giảm số lượng lỗi, nhưng rất khó để đo lường số lượng lỗi đã / không / đã sản xuất do thử nghiệm.
Tom

Tôi không biết rằng ban lãnh đạo sẽ hài lòng với việc ai đó viết một loạt các bài kiểm tra khi họ có thể mã hóa các chức năng mới. Nếu họ không có TDD, bạn có thể sẽ gặp rắc rối khi viết các bài kiểm tra để bao hàm mã bạn không viết.
jcollum

@jcollum Như thường lệ, nó phụ thuộc vào tỷ lệ chi phí / lợi nhuận.
quant_dev

2

Các công ty không thực hiện kiểm thử đơn vị, vì lý do tương tự là nhiều trang web được viết kém - thiếu hiểu biết và mọi người bám vào thói quen cũ. Tại công ty của tôi, kể từ khi chúng tôi bắt đầu thử nghiệm đơn vị (với Nunit và Typemock ), chúng tôi đạt được độ phủ mã cao hơn và phát hành phần mềm ra thị trường trong thời gian ngắn hơn.


2

Giống như hầu hết các ý tưởng hay, việc áp dụng liên quan nhiều đến sự phụ thuộc vào đường lối tổ chức hơn là chất lượng của ý tưởng.

Trong hầu hết các công ty đã vận chuyển sản phẩm, một bộ phận QA đáng kể đã được tạo ra với người đứng đầu QA cấp cao. Kiểm tra là nhiệm vụ của nhóm QA.

Nhóm QA không có khả năng viết mã kiểm tra đơn vị vì công ty thường không nhân viên nhóm QA với những người viết mã công việc nặng nhọc của mình.

Nhóm lập trình không muốn viết mã thử nghiệm vì nó tạo ra xung đột với nhóm QA.

Tôi đã thấy nhiều sự quan tâm và áp dụng Unit Testing trong các nhóm mà QA chưa được tách thành một chức năng công việc riêng biệt


1

Đơn giản, nó tốn tiền để viết và cập nhật các bài kiểm tra đơn vị. Hầu hết các phần mềm trước đây của các công ty không có bài kiểm tra đơn vị và sẽ tốn quá nhiều chi phí để viết. Vì vậy, họ không làm điều đó và nó thêm thời gian vào quá trình phát triển nên họ cũng không thêm nó vào các tính năng mới.


Bạn nên đọc các liên kết về ROI.
jcollum

1

Hầu hết các công ty đều vô dụng. Rõ ràng không phải là người mà bạn (hoặc tôi) làm việc.


Điều này không cung cấp câu trả lời cho câu hỏi. Để phê bình hoặc yêu cầu làm rõ từ tác giả, hãy để lại bình luận bên dưới bài đăng của họ.
AlexVogel

H: "Tại sao nhiều công ty không thực hiện [thử nghiệm đơn vị] hơn?" A: "Bởi vì hầu hết các công ty đều vô dụng." Âm thanh giống như một câu trả lời cho tôi ...
Roger Lipscombe
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.