Về lý thuyết chỉ có TDD

Hơn một năm trước tôi đã may mắn có thể nghỉ làm 9 tháng. Tôi quyết định rằng trong thời gian đó tôi sẽ trau dồi kỹ năng C # của mình. Tôi bắt đầu thực hiện một loạt các dự án và buộc mình phải theo TDD.

Đó là một quá trình khai sáng.

Ban đầu thật khó khăn, nhưng qua thời gian, tôi đã học được cách viết mã có thể kiểm tra nhiều hơn (mà, hóa ra, có xu hướng là mã RẮN hơn) và trong quá trình tôi cũng đã mài giũa kỹ năng thiết kế OO của mình.

Bây giờ tôi trở lại lực lượng lao động và tôi nhận thấy điều gì đó kỳ lạ.

Tôi không thích theo TDD.

Tôi thấy TDD làm tôi chậm lại và thực sự làm cho việc thiết kế một ứng dụng sạch trở nên khó khăn hơn.

Thay vào đó, tôi đã áp dụng một cách tiếp cận khác (ồ ạt):

1. Chọn một lát dọc của công việc
2. Phát triển một nguyên mẫu hoạt động
3. Tái cấu trúc cho đến khi mọi thứ đều tốt đẹp và gọn gàng
4. Ngồi lại đánh giá cao mã RẮN và mã có thể kiểm tra đẹp mà tôi đã viết.

Bạn có thể nhận thấy rằng bước 1 không phải là "xác định bề mặt công khai của mục tiêu thử nghiệm của tôi" và bước 2 không phải là "thử nghiệm các loại đá ong ra khỏi bề mặt công cộng đã nói". Bạn cũng có thể nhận thấy rằng không có bước nào liên quan đến thử nghiệm. Tôi đang viết mã có thể kiểm tra, nhưng tôi chưa kiểm tra nó ... chưa.

Bây giờ, tôi muốn làm rõ rằng tôi không thực sự từ bỏ bất kỳ loại thử nghiệm nào. Mã tôi đang viết hoạt động . Nó hoạt động vì tôi đang thử nó bằng tay.

Tôi cũng muốn làm rõ rằng tôi cũng không từ bỏ tất cả các thử nghiệm tự động. Đây là nơi quá trình của tôi là khác nhau. Và đây là lý do tại sao tôi hỏi câu hỏi này.

TDD trên lý thuyết. Không trong thực tế.

Quá trình của tôi đã phát triển một chút và tôi đã đạt được sự cân bằng giữa TDD và không có xét nghiệm nào tôi thấy rất hiệu quả và cũng an toàn hợp lý. Nó diễn ra như sau:

1. Thực hiện một lát cắt dọc làm việc với tâm trí thử nghiệm, nhưng không viết bất kỳ thử nghiệm nào.
2. Nếu xuống đường (ví dụ, một tháng sau), lát cắt đó cần sửa đổi
   1. Viết Bài kiểm tra đơn vị, Kiểm tra tích hợp, Kiểm tra hành vi, v.v ... đảm bảo lát cắt công việc là chính xác
   2. Sửa đổi mã
3. Nếu lát đó không cần sửa đổi,
   1. Không làm gì cả

Bằng cách đơn giản chuyển gánh nặng viết bài kiểm tra từ trước khi viết mã sang trước khi sửa đổi mã tôi đã có thể tạo ra nhiều mã làm việc hơn. Và, khi tôi đi loanh quanh để viết các bài kiểm tra, tôi viết ít hơn rất nhiều trong số chúng nhưng bao gồm gần như nhiều mặt bằng (ROI cao hơn).

Tôi thích quá trình này, nhưng tôi lo ngại nó có thể không có quy mô tốt. Thành công của nó xoay quanh các nhà phát triển siêng năng viết bài kiểm tra trước khi họ thay đổi mọi thứ. Và đó dường như là một rủi ro khá lớn. Nhưng, TDD có rủi ro rất giống nhau.

