Tôi có nên viết bài kiểm tra khi tôi có thể chứng minh tính chính xác của mã không?

Mọi người nói rằng "nói về TDD hầu như không hoạt động, nếu bạn muốn thuyết phục ai đó về TDD, hãy cho họ thấy kết quả". Tuy nhiên, tôi đã nhận được kết quả tuyệt vời mà không cần TDD. Cho tôi thấy rằng những người sử dụng TDD có kết quả tốt sẽ không thuyết phục, tôi muốn thấy rằng những người viết cả TDD và không TDD đều có kết quả tốt hơn với TDD.

Bất chấp tất cả những điều này, tôi muốn thử TDD. Tuy nhiên tôi không tin rằng tôi sẽ đạt được bất cứ điều gì từ điều này. Nếu nó hữu ích, tôi sẽ cố gắng đẩy nó về phần còn lại của đội mình.

Câu hỏi chính của tôi là: TDD sẽ phục vụ bất kỳ mục đích nào cho mã, nếu tôi đã có thể chứng minh tính chính xác của mã?

Rõ ràng, không ai là viên đạn bạc. Bằng chứng của bạn có thể sai vì bạn đã bỏ lỡ một chi tiết và bài kiểm tra của bạn có thể không phát hiện ra lỗi mà bạn không kiểm tra được. Cuối cùng, chúng ta là con người, không ai có thể tạo mã miễn phí 100% mãi mãi. Chúng tôi chỉ có thể phấn đấu để đến gần nhất có thể.

Tuy nhiên, TDD có thực sự tiết kiệm bất kỳ thời gian nào đối với mã đã được chứng minh tính đúng đắn của nó không? tức là mã, trong máy trạng thái mà mã hoạt động, tất cả các trạng thái có thể hợp lệ và phạm vi của chúng được nhà phát triển nhận ra, tất cả đều được tính và mã được thiết kế theo kiểu kiểm tra lỗi theo danh sách trắng vượt qua mọi ngoại lệ một trình xử lý phía trên để đảm bảo không có bất kỳ rò rỉ bất ngờ nào -> mà không hiển thị cả thông báo có liên quan (trong lý do-) cho khách hàng và gửi thông báo nhật ký cho quản trị viên.

Câu trả lời với các ví dụ thực tế sẽ tốt hơn.

Một số làm rõ:

• Câu hỏi này không phải là về việc bạn có thể chứng minh tính chính xác của mã hay không. Theo mặc định, giả sử rằng không phải tất cả các mã đều có thể được chứng minh là đúng trong khung thời gian hợp lý, nhưng một số đoạn mã có thể được. Ví dụ, rất dễ chứng minh tính đúng đắn của mô-đun FizzBuzz. Không dễ dàng cho một dịch vụ đồng bộ hóa dữ liệu dựa trên đám mây.

• Trong giới hạn này, câu hỏi đặt ra như sau: Bắt đầu với giả định rằng một cơ sở mã được chia thành 2 phần: [I] các phần đã được chứng minh là đúng [II] các phần chưa được chứng minh là đúng, nhưng được kiểm tra thủ công để hoạt động.

• Tôi muốn áp dụng các thực tiễn TDD cho cơ sở mã này mà không có chúng cho đến bây giờ. Câu hỏi đặt ra như sau: TDD có nên được áp dụng cho mọi mô-đun không, hoặc liệu có đủ để áp dụng chúng cho chỉ các mô-đun không được chứng minh là đúng?

• "Đã được chứng minh chính xác" có nghĩa là bạn có thể xem mô-đun này hoàn toàn theo kiểu chức năng, nghĩa là nó không dựa vào bất kỳ trạng thái toàn cầu hoặc bên ngoài nào bên ngoài và hoàn toàn có API riêng cho I / O mà các mô-đun khác tương tác với nó phải tuân theo . Không thể "phá vỡ mô-đun này" bằng cách thay đổi mã bên ngoài mô-đun, tệ nhất là bạn có thể sử dụng sai và nhận các thông báo lỗi được định dạng trả lại cho bạn.

