Sự khác biệt về thời gian giữa phát triển với các bài kiểm tra đơn vị so với không có bài kiểm tra nào

132

Tôi là một nhà phát triển solo với môi trường làm việc khá hạn chế về thời gian trong đó thời gian phát triển thường dao động từ 1-4 tuần cho mỗi dự án, tùy thuộc vào yêu cầu, mức độ khẩn cấp hoặc cả hai. Tại bất kỳ thời điểm nào tôi cũng xử lý khoảng 3-4 dự án, một số có các mốc thời gian chồng chéo với nhau.

Dự kiến, chất lượng mã bị. Tôi cũng không có thử nghiệm chính thức; nó thường đi xuống hệ thống cho đến khi nó bị hỏng. Kết quả là, một số lượng đáng kể lỗi thoát khỏi sản xuất, mà tôi phải sửa và lần lượt đặt lại các dự án khác của tôi.

Đây là nơi thử nghiệm đơn vị đến. Khi được thực hiện đúng, nó sẽ giữ các lỗi, chứ đừng nói đến những lỗi thoát khỏi sản xuất, đến mức tối thiểu. Mặt khác, các bài kiểm tra viết có thể mất một lượng thời gian đáng kể, điều này không tốt cho các dự án bị hạn chế về thời gian như của tôi.

Câu hỏi là, bao nhiêu sự khác biệt về thời gian sẽ viết mã được kiểm tra đơn vị so với mã chưa được kiểm tra và mức chênh lệch thời gian đó như thế nào khi phạm vi dự án mở rộng?

unit-testing productivity solo-development

— Doanh thu
nguồn

Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .

— maple_shaft

8

Bạn đang giải quyết vấn đề sai. Bạn quá bận rộn và dường như không có hỗ trợ quản lý dự án. Bạn đang ước tính nỗ lực dự án? Bạn có dành 20% thời gian để sửa lỗi, họp và các tác vụ không mã hóa khác không? Bạn làm thêm bao nhiêu giờ?

— Tony Enni

20

Bạn có nhận ra rằng về cơ bản bạn đang nói "Tôi có thời gian để làm điều đó hai lần, nhưng không có thời gian để làm điều đó một lần đúng cách."?

— RubberDuck

5

@RubberDuck thực sự có một điểm trong đường cong độ phức tạp của dự án được đo là Thời gian để viết so với thời gian để kiểm tra, trong đó "Vặn nó hai lần", mất ít thời gian hơn so với "Viết và kiểm tra". Tôi nghĩ rằng nó có thể là một nơi nào đó trong khu vực của một bash oneliner.

— Lyndon White

Một lần, các nhà phát triển đã nhận được quà và cảm ơn khi một dự án bị hủy bỏ. Tôi đã chỉ ra rằng chúng tôi có thể có năng suất cao hơn nữa nếu chúng tôi biết rằng sản phẩm sẽ không được giao. Vì vậy, đây là một trường hợp phát triển mà không thử nghiệm sẽ là lợi thế.

— JDługosz

149

Bạn càng kiểm tra sau, chi phí để viết bài kiểm tra càng nhiều.

Một lỗi tồn tại càng lâu thì càng tốn kém để sửa chữa.

Luật lợi nhuận giảm dần đảm bảo bạn có thể kiểm tra bản thân vào quên lãng để cố gắng đảm bảo không có lỗi.

Phật dạy trí tuệ của con đường trung đạo. Các xét nghiệm đều tốt. Có một điều như là quá nhiều của một điều tốt. Chìa khóa là có thể cho biết khi bạn mất cân bằng.

Mỗi dòng mã bạn viết mà không có bài kiểm tra sẽ có chi phí lớn hơn đáng kể để thêm bài kiểm tra muộn hơn so với việc bạn đã viết bài kiểm tra trước khi viết mã.

Mỗi dòng mã không có kiểm tra sẽ khó gỡ lỗi hoặc viết lại hơn đáng kể.

Mỗi bài kiểm tra bạn viết sẽ mất thời gian.

Mỗi lỗi sẽ mất thời gian để sửa chữa.

Các tín đồ sẽ bảo bạn không viết một dòng mã nào mà không viết bài kiểm tra thất bại trước. Bài kiểm tra đảm bảo bạn sẽ có được hành vi mà bạn mong đợi. Nó cho phép bạn thay đổi mã nhanh chóng mà không lo ảnh hưởng đến phần còn lại của hệ thống vì thử nghiệm chứng minh hành vi là như nhau.

Bạn phải cân nhắc tất cả những điều đó với thực tế là các bài kiểm tra không thêm tính năng. Mã sản xuất thêm tính năng. Và các tính năng là những gì trả hóa đơn.

Nói một cách thực tế, tôi thêm tất cả các bài kiểm tra mà tôi có thể làm được. Tôi bỏ qua ý kiến ủng hộ xem các bài kiểm tra. Tôi thậm chí không tin tưởng mã để làm những gì tôi nghĩ nó làm. Tôi tin tưởng các bài kiểm tra. Nhưng tôi đã biết ném mary thỉnh thoảng và nhận được may mắn.