Vì vậy, tôi sẽ đến [BT] DD hell, hay đây là một hình thức phổ biến của mã hóa và thử nghiệm?

Tôi muốn tiếp tục làm việc theo cách này. Tôi có thể làm gì để quá trình này hoạt động lâu dài?

Tôi là nhà phát triển duy nhất cho các dự án của mình và tôi chịu trách nhiệm về mọi thứ: Thu thập yêu cầu, thiết kế, kiến ​​trúc, thử nghiệm, triển khai, v.v. Tôi nghi ngờ đây là lý do tại sao quy trình của tôi hoạt động.

Để làm cho quá trình hoạt động trong dài hạn, tôi sẽ viết các bài kiểm tra khi mã được viết.

Mà có vẻ mâu thuẫn với cách tiếp cận của bạn. Tuy nhiên, bạn đã đặt ra câu hỏi vì vậy tôi sẽ đưa cho bạn câu hỏi của tôi:

Bạn không phải viết các bài kiểm tra trước khi mã. Hãy quên đi sự tinh khiết đó. Tuy nhiên, bạn muốn viết các bài kiểm tra trong khoảng thời gian đó.
Khi bạn đã làm cho mã hoạt động, bạn đã tinh chỉnh nó một chút, đã phát hiện ra một số lỗi (chúng ta đang nói về một khoảng thời gian ở đây), lúc đó bạn sẽ hiểu rõ nhất về những gì mã đang làm. Đây là thời điểm tuyệt vời để viết các bài kiểm tra nắm bắt kiến ​​thức của bạn.

Để lại điều này cho đến sau này có nghĩa là kiến ​​thức (tự nhiên) sẽ giảm dần theo thời gian.

Điều đó cũng có nghĩa là bạn nên rời đi và bất kỳ ai khác tiếp quản bạn sẽ không có khoản nợ kỹ thuật ngay lập tức khi không có tài liệu (thông qua các bài kiểm tra) để làm gì.

Hầu hết tất cả, "một ngày nào đó" có thể không đến. Bạn có thể bị xe buýt đâm hoặc bạn có thể lên xe buýt cho những cuộc phiêu lưu mới.

Cuối cùng, kiểm tra thủ công không mở rộng quy mô và thường không bao gồm tất cả các thiết bị được sử dụng bởi người dùng cuối.

Mặc dù TDD rất khó thực hiện 100% nhưng có một lỗ hổng trong cách tiếp cận của bạn

1. Thực hiện một lát cắt dọc làm việc

   1.1 1 năm trôi qua ....

   1.2 Một nhà phát triển mới bắt đầu làm việc với dự án

2. Nếu lát đó cần sửa đổi

   2.3 Các tên và tham số của kiểu phương thức 'Clean Coding' 'GetUnicorn (colourOfUnicorn)'

   2.4 Đọc bình luận xml 'Nhận được một con kỳ lân vàng (để cưỡi) (obvs)'

   2.5 Săn xuống nhà phát triển ban đầu

   2.6 Hy vọng họ nhớ những gì mã phải làm

   2.7 Yêu cầu họ giải thích tất cả

3. Viết Bài kiểm tra đơn vị, Kiểm tra tích hợp, Kiểm tra hành vi, v.v ... hy vọng đảm bảo lát cắt công việc là chính xác

4. Sửa đổi mã

Tôi nghĩ bạn đã đúng khi xác định rằng các bài kiểm tra đơn vị thực sự cho thấy giá trị của chúng khi cần sửa đổi.

Tôi đồng ý với cả Daniel Hollinrake và Ewan, rằng điểm mấu chốt đầu tiên tại sao bản thử nghiệm chỉ sửa đổi của bạn hoạt động tốt cho đến nay là:

I am the sole developer on my projects and I am responsible for everything

và đó là một điểm quan trọng thứ hai có thể là:

you're producing nice clean code

Tôi không nghĩ TDD mang lại sự tăng năng suất lớn cho các lập trình viên duy nhất và nó có thể không cải thiện đáng kể chất lượng mã của bạn nếu bạn đang viết mã sạch tốt.

Tuy nhiên, TDD chắc chắn sẽ cải thiện chất lượng mã của các lập trình viên kém / thiếu kinh nghiệm / lỗi thời, đặc biệt là khi đến lúc phải sửa đổi mã mà không vi phạm bất cứ điều gì khác. Và thậm chí còn hơn thế nếu người sửa đổi mã không phải là người đã viết mã ban đầu hoặc đã vài tháng trôi qua.

Nói cách khác, tôi nghĩ TDD vừa là một cách thực hành tốt để cải thiện chất lượng mã của bạn (như bạn thừa nhận chính mình) nhưng cũng (và quan trọng hơn) là một loại hàng rào khi bạn làm việc với các lập trình viên trung bình hoặc tầm thường (nói, từ một người khác bộ phận hoặc một công ty khác) đó là một tình huống phổ biến hơn nhiều so với làm việc solo.

Đối với tôi, điều quan trọng nhất là:

Tôi là nhà phát triển duy nhất cho các dự án của mình và tôi chịu trách nhiệm về mọi thứ: Thu thập yêu cầu, thiết kế, kiến ​​trúc, thử nghiệm, triển khai, v.v. Tôi nghi ngờ đây là lý do tại sao quy trình của tôi hoạt động.

Điều này làm việc cho bạn và bạn đang sản xuất mã sạch đẹp (tôi giả sử!). Điều duy nhất tôi muốn nói bạn cần làm là tạo ra một khai thác thử nghiệm để các nhà phát triển khác có thể tham gia và tự tin thực hiện các thay đổi. Ngoài ra khai thác kiểm tra đảm bảo tính nhất quán trong hành vi của mã.

Tôi nghĩ rằng cách tiếp cận của bạn là tương tự như của tôi. Tôi thường là nhà phát triển duy nhất trong các dự án của tôi. Tôi đã thấy rằng sự đánh giá cao của TDD đã cho phép tôi viết các hàm nhỏ hơn và mã sạch hơn nhưng tôi thêm các bài kiểm tra trong khi viết mã dưới dạng khai thác thử nghiệm. Theo cách đó khi mã phát triển và thay đổi chức năng, tôi có thể tự tin một cách hợp lý khi thực hiện các thay đổi.

Một lý do thứ yếu để viết bài kiểm tra là tôi cảm thấy chúng là một dạng tài liệu. Họ có thể giải thích lý do của tôi đằng sau lý do tại sao một chức năng được tạo ra. Nhưng ở đây, tôi đang suy nghĩ nhiều hơn về Phát triển hướng hành vi.

Kiểm thử đơn vị là về việc giải quyết vấn đề duy trì mã. Mặc dù có những người nói rằng họ viết mã nhanh hơn bằng TDD chứ không phải không có, tôi không ngạc nhiên khi bạn có thể viết thêm mã mới mà không cần viết bài kiểm tra.

Các vấn đề mà tôi có thể thấy với việc thực hành viết bài kiểm tra ngay trước khi bạn thay đổi nó:

Tôi thường cần thay đổi vội vàng

Mặc dù bạn có thể tiết kiệm thời gian tổng thể bằng cách chỉ viết bài kiểm tra khi bạn cần, nhưng không phải tất cả thời gian đều như nhau. Dành 2 giờ để viết bài kiểm tra để tiết kiệm 1 giờ khi tôi ở chế độ khủng hoảng - hoàn toàn xứng đáng.

Viết bài kiểm tra cùng lúc dễ hơn khi tôi viết mã