• Rõ ràng, mọi quy tắc đều có ngoại lệ, lỗi trình biên dịch trong các phiên bản trình biên dịch mới có thể đưa ra lỗi cho mô-đun này, nhưng các lỗi tương tự có thể được đưa vào các thử nghiệm đã kiểm tra nó và dẫn đến cảm giác an toàn sai từ các thử nghiệm không còn hoạt động như dự định. Điểm mấu chốt là các thử nghiệm không phải là một giải pháp kỳ diệu, chúng là một lớp bảo vệ khác và câu hỏi này thảo luận về vấn đề liệu lớp bảo vệ này có xứng đáng với nỗ lực trong trường hợp cụ thể của một mô-đun đã được chứng minh là đúng hay không (giả sử rằng nó đã thực sự).

Đúng.

Bằng chứng là tốt khi chúng có sẵn, nhưng ngay cả ở thời điểm tốt nhất, chúng chỉ chứng minh rằng một bit mã sẽ hoạt động như mong đợi (đối với tất cả các đầu vào? Kế toán cho các gián đoạn ở giữa bất kỳ hoạt động nào? Điều gì về việc hết bộ nhớ ? Lỗi đĩa? lỗi mạng?).

Điều gì xảy ra khi nó thay đổi?

Các thử nghiệm là tuyệt vời vì chúng phục vụ như một hợp đồng ngụ ý về những gì mã nên làm. Họ cung cấp một số giàn giáo để thực tập sinh mới của bạn có thể đi vào và thực hiện các thay đổi với một mức độ tự tin. Tất cả thông qua kết quả nhanh chóng, rõ ràng: vượt qua hoặc thất bại.

Và thẳng thắn, tôi có thể huấn luyện một thực tập sinh để viết bài kiểm tra đơn vị khả thi trong một vài tháng. Tôi nghi ngờ rằng bất kỳ ai trong nhóm của tôi (bao gồm cả tôi) có thể tạo ra bằng chứng đảm bảo mọi thứ có ý nghĩa đối với mã không tầm thường; hãy để một mình làm điều đó một cách nhanh chóng và chính xác.

Chúng tôi không biết. Chúng tôi không thể trả lời câu hỏi của bạn.

Trong khi bạn dành nhiều thời gian để giải thích quá trình mà bây giờ bạn có vẻ làm việc để làm hài lòng tất cả mọi người, bạn chỉ nói với chúng tôi những điều nhỏ nhặt về những gì đang thực sự xảy ra.

Từ kinh nghiệm của tôi, những gì bạn đang mô tả là rất hiếm và tôi nghi ngờ rằng đó thực sự là quá trình và cách tiếp cận của bạn để mã hóa thực sự là nguyên nhân của số lượng lỗi thấp trong các ứng dụng của bạn. Có thể có nhiều yếu tố khác ảnh hưởng đến ứng dụng của bạn và bạn không cho chúng tôi biết gì về những yếu tố đó.

Vì vậy, chúng tôi không biết, trước khi không biết môi trường và văn hóa phát triển chính xác của bạn, liệu TDD có giúp bạn hay không. Và chúng ta có thể dành nhiều ngày để thảo luận và tranh luận về nó.

Chỉ có một đề nghị chúng tôi có thể cung cấp cho bạn: hãy thử. Thí nghiệm. Học nó. Tôi biết bạn đang cố gắng dành ít nỗ lực nhất để quyết định, nhưng điều đó là không thể. Nếu bạn thực sự muốn biết liệu TDD có hoạt động trong ngữ cảnh của bạn hay không, cách duy nhất để tìm hiểu là thực sự làm TDD. Nếu bạn thực sự học nó và áp dụng nó vào ứng dụng của mình, bạn có thể so sánh nó với quy trình không TDD của bạn. Có thể TDD thực sự có lợi thế và bạn quyết định giữ nó. Hoặc có thể phát hiện ra rằng TDD không mang lại điều gì mới và chỉ làm bạn chậm lại. Trong trường hợp đó, bạn có thể quay lại quy trình trước đó của bạn.

Mục đích chính của các bài kiểm tra (đơn vị) là bảo vệ mã, đảm bảo nó sẽ không bị phá vỡ vì những thay đổi sau này. Khi mã được viết lần đầu tiên, nó sẽ được chú ý rất nhiều và nó sẽ được xem xét kỹ lưỡng. Và bạn có thể có một số hệ thống ưu việt cho điều đó.