Tuy nhiên, nhiều lập trình viên thành công không làm TDD. Điều đó không có nghĩa là họ không kiểm tra. Họ chỉ khăng khăng khẳng định rằng mọi dòng mã đều có kiểm tra tự động chống lại nó. Ngay cả chú Bob cũng thừa nhận ông không kiểm tra giao diện người dùng của mình. Ông cũng khẳng định bạn di chuyển tất cả logic ra khỏi UI.

Như một phép ẩn dụ bóng đá (đó là bóng đá Mỹ) TDD là một trò chơi mặt đất tốt. Hướng dẫn chỉ kiểm tra nơi bạn viết một đống mã và hy vọng nó hoạt động là một trò chơi vượt qua. Bạn có thể giỏi một trong hai. Sự nghiệp của bạn sẽ không tạo ra các trận playoff trừ khi bạn có thể làm cả hai. Nó sẽ không tạo ra superbowl cho đến khi bạn biết khi nào nên chọn từng cái. Nhưng nếu bạn cần một người nũng nịu theo một hướng cụ thể: các quan chức gọi điện chống lại tôi thường xuyên hơn khi tôi đi qua.

Nếu bạn muốn thử TDD, tôi khuyên bạn nên thực hành trước khi thử thực hiện tại nơi làm việc. TDD thực hiện một nửa, nửa vời và nửa khẳng định là lý do lớn khiến một số người không tôn trọng nó. Nó giống như rót một ly nước vào ly khác. Nếu bạn không cam kết và thực hiện nó một cách nhanh chóng và hoàn toàn, bạn sẽ bị chảy nước khắp bàn.

— candied_orange
nguồn

68

Có một điều giống như quá nhiều điều tốt đẹp Cả bạn và Phật đều không kiểm tra cookie của bà tôi :-)

— Pierre Arlaud

3

@NickAlexeev Tôi thích biểu đồ đó. Một điều nó không chỉ ra là các bài kiểm tra đơn vị (thường được tự động hóa) thực sự tốt trong việc tìm ra lỗi khi mã được sửa đổi. Tôi rất muốn thấy rằng tách ra thành "lỗi được tìm thấy trước khi phát hành" và "lỗi được tìm thấy sau khi phát hành". Các bài kiểm tra đơn vị là dòng phòng thủ tốt nhất chống lại hồi quy.

— corsiKa

3

Tôi nghĩ rằng đây là một câu trả lời rất cân bằng: thử nghiệm mọi thứ, ngay cả những thứ tầm thường, có thể là một sự lãng phí thời gian. Có các bài kiểm tra tốt cho các phần phức tạp có thể dễ dàng phá vỡ có thể thực sự có ích. Tôi vừa hoàn thành việc chuyển một dự án nhỏ nhưng không tầm thường từ Java sang C ++. Lần đầu tiên tôi chuyển các bài kiểm tra và điều này hướng dẫn tôi thiết lập toàn bộ triển khai C ++. Khi tất cả các bài kiểm tra đều có màu xanh, chỉ có một vài lớp dễ dàng hơn cần được chuyển và nó đã diễn ra khá suôn sẻ. Mặt khác, tôi không có các thử nghiệm cho tất cả các mã: điều này sẽ kéo dài việc thực hiện ít nhất 3, 4 ngày với mức tăng ít.

— Giorgio

5

Một chút bất đồng với điều này: 'Bạn phải cân nhắc tất cả những điều đó với thực tế là các bài kiểm tra không thêm tính năng. Mã bổ sung các tính năng. Và các tính năng là những gì trả hóa đơn. ' Tôi thực sự muốn đề xuất rằng đó không phải là các tính năng thanh toán hóa đơn - đó là các tính năng hoạt động. (hoặc mọi người có được trả tiền cho việc giao hàng không làm việc không?). Phần còn lại của câu trả lời tôi hoàn toàn đồng ý với.

— Tony Suffolk 66

6

@ TonySuffolk66 bạn đã đúng, đó là các tính năng hoạt động thanh toán hóa đơn (cấm bán hàng flimflam) Tuy nhiên, mọi người đã tạo ra các tính năng làm việc từ lâu trước khi TDD là một điều. Họ sẽ rất lâu sau khi nó biến mất. Hãy nhớ rằng, TDD là một cách kiểm tra kỷ luật. Đó không phải là cách kiểm tra kỷ luật duy nhất.

— candied_orange

112

Tôi đồng ý với các câu trả lời còn lại nhưng để trả lời câu hỏi chênh lệch thời gian trực tiếp là gì.

Roy Osherove trong cuốn sách Nghệ thuật thử nghiệm đơn vị, Ấn bản thứ hai trang 200 đã thực hiện một nghiên cứu tình huống về việc thực hiện các dự án có quy mô tương tự với các nhóm tương tự (khôn ngoan về kỹ năng) cho hai khách hàng khác nhau trong khi một nhóm khác không thử nghiệm.

Kết quả của anh ấy là như vậy:

Vì vậy, khi kết thúc một dự án, bạn nhận được cả thời gian ít hơn và ít lỗi hơn. Điều này tất nhiên phụ thuộc vào mức độ lớn của một dự án.