Để viết đúng các bài kiểm tra đơn vị, bạn cần hiểu mã tôi đang kiểm tra. Tôi thường sử dụng kiểm thử đơn vị như một bài tập để hiểu, nhưng kiểm thử đơn vị mã hiện tại có thể tốn thời gian vì hiểu mã hiện tại là tốn thời gian. Ngược lại với việc viết các bài kiểm tra khi bạn viết mã và bạn sẽ thấy nó nhanh hơn nhiều vì bạn đã hiểu mã - bạn chỉ cần viết nó!

Định nghĩa của Michael Feathers về mã kế thừa là mã không có kiểm tra. Bất kể bạn có đồng ý với định nghĩa của anh ấy hay không, rõ ràng là một phần đáng kể chi phí sửa đổi mã hiện tại đang đảm bảo rằng nó vẫn hoạt động như mong đợi, thường thì thậm chí còn không rõ hành vi dự kiến ​​là gì.

Viết đơn vị kiểm tra bù đắp chi phí bằng cách mã hóa sự hiểu biết về hành vi chính xác là gì, cũng như cung cấp một cách dễ dàng cho "chúng tôi trong tương lai" để kiểm tra hành vi đó vẫn đúng.

Đây là một câu hỏi hay và FWIW tôi sẽ ném hai xu của mình.

Khoảng một năm trước tôi đã viết mã trong Salesforce, một nền tảng có cơ chế ăn sâu khiến bạn không nhất thiết phải viết bài kiểm tra trước khi viết mã , nhưng lại buộc bạn phải viết bài kiểm tra nói chung.

Cách thức hoạt động là hệ thống sẽ buộc bạn phải viết các bài kiểm tra và nó sẽ tính toán số dòng mã của bạn đã được kiểm tra theo tỷ lệ phần trăm. Nếu tất cả mã trong toàn bộ sản phẩm của bạn giảm xuống dưới 75% được kiểm tra .. Salesforce không còn làm việc nữa.

Kết quả cuối cùng của việc này là mỗi khi bạn làm bất cứ điều gì trong Salesforce, bạn phải viết hoặc cập nhật các bài kiểm tra. Mặc dù tôi chắc chắn rằng điều này có tác động rất lớn đến thị phần của Salesforce, nhưng về mặt cuộc sống của một nhà phát triển, đó là một nỗi đau lớn ở mông .

Rất nhiều thời gian bạn chỉ cố gắng để vượt qua một vé nhỏ, và sau đó thử nghiệm đến và tăng gấp đôi thời gian phát triển của bạn, cho một tính năng mà bạn chỉ biết hoạt động.

Sau đó, khái niệm vụng về TDD quét qua bộ phận của chúng tôi, ngay đến cơ sở dữ liệu của chúng tôi. Các kiến ​​trúc sư của chúng tôi muốn đẩy mạnh thử nghiệm kỹ lưỡng vào mọi khía cạnh của bộ phận CNTT của chúng tôi. Đau nhẹ ở mông, gặp đau còn lớn hơn ở mông.

Hồi đó TDD chưa bao giờ thực sự có ý nghĩa với tôi, và ngay cả bây giờ nó vẫn không. Rất nhiều chức năng tôi đã viết trong vai trò hiện tại của mình diễn ra theo một cơ chế tương tự như cơ chế mà bạn đã đề cập: trong các lát cắt dọc mà tôi tinh chỉnh cho đến khi chúng hoạt động. Khi tôi ở trong vai trò cũ đó, và bây giờ tôi vẫn thường không biết mã của mình sẽ làm gì cho đến khi tôi thực sự viết nó , vì vậy ý ​​tưởng rằng tôi có thể viết các bài kiểm tra để lái mã tôi sẽ viết. Không có ý nghĩa với tôi, là cồng kềnh, và chủ yếu là lãng phí thời gian.