Sáu tháng sau, khi một người khác đang làm việc với một thứ gì đó dường như không liên quan, nó có thể bị phá vỡ và người cung cấp mã chính xác siêu lừa đảo của bạn sẽ không nhận thấy điều đó. Một bài kiểm tra tự động sẽ.

Tôi muốn áp dụng các thực tiễn TDD cho cơ sở mã này mà không có chúng cho đến bây giờ.

Đây là cách khó nhất để học TDD. Bạn kiểm tra càng muộn thì càng tốn nhiều chi phí để viết bài kiểm tra và bạn càng ít thoát khỏi việc viết chúng.

Tôi không nói rằng không thể trang bị thêm các bài kiểm tra vào một cơ sở mã hiện có. Tôi đang nói làm như vậy không có khả năng biến bất kỳ ai thành tín đồ TDD. Đây là công việc khó khăn.

Thực sự tốt nhất để thực hành TDD lần đầu tiên trên một cái gì đó mới và ở nhà. Bằng cách đó bạn học được nhịp điệu thực sự. Làm điều này đúng và bạn sẽ thấy nó gây nghiện.

Câu hỏi đặt ra như sau: TDD có nên được áp dụng cho mọi mô-đun không,

Đó là tư duy cấu trúc. Bạn không nên nói những thứ như kiểm tra mọi chức năng, hoặc lớp hoặc mô-đun. Những ranh giới đó không quan trọng để thử nghiệm và dù sao họ cũng có thể thay đổi. TDD là về việc thiết lập một nhu cầu hành vi có thể kiểm chứng và không quan tâm đến việc nó hài lòng như thế nào. Nếu không, chúng tôi không thể tái cấu trúc.

hoặc nó sẽ là đủ để áp dụng chúng cho chỉ các mô-đun không được chứng minh là đúng?

Thế là đủ để áp dụng chúng khi bạn thấy cần chúng. Tôi sẽ bắt đầu với mã mới. Bạn sẽ nhận lại được nhiều hơn từ việc kiểm tra sớm hơn là muộn. Đừng làm điều này tại nơi làm việc cho đến khi bạn thực hành đủ để thành thạo nó ở nhà.

Khi bạn cho thấy TDD có hiệu quả với mã mới tại nơi làm việc và cảm thấy đủ tự tin để tiếp nhận mã cũ tôi sẽ bắt đầu với mã đã được chứng minh. Lý do là vì bạn sẽ có thể nhìn thấy ngay nếu các bài kiểm tra bạn viết đang thực hiện theo hướng tốt.

Câu hỏi chính của tôi là: TDD sẽ phục vụ bất kỳ mục đích nào cho mã, nếu tôi đã có thể chứng minh tính chính xác của mã?

Các xét nghiệm không chỉ chứng minh tính đúng đắn. Họ thể hiện ý định. Họ cho thấy những gì cần thiết. Họ chỉ ra một con đường để thay đổi. Một bài kiểm tra tốt cho biết có một số cách để viết mã này và có được những gì bạn muốn. Họ giúp các lập trình viên mới thấy những gì họ có thể làm mà không phá vỡ mọi thứ.

Chỉ một khi bạn có được điều đó, bạn nên đi lang thang vào mã chưa được chứng minh.

Một cảnh báo chống lại những người quá khích: Bạn có vẻ như bạn đã đạt được thành công và do đó sẽ không thể nhảy vào đầu. Nhưng những người khác đang tìm cách chứng minh bản thân họ sẽ không được bảo lưu như vậy. TDD có thể bị quá liều. Thật dễ dàng để tạo ra một bộ các thử nghiệm thực sự gây tổn hại cho việc tái cấu trúc vì chúng khóa các thứ vô giá trị và vô nghĩa. Làm thế nào điều này xảy ra? Bởi vì những người muốn thể hiện các bài kiểm tra chỉ viết bài kiểm tra và không bao giờ tái cấu trúc. Giải pháp? Làm cho họ tái cấu trúc. Làm cho họ đối phó với các thay đổi tính năng. Càng sớm càng tốt. Điều đó sẽ cho bạn thấy các bài kiểm tra vô dụng một cách nhanh chóng. Bạn chứng minh sự linh hoạt bằng cách uốn cong.