— Aki K
nguồn

32

Kích thước mẫu quá nhỏ để coi điều này là khoa học nhưng tôi nghĩ nó đại diện cho những gì nhiều người trải nghiệm. Tôi thấy rằng khi tôi làm TDD, phần lớn thời gian dành cho việc sửa các lỗi khiến bài kiểm tra đơn vị của tôi không thành công, không tự viết bài kiểm tra. Đó không thực sự là thêm thời gian, chỉ thay đổi khi bạn tìm và khắc phục những vấn đề đó. Bất kỳ thời gian thêm thực sự là trong việc khắc phục các vấn đề mà bạn sẽ không tìm thấy, ít nhất là không phải trong vòng đầu tiên.

— JimmyJames

7

@JimmyJames Đây là một nghiên cứu điển hình, được sử dụng rộng rãi trong kinh doanh và rất nhiều trong khoa học khi chưa thể (chưa) có thể thực hiện một thử nghiệm tái sản xuất quy mô lớn. Có những tạp chí tâm lý đầy đủ về họ. "Không khoa học" không phải là từ đúng.

— djechlin

25

Tại sao tôi nghĩ rằng nếu kết quả của nghiên cứu trường hợp đó đã cho thấy điều ngược lại, nó sẽ không được đưa vào cuốn sách ;-)?

— Doc Brown

11

@DocBrown Tôi tự hỏi có bao nhiêu nghiên cứu trường hợp đã được thực hiện và loại bỏ trước khi họ tìm thấy một câu trả lời đúng :-)

— gbjbaanb

6

@JimmyJames gần như chắc chắn đủ điều kiện là khoa học. Hơn nữa, một nhà khoa học khác có thể đọc nghiên cứu điển hình "n = 1" này, quyết định rằng nó đáng để nghiên cứu thêm, sau đó thực hiện một nghiên cứu thống kê quy mô lớn hoặc thậm chí là một thử nghiệm được kiểm soát theo chiều dọc và xác nhận hoặc từ chối nó. Đó chính xác là cách khoa học hoạt động. Đó là cách nó hoạt động. bạn có thể đọc thêm về cách khoa học hoạt động ở đây en.wikipedia.org/wiki/Sellectific_method

— djechlin

30

Chỉ có một nghiên cứu mà tôi biết là đã nghiên cứu điều này trong "môi trường thực tế": Hiện thực hóa cải tiến chất lượng thông qua phát triển dựa trên thử nghiệm: kết quả và kinh nghiệm của bốn nhóm công nghiệp . Thật tốn kém khi làm điều này một cách hợp lý, vì về cơ bản, điều đó có nghĩa là bạn cần phát triển cùng một phần mềm hai lần (hoặc lý tưởng hơn là thường xuyên hơn) với các nhóm tương tự, và sau đó ném tất cả trừ một.

Kết quả của nghiên cứu là sự gia tăng thời gian phát triển giữa 15%, 35% (không ở gần con số 2x thường được các nhà phê bình TDD trích dẫn) và giảm mật độ khiếm khuyết trước khi phát hành từ 40% 90% 90% (! ). Lưu ý rằng tất cả các nhóm không có kinh nghiệm trước với TDD, vì vậy người ta có thể cho rằng sự gia tăng thời gian ít nhất có thể được quy cho việc học, và do đó sẽ còn đi xa hơn theo thời gian, nhưng điều này không được đánh giá bởi nghiên cứu.

Lưu ý rằng nghiên cứu này là về TDD, và câu hỏi của bạn là về kiểm tra đơn vị, đó là những điều rất khác nhau, nhưng đó là điều gần nhất tôi có thể tìm thấy.

— Jörg W Găngag
nguồn

1

Sẽ thú vị hơn khi áp đặt các ràng buộc bổ sung: không có trạng thái có thể thay đổi, theo RẮN, gõ tĩnh, không phụ thuộc null, chức năng trên mệnh lệnh, hợp đồng mã, phân tích tĩnh, tái cấu trúc tự động, không chứa container IoC (nhưng DI), v.v. các bài kiểm tra đơn vị sẽ giảm (nhưng không biến mất).

— Den

24

Hoàn thành tốt, phát triển với các bài kiểm tra đơn vị có thể nhanh hơn ngay cả khi không xem xét lợi ích của các lỗi bổ sung bị bắt.

Thực tế là, tôi không phải là một lập trình viên đủ giỏi để đơn giản là mã của tôi hoạt động ngay khi nó được biên dịch. Khi tôi viết / sửa đổi mã, tôi phải chạy mã để đảm bảo nó làm những gì tôi nghĩ nó làm. Tại một dự án, điều này có xu hướng kết thúc giống như:

Sửa đổi mã
Biên dịch ứng dụng
Chạy ứng dụng
Đăng nhập vào ứng dụng
Mở một cửa sổ
Chọn một mục từ cửa sổ đó để mở một cửa sổ khác
Đặt một số điều khiển trong cửa sổ đó và nhấp vào nút