Tất cả những gì đã nói, các bài kiểm tra là những điều tuyệt vời và kỳ diệu làm cho mọi thứ trở nên đúng đắn trên thế giới . Họ làm cho mã của bạn chính xác, họ đảm bảo ứng dụng của bạn thực hiện những gì bạn nghĩ và nói chung mọi thứ đều mượt mà hơn. Câu hỏi sau đó không phải là bạn viết bài kiểm tra trước khi viết mã hay sau khi viết mã, câu hỏi là bạn sẽ cam kết kiểm tra bao nhiêu thời gian. Đó là vấn đề thực sự, ít nhất là trong kinh nghiệm phát triển phần mềm của tôi. Kiểm tra tốn thời gian và tiền bạc và bạn phải thực hiện nó trong khuôn khổ lợi ích cạnh tranh.

Và vì vậy, nói chung tôi đồng ý với bạn: TDD trong thực tế là một chút vụng về và cồng kềnh. Tại thời điểm đó, bạn cần ghi nhớ những gì hoạt động tốt nhất trong tình huống hiện tại của bạn . Nếu bạn đang viết mã quan trọng, chỉ cần đảm bảo rằng nó đã được kiểm tra nói chung. Nếu bạn có thời gian, hãy thử TDD và xem liệu nó có thêm gì vào quy trình không.

Tôi không thể đề nghị phương pháp của bạn.

Nếu tôi sử dụng cách tiếp cận của bạn, nó sẽ là ví dụ như sau (nhà là ứng dụng):

1. Tôi bắt đầu xây dựng một ngôi nhà cho gia đình tôi như một thợ hồ với một số kiến ​​thức hoặc là người mới bắt đầu.
2. Tôi biết các yêu cầu như phòng trẻ em, phòng khách và bắt đầu xây dựng ngôi nhà "nguyên mẫu" của mình.
3. Hơn một vài lần sau đó ngôi nhà "nguyên mẫu" của bạn đã hoàn thành.
4. Tôi bắt đầu tìm kiếm nếu cấu trúc đủ ổn định bằng tay. Vì vậy, tôi chọn rất nhiều trọng lượng và mang nó vào các phòng khác nhau ở tầng một. Để đảm bảo khi tôi ngồi trong phòng với gia đình, trần nhà không bị vỡ. Nhưng nó phá vỡ và tôi bắt đầu tái cấu trúc. Đầu tiên làm sạch tất cả các khối lượng lên. Hơn xây dựng nó mới và kiểm tra lại một cách thủ công cho đến khi nó đủ ổn định.
5. Hơn tôi chuyển đến với gia đình của tôi. Tất cả đều ổn.
6. Một con sâu bướm sau đó anh em họ và cha mẹ của tôi sẽ đến thăm chúng tôi. Nhưng trước khi họ có thể vào nhà chúng tôi, họ cần phải trả cho một kiến ​​trúc sư và kỹ sư dân sự để đảm bảo trần nhà không bị vỡ khi chúng tôi ngồi trong một trong những phòng ở tầng một.
7. Kiến trúc sư và kỹ sư xây dựng có rất nhiều công việc vì họ không có gì để bắt đầu. Vì vậy, họ cần phải đi vào nhà tôi và xem cách tôi xây dựng nó.
8. Và một lần nữa nó không đủ ổn định. Vì vậy, họ phải tái cấu trúc mặt bằng của tầng đầu tiên.
9. Nhưng sau đó mọi thứ đều ổn và tất cả đều có thể vào nhà tôi một cách an toàn.

Vì vậy, cách tiếp cận của bạn tốn rất nhiều thời gian và rất nhiều kiến ​​thức trước khi tôi xây dựng ngôi nhà với cách tiếp cận của bạn. Hoặc nó mất một loạt thời gian! Ngoài ra, nó không phải là quý ông đẹp để cho các bài kiểm tra viết khác cho mã của bạn khi có yêu cầu đã thay đổi.