Một cảnh báo chống phân loại cấu trúc: Một số người sẽ nhấn mạnh rằng một lớp là một đơn vị. Một số người sẽ gọi bất kỳ bài kiểm tra nào với hai lớp là bài kiểm tra tích hợp. Một số người sẽ nhấn mạnh rằng bạn không thể vượt qua ranh giới x và gọi đó là bài kiểm tra đơn vị. Thay vì quan tâm đến bất kỳ điều gì tôi khuyên bạn nên quan tâm đến cách kiểm tra của bạn. Nó có thể chạy trong một phần của giây không? Nó có thể được chạy song song với các thử nghiệm khác (tác dụng phụ miễn phí) không? Nó có thể được chạy mà không cần khởi động hoặc chỉnh sửa những thứ khác để đáp ứng các phụ thuộc và điều kiện tiên quyết? Tôi đặt những cân nhắc này lên trước nếu nó nói chuyện với DB, hệ thống tệp hoặc mạng. Tại sao? Bởi vì ba vấn đề cuối cùng chỉ là vấn đề vì chúng gây ra những vấn đề khác. Nhóm các bài kiểm tra của bạn với nhau dựa trên cách bạn có thể mong đợi chúng hành xử. Không phải ranh giới họ xảy ra để vượt qua. Sau đó, bạn biết những gì bạn có thể mong đợi mỗi bộ thử nghiệm để làm.

Tôi đã thấy mọi người nói rằng họ không muốn sử dụng TDD vì nó sẽ có quá nhiều chi phí và những người ủng hộ TDD bảo vệ điều đó bằng cách nói rằng một khi bạn đã quen viết TDD mọi lúc thì không có quá nhiều chi phí.

Câu hỏi đó đã có câu trả lời ở đây .

Test Driven Development liên quan nhiều đến việc tạo mẫu và động não một API, hơn là thử nghiệm. Các xét nghiệm được tạo ra thường có chất lượng kém và cuối cùng phải bị loại bỏ. Ưu điểm chính của TDD là xác định cách sử dụng API trước khi viết triển khai API. Lợi thế này cũng có thể có được theo những cách khác, ví dụ bằng cách viết tài liệu API trước khi thực hiện.

Bằng chứng chính xác luôn có giá trị hơn các bài kiểm tra. Các xét nghiệm không chứng minh bất cứ điều gì. Tuy nhiên, để sử dụng bằng chứng chính xác một cách hiệu quả, cần phải có trình kiểm tra bằng chứng tự động và bạn sẽ cần phải sử dụng các hợp đồng thuộc loại nào đó (thiết kế theo hợp đồng hoặc thiết kế dựa trên hợp đồng).

Trước đây, khi làm việc trên các phần quan trọng của mã, tôi sẽ thử bằng chứng chính xác thủ công. Ngay cả bằng chứng không chính thức cũng có giá trị hơn bất kỳ bài kiểm tra tự động nào. Nhưng bạn vẫn cần các bài kiểm tra, trừ khi bạn có thể tự động hóa bằng chứng của mình, vì mọi người sẽ phá mã của bạn trong tương lai.

Kiểm tra tự động không ngụ ý TDD.

A) Bạn đọc mã và tự thuyết phục bản thân rằng nó chính xác không phải từ xa để chứng minh nó đúng. Nếu không thì tại sao lại viết bài kiểm tra?

B) Khi bạn thay đổi mã bạn muốn chạy thử nghiệm chứng minh mã vẫn đúng hay không.

Tôi sẽ cảnh báo bằng cách nói rằng một khi bạn đã quen với việc sử dụng TDD một cách hiệu quả, nó sẽ giúp bạn tiết kiệm thời gian trong trò chơi kết thúc. Cần thực hành để học cách sử dụng TDD một cách hiệu quả và không giúp ích gì khi bạn đang trong thời gian khủng hoảng. Khi tìm hiểu cách sử dụng nó tốt nhất, tôi khuyên bạn nên bắt đầu một dự án cá nhân nơi bạn có nhiều thời gian hơn và ít áp lực lịch trình hơn.