Và tất nhiên, sau tất cả những điều đó, thường phải mất một vài chuyến đi khứ hồi để thực sự làm cho đúng.

Bây giờ, nếu tôi đang sử dụng bài kiểm tra đơn vị thì sao? Sau đó, quá trình này trông giống như:

Viết một bài kiểm tra
Chạy thử nghiệm, đảm bảo nó thất bại theo cách dự kiến
Viết mã
Chạy thử nghiệm một lần nữa, thấy rằng nó vượt qua

Điều này là dễ dàng hơn và nhanh hơn sau đó kiểm tra ứng dụng bằng tay. Tôi vẫn phải chạy ứng dụng theo cách thủ công (vì vậy tôi trông không ngớ ngẩn khi tôi làm việc mà hoàn toàn không hoạt động), nhưng đối với hầu hết các phần tôi đã làm việc hết sức, và tôi chỉ kiểm chứng tại thời điểm đó Tôi thực sự thường làm cho vòng lặp này thậm chí chặt chẽ hơn bằng cách sử dụng một chương trình tự động chạy lại các bài kiểm tra của tôi khi tôi lưu.

Tuy nhiên, điều này phụ thuộc vào việc làm việc trong một cơ sở mã thân thiện với thử nghiệm. Nhiều dự án, ngay cả những dự án có nhiều bài kiểm tra, làm cho bài kiểm tra viết khó khăn. Nhưng nếu bạn làm việc với nó, bạn có thể có một cơ sở mã dễ kiểm tra hơn thông qua kiểm tra tự động so với kiểm tra thủ công. Là một phần thưởng, bạn có thể giữ các bài kiểm tra tự động xung quanh và tiếp tục chạy chúng để ngăn hồi quy.

— Winston Ewert
nguồn

1

Và sử dụng một cái gì đó như nCrunch có thể cắt các bước 2 và 4, làm cho vòng phản hồi thậm chí còn chặt chẽ hơn.

— Euphoric

"Tôi vẫn phải tự chạy ứng dụng" là một quan sát quan trọng, IMHO. Không có đạn bạc.

— Den

20

Mặc dù đã có rất nhiều câu trả lời, nhưng chúng hơi lặp đi lặp lại và tôi muốn thực hiện một chiến thuật khác. Các thử nghiệm đơn vị có giá trị, nếu và chỉ khi , chúng làm tăng giá trị kinh doanh . Thử nghiệm để kiểm tra vì lợi ích (kiểm tra tầm thường hoặc kiểm tra tautological) hoặc để đạt một số liệu tùy ý (như phạm vi bảo hiểm mã), là lập trình sùng bái hàng hóa.

Các bài kiểm tra rất tốn kém, không chỉ trong thời gian cần thiết để viết chúng, mà còn bảo trì. Chúng phải được giữ đồng bộ với mã mà chúng kiểm tra hoặc chúng không có giá trị. Chưa kể chi phí thời gian để chạy chúng trên mỗi thay đổi. Đó không phải là một công cụ thỏa thuận (hoặc một lý do để không làm những việc thực sự cần thiết), nhưng cần phải được phân tích để phân tích lợi ích chi phí.

Vì vậy, câu hỏi cần đặt ra khi quyết định có hay không (hoặc loại nào) để kiểm tra chức năng / phương thức, hãy tự hỏi mình 'tôi đang tạo / bảo vệ giá trị người dùng cuối nào với thử nghiệm này?'. Nếu bạn không thể trả lời câu hỏi đó, ngoài đầu bạn , thì bài kiểm tra đó có thể không xứng đáng với chi phí viết / duy trì. (hoặc bạn không hiểu được vấn đề tên miền, mà là một waaaay vấn đề lớn hơn một thiếu kiểm tra).

http://rbcs-us.com/document/Why-Most-Unit-Testing-is-Waste.pdf

— Jared Smith
nguồn

1

Tôi không quá quen thuộc với BDD nhưng sẽ đoán rằng nó hoạt động ở mức độ chi tiết hơi thô hơn so với mức phương thức / hàm và có thể có kết nối ít hơn với giá trị người dùng.

— Jared Smith

1

Liên quan

— Robbie Dee

9

"Thử nghiệm để kiểm tra vì lợi ích (thử nghiệm tầm thường hoặc tautological), hoặc để đạt một số liệu tùy ý (như phạm vi bảo hiểm mã), là lập trình sùng bái hàng hóa." Vì vậy, sự thật và nói rất tốt. Kiểm tra theo cách mà bạn cảm thấy như một kẻ xấu lạnh lùng - hãy nghĩ về bản thân bạn như một ... gián điệp, vận động viên ưu tú ... KHÔNG thử nghiệm như một "bộ phận chính phủ". Bạn biết?

— Fattie

2

@SteveJessop không đồng ý, phạm vi bảo hiểm mã (theo nghĩa là một số liệu) vốn đã tùy ý: số lượng đường dẫn qua một chương trình không tầm thường ở cấp độ chỉ dẫn của máy (tức là số lượng) sẽ lớn hơn số lượng nguyên tử trên Trái đất hoặc thậm chí có thể là vũ trụ hữu hình. Đây không phải là thử nghiệm. Vì vậy, bất kỳ khiếu nại nào về 'phạm vi bảo hiểm mã' sẽ thuộc về một số ngưỡng tùy ý được chọn theo phương pháp . Các lập trình viên rất giỏi trong việc chơi các số liệu như vậy với chi phí cho những thứ thực sự quan trọng.