Vì vậy, có một cách tiếp cận tốt hơn mà không cần lập trình một "nguyên mẫu" và bắt đầu tái cấu trúc. Thay vì lập trình một nguyên mẫu "hãy tạo một Thiết kế với UML của Ứng dụng của bạn như sau.

1. Tạo sơ đồ UseCase. Bạn có thể sử dụng draw.io để bắt đầu.
2. Hơn tạo sơ đồ EPK dựa trên UseCase của bạn để xác định hành vi. (BEHAVIOR của Ứng dụng của bạn) Nhanh hơn để tái cấu trúc hơn so với tái cấu trúc một nguyên mẫu được mã hóa. Đặc biệt là khi bạn là người mới bắt đầu.
3. Tạo một sơ đồ lớp. (CẤU TRÚC CỦA Ứng dụng của bạn)
4. Xác định nơi bạn có thể gặp rắc rối trong việc thực hiện hành vi.
5. Viết cho đó một nguyên mẫu đơn giản với khoảng 10 hoặc 20 dòng mã để xác định cách bạn có thể thực hiện hành vi này. Tốt cho người mới bắt đầu. Hoặc xem hướng dẫn, xem mã nguồn của các ứng dụng ví dụ khác ngoài kia. Làm thế nào họ giải quyết nó.
6. Hơn bắt đầu mã hóa. Nắm bắt các bài kiểm tra thành công của UseCase của bạn. Điều này có thể được thực hiện theo những cách khác nhau. Đầu tiên tạo tất cả Cấu trúc cần thiết cho thử nghiệm và UseCase đó. Khi sử dụng Enterprise Architekt , cấu trúc có thể được tạo cho bạn. Dựa trên sơ đồ của bạn. Hoặc tạo cấu trúc trong khi nối dây Kiểm tra. Vì vậy, không có lỗi biên dịch xuất hiện. Đề cập ở đây là bạn CHỈ cần kiểm tra BEHAVIOR của ứng dụng của bạn. UseCase bạn có.
7. Hơn Thực hiện hành vi của UseCase của bạn.
8. Sau khi UseCase thành công bắt đầu viết Kiểm tra cho các ngoại lệ. Và cảm giác luôn tốt khi bạn thấy màu xanh lục khi các bài kiểm tra của bạn hợp lệ;)
9. Và bạn đã hoàn thành.

Chắc chắn cách tiếp cận này cũng cần một số Kiến thức về UML nhưng nó rất nhanh để học. Và việc đổi tên Class hoặc di chuyển mũi tên trong digram luôn nhanh hơn so với thực hiện trong IDE của bạn. Nhưng việc học sử dụng các khung kiểm tra sẽ mệt mỏi hơn khi bắt đầu. Tốt nhất là ở đây để xem thử chạy các dự án nguồn mở và xem cách chúng hoạt động. Nhưng khi bạn có một ứng dụng điều khiển thử nghiệm, ứng dụng tiếp theo sẽ nhanh hơn nhiều. Và tôi nghĩ rằng đó là một cảm giác tốt để biết mọi thứ hoạt động tốt.

Vì vậy, tôi chỉ bỏ phiếu cho các phương pháp tiếp cận vì chúng rất tốn thời gian cho người mới bắt đầu và sau tất cả là không tốt. Để có một đường viền rõ ràng giữa cấu trúc của bạn và hành vi, bạn có thể sử dụng Thiết kế hướng tên miền và trong Sắp xếp rất Miền với hai Gói (một gói có cấu trúc và hành vi được đặt tên khác). Ngoài ra cho các bài kiểm tra của bạn. Ví dụ kiểm tra đơn giản ra này Ví dụ viết bằng java.

Mã tôi đang viết hoạt động. Nó hoạt động vì tôi đang thử nó bằng tay.

Bạn đã kiểm tra thủ công từng nhánh có thể của các điều kiện của bạn sau khi thay đổi ít? Mất bao lâu trên vòng phản hồi của thử nghiệm thủ công của bạn. Làm thế nào gần với vòng phản hồi bạn nhận được với các bài kiểm tra tự động.