Bạn sẽ thấy rằng tiến trình ban đầu của bạn chậm hơn trong khi bạn đang thử nghiệm nhiều hơn và viết API của bạn. Theo thời gian, tiến trình của bạn sẽ nhanh hơn khi các thử nghiệm mới của bạn bắt đầu trôi qua mà không thay đổi mã và bạn có cơ sở rất ổn định để xây dựng từ đó. Trong trò chơi muộn, mã không được xây dựng bằng TDD yêu cầu bạn phải dành nhiều thời gian hơn cho trình gỡ lỗi khi bạn cố gắng tìm ra điều gì đang xảy ra sai hơn là cần thiết. Bạn cũng có nguy cơ cao hơn trong việc phá vỡ thứ gì đó đã từng làm việc với những thay đổi mới. Đánh giá hiệu quả của TDD so với việc không sử dụng nó theo tổng thời gian để hoàn thành.

Điều đó nói rằng, TDD không phải là trò chơi duy nhất trong thị trấn. Bạn có thể sử dụng BDD sử dụng một cách tiêu chuẩn để thể hiện hành vi của ứng dụng toàn ngăn xếp và đánh giá tính chính xác của API từ đó.

Toàn bộ đối số của bạn xoay quanh "việc chứng minh tính chính xác của mã", vì vậy bạn cần một cái gì đó xác định tính chính xác của mã. Nếu bạn không sử dụng một công cụ tự động để định nghĩa "chính xác" nghĩa là gì, thì định nghĩa này rất chủ quan. Nếu định nghĩa chính xác của bạn dựa trên sự đồng thuận của các đồng nghiệp, điều đó có thể thay đổi vào bất kỳ ngày nào. Định nghĩa của bạn về các nhu cầu chính xác phải cụ thể và có thể kiểm chứng, điều đó cũng có nghĩa là nó sẽ có thể được đánh giá bằng một công cụ. Tại sao không sử dụng một?

Chiến thắng số 1 từ việc sử dụng thử nghiệm tự động dưới bất kỳ hình thức nào, là bạn có thể xác minh mã của mình vẫn chính xác ngay cả khi các bản vá hệ điều hành được áp dụng nhanh chóng và hiệu quả. Chạy bộ phần mềm của bạn để đảm bảo mọi thứ đều trôi qua, sau đó áp dụng bản vá và chạy lại bộ phần mềm. Thậm chí tốt hơn, làm cho nó một phần của cơ sở hạ tầng xây dựng tự động của bạn. Bây giờ bạn có thể xác minh mã của mình vẫn đúng sau khi hợp nhất mã từ nhiều nhà phát triển.

Kinh nghiệm của tôi khi sử dụng TDD đã đưa tôi đến những kết luận sau:

• Thật tuyệt vời cho mã mới, khó thay đổi hệ thống cũ
• Bạn vẫn phải biết những gì bạn đang cố gắng thực hiện (tức là có kế hoạch)
• Bắt đầu chậm, nhưng tiết kiệm thời gian sau
• Buộc bạn phải suy nghĩ về cách xác thực tính chính xác và gỡ lỗi từ góc độ người dùng

Kinh nghiệm của tôi khi sử dụng BDD đã đưa tôi đến những kết luận sau:

• Nó hoạt động cho cả di sản và mã mới
• Nó xác nhận toàn bộ ngăn xếp và xác định đặc tả
• Chậm hơn để đứng dậy và chạy (giúp có người biết bộ công cụ)
• Ít hành vi cần được xác định hơn so với kiểm tra đơn vị

Định nghĩa chính xác: Mã của bạn tuân thủ các yêu cầu. Điều này được xác minh tốt nhất với BDD, cung cấp một phương tiện để thể hiện các yêu cầu đó theo cách dễ đọc của con người và xác minh chúng trong thời gian chạy.

Tôi không nói về tính đúng đắn trong các bằng chứng toán học, điều này là không thể. Và tôi mệt mỏi khi có lý lẽ đó.