— Jared Smith

2

Tôi cũng sẽ nói rằng các thử nghiệm cung cấp giá trị doanh nghiệp xấp xỉ (mặc dù không chính xác) bất cứ khi nào chúng thất bại và độ phân giải là để cải thiện mã được thử nghiệm. Vì vậy, nếu bạn đang sử dụng TDD, điều đó sẽ tự động xảy ra ít nhất một lần cho mỗi bài kiểm tra. Xét nghiệm Tautological theo định nghĩa không thể thất bại và vì vậy là vô ích. Đối với các thử nghiệm "tầm thường" - đã làm việc với Java TCK từ rất sớm trong sự nghiệp của tôi, tôi không còn ngạc nhiên về việc thử nghiệm tầm thường có thể thất bại khi triển khai lại API từ đầu ;-) Nhưng giá trị kinh doanh là hầu như luôn dự đoán heuristur, do đó, "tùy tiện" quá.

— Steve Jessop

9

Nó phụ thuộc vào từng người, cũng như độ phức tạp và hình dạng của mã bạn đang làm việc.

Đối với tôi, trên hầu hết các dự án, viết bài kiểm tra đơn vị có nghĩa là tôi hoàn thành công việc nhanh hơn khoảng 25%. Có, thậm chí bao gồm cả thời gian để viết các bài kiểm tra.

Bởi vì thực tế của vấn đề là phần mềm không được thực hiện khi bạn viết mã. Nó được thực hiện khi bạn gửi nó cho khách hàng và họ hài lòng với nó. Các thử nghiệm đơn vị cho đến nay là cách hiệu quả nhất mà tôi biết để bắt hầu hết các lỗi, cách ly hầu hết các lỗi để gỡ lỗi và để có được sự tin tưởng rằng mã là tốt. Bạn phải làm những điều đó dù sao đi nữa , vì vậy hãy làm chúng thật tốt.

— Telastyn
nguồn

7

Tôi nghĩ rằng đáng chú ý mặc dù, đó là một kỹ năng có được. Tôi thấy rất nhiều người nghe thấy tuyên bố rằng TDD thực sự thậm chí không phải là một khoản trả trước thời gian mà tự trả về trong thời gian dài, nó chỉ nhanh hơn, thời gian. sau đó họ thử nó trong một ngày và thật đau đớn vì họ có 0 kinh nghiệm, đã đọc 0 cuốn sách, không có thực hành, họ chỉ mong nó hoạt động một cách kỳ diệu. Không có bí mật nào đối với TDD giúp bạn trở thành một nhà phát triển tốt hơn, bạn vẫn cần thực hành, vẫn cần suy nghĩ, vẫn cần đưa ra quyết định giáo dục tốt.

— sara

1

@ Yêu - +1. Tôi đã dành nhiều tuần để đọc về TDD trước khi tôi thử nó. Tôi đọc mọi thứ tôi có thể tìm thấy. Tôi đọc sách. Tôi đọc qua tất cả các blog nhanh nhẹn nổi tiếng cho các ví dụ. Tôi đọc xUnit Test Forms -to-cover. Trong vài tuần đầu tiên, tôi vẫn mất gấp đôi thời gian.

— Jules

2

Tôi đồng ý. TDD là khó. Những suy nghĩ là khó khăn. Bất cứ ai nói "Chỉ cần viết bài kiểm tra trước" và tuyên bố rằng nó miễn phí không biết cách thực hiện. Nó cần thực hành.

— duffymo

@kai: vì những lý do tương tự, nhiều người không thể chạm vào. Họ đã thử nó một lần và sau cả tiếng đồng hồ vẫn không gõ nhanh hơn trước ;-)

— Steve Jessop

@SteveJessop Tôi đoán đó là một so sánh khá gọn gàng. Hoặc là thực sự không thích hợp và đi ra ngoài để chạy bộ 10 phút, bị kiệt sức và tự hỏi tại sao bạn không thể chạy 10 dặm một giờ. nó thực sự minh họa cách bạn cần làm việc trước khi bạn nhận được lợi ích.

— sara

4

Câu hỏi là, bao nhiêu sự khác biệt về thời gian sẽ viết mã được kiểm tra đơn vị so với mã chưa được kiểm tra và mức chênh lệch thời gian đó như thế nào khi phạm vi dự án mở rộng?

Vấn đề trở nên tồi tệ hơn khi tuổi của dự án tăng lên: bởi vì bất cứ khi nào bạn thêm chức năng mới và / hoặc bất cứ khi nào bạn tái cấu trúc triển khai hiện có, bạn phải kiểm tra lại những gì trước đây đã được kiểm tra để đảm bảo rằng nó vẫn hoạt động. Vì vậy, đối với một dự án kéo dài (nhiều năm), bạn có thể không chỉ cần kiểm tra chức năng mà còn kiểm tra lại 100 lần và hơn thế nữa. Vì lý do này, bạn có thể được hưởng lợi từ việc kiểm tra tự động . Tuy nhiên, IMO nó đủ tốt (hoặc thậm chí, tốt hơn) nếu đây là các thử nghiệm hệ thống tự động, thay vì thử nghiệm đơn vị tự động.