Kiểm tra tự động (không quan trọng kiểm tra trước hay không) làm cho bạn đi nhanh - bằng cách cung cấp vòng phản hồi nhanh hơn về mã của bạn.

Bạn có chắc chắn sẽ nhớ kiểm tra một số điều kiện theo cách thủ công sau sáu tháng - vui lòng không nói rằng bạn sẽ ghi lại tất cả các điều kiện quan trọng để kiểm tra - bởi vì việc viết loại tài liệu / nhận xét tương đương với kiểm tra viết (tài liệu thực thi)

• Chọn một lát dọc của công việc

• Phát triển một nguyên mẫu hoạt động

• Tái cấu trúc cho đến khi mọi thứ đều tốt đẹp và gọn gàng

Và một lần nữa: trong khi tái cấu trúc, bạn có tự kiểm tra tất cả logic bị ảnh hưởng bởi tái cấu trúc không? Mất bao lâu để kiểm tra thay đổi cấu trúc lại? Nếu tái cấu trúc phá vỡ một số mã, bạn mất bao lâu để tìm ra lý do cho việc phá vỡ?

• Ngồi lại đánh giá cao mã RẮN và mã có thể kiểm tra đẹp mà tôi đã viết.

Mã đẹp và sạch bạn rất thích là rất chủ quan. Mã của bạn có thể được sạch sẽ và hợp lý cho bạn. Phương pháp tốt nhất để kiểm tra xem mã của bạn có thực sự dễ đọc, dễ hiểu và có thể kiểm tra hay không là các bài kiểm tra và đánh giá mã được thực hiện bởi các nhà phát triển khác.

Bạn thấy cách của mình rất hiệu quả chỉ vì bạn chỉ là nhà phát triển làm việc với mã, và, tôi nghĩ, bởi vì bạn chỉ bắt đầu làm việc trong dự án này (Dự án này bạn làm việc bao nhiêu tuổi? 6 - 8 tháng?).
Bạn vẫn nhớ mọi thứ bạn đã viết và bạn có thể nhận ra một lý do cho các vấn đề có thể xảy ra. Tôi khá chắc chắn rằng bạn sẽ bắt đầu viết bài kiểm tra từ đầu sau 2 - 3 năm dự án của bạn - bởi vì bạn muốn chắc chắn rằng bạn không quên bất cứ điều gì.

Nếu bạn không bao giờ phạm sai lầm, bạn không thực sự cần kiểm tra. Hầu hết các nhà phát triển đều mắc lỗi, nhưng nếu bạn không bao giờ làm điều đó và bạn tự tin rằng bạn sẽ không bao giờ mắc lỗi trong tương lai (và bạn là người duy nhất trong dự án), thực sự không có lý do gì để lãng phí thời gian viết bài kiểm tra.

Nhưng giải pháp của bạn là một nửa vì bạn đang đề xuất viết bài kiểm tra khi thay đổi mã, nhưng đồng thời phương pháp của bạn cho rằng bạn sẽ không bao giờ mắc lỗi khi bạn quyết định phần nào của mã để viết bài kiểm tra. Điều này chỉ hoạt động nếu bạn luôn hiểu hoàn hảo những thay đổi có thể ảnh hưởng đến. Tôi nghĩ rằng nhiều nhà phát triển phổ biến (tất nhiên không phải bạn!) Đã có kinh nghiệm để thực hiện thay đổi, và sau đó một thử nghiệm ở đâu đó bất ngờ thất bại, vì bạn đã phạm sai lầm.

Tất nhiên kiến ​​trúc tốt, các nguyên tắc RẮN, v.v ... nên ngăn chặn điều này xảy ra, nhưng hầu hết các nhà phát triển không hoàn hảo, và đây là lý do tại sao các thử nghiệm trên toàn hệ thống đều có giá trị.