Một vấn đề thứ hai là các lỗi có thể khó tìm và sửa hơn nếu chúng không được phát hiện sớm. Ví dụ: nếu có lỗi trong hệ thống và tôi biết nó đã hoạt động hoàn hảo trước khi bạn thực hiện thay đổi mới nhất, thì tôi sẽ tập trung chú ý vào thay đổi mới nhất của bạn để xem nó có thể đã giới thiệu lỗi như thế nào. Nhưng nếu tôi không biết rằng hệ thống đã hoạt động trước khi bạn thực hiện thay đổi mới nhất của mình (vì hệ thống chưa được kiểm tra chính xác trước thay đổi mới nhất của bạn), thì lỗi có thể ở bất cứ đâu.

Những điều trên đặc biệt áp dụng cho mã sâu và ít hơn cho mã nông, ví dụ: thêm các trang web mới nơi các trang mới không có khả năng ảnh hưởng đến các trang hiện có.

Kết quả là, một số lượng đáng kể lỗi thoát khỏi sản xuất, mà tôi phải sửa và lần lượt đặt lại các dự án khác của tôi.

Theo kinh nghiệm của tôi, điều đó là không thể chấp nhận được, và vì vậy bạn đang đặt câu hỏi sai. Thay vì hỏi liệu các bài kiểm tra có làm cho sự phát triển nhanh hơn hay không, bạn nên hỏi điều gì sẽ làm cho sự phát triển không có lỗi hơn.

Một câu hỏi tốt hơn có thể là:

Kiểm thử đơn vị có phải là loại kiểm thử phù hợp, mà bạn cần tránh "số lượng lỗi đáng kể" mà bạn đang tạo ra không?
Có các cơ chế kiểm soát / cải tiến chất lượng khác (ngoài kiểm tra đơn vị) để đề xuất là tốt hay thay vào đó?

Học tập là một quá trình gồm hai giai đoạn: học để làm điều đó đủ tốt, sau đó học cách làm điều đó nhanh hơn.

— Chris
nguồn

3

Một số khía cạnh để xem xét, không được đề cập trong các câu trả lời khác.

Lợi ích bổ sung / Chi phí thêm phụ thuộc vào kinh nghiệm viết không rõ ràng
- với dự án thử nghiệm đơn vị đầu tiên của tôi, chi phí tăng gấp ba lần vì tôi phải học rất nhiều và tôi đã phạm rất nhiều sai lầm.
- Sau 10 năm kinh nghiệm với tdd tôi cần thêm 25% thời gian mã hóa để viết các bài kiểm tra trước.
với nhiều tdd-moduls hơn, vẫn cần kiểm tra thủ công và kiểm tra tích hợp
tdd chỉ hoạt động khi được thực hiện từ đầu.
- áp dụng tdd cho một dự án đã phát triển hiện có là tốn kém / phổ biến. Nhưng bạn có thể thực hiện kiểm tra hồi quy thay thế.
kiểm tra tự động (không kiểm tra và các loại kiểm tra khác) yêu cầu bảo trì const để giữ cho chúng hoạt động.
- đã tạo thử nghiệm thông qua sao chép và dán có thể làm cho testcode-bảo trì đắt tiền.
- với kinh nghiệm ngày càng tăng testcode trở nên mô-đun hơn và dễ bảo trì hơn.
với kinh nghiệm ngày càng tăng, bạn sẽ có được cảm giác đáng giá khi tạo các bài kiểm tra tự động và khi nào thì không.
- ví dụ không có lợi ích lớn đối với các getters / setters / Wrapper đơn giản nhất
- tôi không viết bài kiểm tra tự động thông qua gui
- tôi quan tâm rằng các doanh nhân có thể được kiểm tra

Tóm lược

Khi bắt đầu với tdd, điều đó là khó khăn để đạt đến trạng thái "có lợi hơn chi phí" miễn là bạn ở trong "môi trường làm việc bị hạn chế về thời gian" đặc biệt là nếu có "người quản lý thông minh" nói với bạn rằng "hãy loại bỏ sự đắt đỏ, vô dụng công cụ kiểm tra "

Lưu ý: với "thử nghiệm đơn vị" tôi có nghĩa là "thử nghiệm mô-đun cách ly".

Lưu ý: với "kiểm tra hồi quy" ý tôi là

viết một số mã tạo ra một số văn bản đầu ra.
viết một số mã "kiểm tra hồi quy" để xác minh rằng kết quả của thế hệ ist vẫn giống nhau.
kiểm tra hồi quy cho bạn biết bất cứ khi nào kết quả thay đổi (có thể ổn hoặc chỉ báo cho một lỗi mới)
ý tưởng "kiểm tra hồi quy" tương tự như phê duyệt
- ... chụp ảnh kết quả và xác nhận rằng chúng không thay đổi.

— k3b
nguồn

Cần hiệu đính (tương đương văn học của thử nghiệm?)

— JDługosz

3

Các lập trình viên, giống như những người xử lý hầu hết các nhiệm vụ, đánh giá thấp thời gian thực sự mất bao lâu để hoàn thành nó. Với ý nghĩ đó, việc dành 10 phút để viết một bài kiểm tra có thể được xem xét như thời gian người ta có thể đã viết hàng tấn mã khi trong thực tế, bạn sẽ dành thời gian đó để đưa ra cùng tên hàm và các tham số bạn đã làm trong quá trình kiểm tra . Đây là một kịch bản TDD.

Không viết bài kiểm tra, rất giống như có thẻ tín dụng; chúng ta có xu hướng chi tiêu nhiều hơn hoặc viết nhiều mã hơn. Nhiều mã có nhiều lỗi hơn.

Thay vì quyết định có tổng phạm vi bảo hiểm hoặc không có gì cả, tôi khuyên bạn nên tập trung vào phần quan trọng và phức tạp trong ứng dụng của bạn và có các bài kiểm tra ở đó. Trong một ứng dụng ngân hàng, đó có thể là tính toán lãi suất. Một công cụ chẩn đoán động cơ có thể có các giao thức hiệu chuẩn phức tạp. Nếu bạn đang làm việc trên một dự án, bạn có thể biết nó là gì và lỗi ở đâu.

Bắt đầu từ từ. Xây dựng một số lưu loát trước khi bạn phán xét. Bạn luôn có thể dừng lại.

— Jeff
nguồn

3

Đã có một lịch sử lâu dài của các lập trình viên ban quảng bá TDD và các phương pháp thử nghiệm khác, tôi sẽ không nhớ lại các lập luận của họ và đồng ý với họ, nhưng đây là những điều cần xem xét thêm về sắc thái một chút:

Kiểm tra không thuận tiện như nhau và hiệu quả tùy thuộc vào bối cảnh. Tôi phát triển phần mềm web, cho tôi biết nếu bạn có chương trình kiểm tra toàn bộ giao diện người dùng ... ngay bây giờ tôi đang lập trình macro excel, tôi có thực sự nên phát triển một mô-đun thử nghiệm trong VBA không?
Viết và bảo trì phần mềm kiểm tra là công việc thực sự được tính trong thời gian ngắn (nó sẽ mang lại hiệu quả trong thời gian dài hơn). Viết các bài kiểm tra có liên quan cũng là một chuyên môn để có được
Làm việc theo nhóm và làm việc một mình, không có các yêu cầu kiểm tra giống nhau vì trong nhóm bạn cần xác thực, hiểu và giao tiếp mã bạn không viết.

Tôi muốn nói kiểm tra là tốt, nhưng hãy chắc chắn rằng bạn kiểm tra sớm và kiểm tra mức tăng là bao nhiêu.

— Arthur Havlicek
nguồn

1

"Tôi có nên thực sự phát triển một mô-đun thử nghiệm cho VBA không?" Chết tiệt bạn nên. Rubberduckvba.com/Features#unitTesting

— RubberDuck

Có một vài lý do tôi sẽ không sử dụng điều này vì nó không phù hợp với nhu cầu của tôi (Tôi hầu như không có nhiệm vụ trong vài ngày, môi trường bị khóa, người kế nhiệm sẽ không làm phiền bên thứ 3). Mặc dù bình luận tốt, ngôn ngữ không phải là một cái cớ trong chính nó :)

— Arthur Havlicek

Tất cả các điểm công bằng @ArthurHavlicek.

— RubberDuck

2

Kiểm tra viết vẫn còn tầm thường trong VBA. Có tất cả các tính năng ưa thích mà một số khung không đáng tin cậy nhất có? Điều đó khó hơn, nhưng chạy một chương trình gọi là mainTest()tất cả các mô-đun thử nghiệm của bạn không thực sự khó đến thế.

— enderland

1

Một lợi ích bị bỏ qua của TDD là các xét nghiệm hoạt động như một biện pháp bảo vệ để đảm bảo bạn không đưa ra các lỗi mới khi bạn thực hiện thay đổi.

Cách tiếp cận TDD chắc chắn tốn nhiều thời gian hơn ban đầu nhưng điểm đáng chú ý là bạn sẽ viết ít mã hơn , điều đó có nghĩa là ít sai sót hơn. Tất cả những tiếng chuông và còi mà bạn thường đưa vào như một vấn đề tất nhiên sẽ không biến nó thành cơ sở mã.

Có một cảnh trong bộ phim Swordfish, nếu bộ nhớ phục vụ, một hacker phải làm việc với một khẩu súng trên đầu và bị ... làm mất tập trung. Vấn đề là làm việc dễ dàng hơn rất nhiều khi khoảng trống của bạn nằm trong mã và bạn có thời gian ở bên thay vì hàng tháng trời với một khách hàng hét vào mặt bạn và các ưu tiên khác bị siết chặt.

Các nhà phát triển hiểu rằng sửa lỗi sau này tốn kém hơn, nhưng hãy lật nó lên. Nếu bạn có thể được trả 500 đô la một ngày để mã hóa cách bạn mã hóa ngay bây giờ hoặc 1000 đô la nếu bạn viết theo cách TDD, bạn sẽ cắn tay người đưa ra lời đề nghị thứ 2 cho bạn. Bạn càng sớm ngừng xem thử nghiệm như một việc vặt và xem nó như một công cụ tiết kiệm tiền, bạn sẽ càng có lợi.

— Robbie Dee
nguồn

Điều đó trong câu đầu tiên của bạn được gọi là Kiểm tra hồi quy

— mèo

0

Tôi có thể liên quan đến kinh nghiệm của bạn - cơ sở mã của chúng tôi gần như không có thử nghiệm và hầu như không thể kiểm chứng được. Phải mất nhiều thời gian để phát triển một cái gì đó và sửa lỗi sản xuất mất thời gian quý báu từ các tính năng mới.

Để viết lại một phần, tôi thề sẽ viết các bài kiểm tra cho tất cả các chức năng cốt lõi. Lúc đầu, nó mất nhiều thời gian hơn và năng suất của tôi bị giảm đáng kể, nhưng sau đó năng suất của tôi tốt hơn bao giờ hết.

Một phần của sự cải thiện đó là tôi có ít lỗi sản xuất hơn, từ đó dẫn đến ít bị gián đoạn hơn -> Tôi đã tập trung tốt hơn vào bất kỳ thời điểm nào.

Hơn nữa, khả năng kiểm tra mã gỡ lỗi AND rất đơn giản - một bộ thử nghiệm vượt trội hơn rất nhiều so với hệ thống không thể gỡ lỗi trừ khi cài đặt thủ công, ví dụ: khởi chạy ứng dụng của bạn và điều hướng đến màn hình và làm gì đó ... có lẽ vài chục lần

Nhưng lưu ý rằng có sự sụt giảm năng suất ngay từ đầu, vì vậy hãy bắt đầu học thử nghiệm trên một số dự án nơi áp lực thời gian chưa điên rồ. Ngoài ra, hãy thử khởi động nó trong một dự án greenfield, mã kế thừa đơn vị thử nghiệm rất khó và nó giúp ích khi bạn biết một bộ thử nghiệm tốt trông như thế nào.

— Christian Sauer
nguồn

0

Chỉ để bổ sung cho các câu trả lời trước: hãy nhớ rằng kiểm tra không phải là một mục đích. Mục đích của việc thực hiện các bài kiểm tra là để ứng dụng của bạn hoạt động như mong đợi thông qua quá trình tiến hóa, trong bối cảnh bất ngờ, v.v.

Do đó, kiểm tra viết không có nghĩa là chứng minh tất cả các hành vi của tất cả các điểm cuối của một thực thể. Đây là một lỗi phổ biến. Rất nhiều nhà phát triển nghĩ rằng họ cần kiểm tra tất cả các hàm / đối tượng / phương thức / thuộc tính / v.v. Điều này dẫn đến một khối lượng công việc lớn và một loạt các mã và kiểm tra không liên quan. Cách tiếp cận này là phổ biến trong các dự án lớn, nơi hầu hết các nhà phát triển không nhận thức được hành vi tổng thể, nhưng chỉ có thể thấy miền tương tác của họ.

Cách tiếp cận đúng đắn khi xử lý các tài nguyên thưa thớt và thử nghiệm là khá rõ ràng và thông thường, nhưng không được chính thức hóa: đầu tư thử nghiệm các tài nguyên phát triển trước tiên vào các chức năng cấp cao, và dần dần đi vào các đặc tính . Điều này có nghĩa là tại một số điểm, với tư cách là một nhà phát triển cô đơn, bạn sẽ không chỉ tập trung vào kiểm thử đơn vị, mà còn về chức năng / tích hợp / vv. kiểm tra và tùy thuộc vào tài nguyên thời gian của bạn, dần dần vào các chức năng đơn nhất chính, như bạn sẽ lập kế hoạch và xem xét. Thử nghiệm cấp cao sẽ cung cấp thông tin cần thiết để giải quyết thử nghiệm cấp thấp / đơn nhất và lập kế hoạch cho chiến lược phát triển thử nghiệm của bạn theo các tài nguyên bạn có.

Ví dụ: trước tiên bạn muốn kiểm tra chuỗi xử lý dưới dạng hộp đen. Nếu bạn thấy rằng một số thành viên của chuỗi thất bại do hành vi không được coi là một số điều kiện khắc nghiệt, bạn viết các bài kiểm tra đảm bảo chức năng không chỉ cho thành viên này mà còn cho những người khác. Sau đó bạn giao hàng. Đối với chu kỳ tiếp theo, bạn phát hiện ra rằng đôi khi mạng bị lỗi. Vì vậy, bạn viết các bài kiểm tra giải quyết vấn đề như vậy trên các mô-đun có thể dễ bị tổn thương. Và như vậy.

— RodolfoAP
nguồn