Tại sao các bài kiểm tra đơn vị không được xem là xấu?

Trong một số tổ chức, rõ ràng, một phần của quy trình phát hành phần mềm là sử dụng thử nghiệm đơn vị, nhưng tại bất kỳ thời điểm nào, tất cả các thử nghiệm đơn vị đều phải vượt qua. Ví dụ, có thể có một số màn hình hiển thị tất cả các bài kiểm tra đơn vị chuyển sang màu xanh lục - được cho là tốt.

Cá nhân, tôi nghĩ rằng đây không phải là như vậy vì những lý do sau:

1. Nó thúc đẩy ý tưởng rằng mã phải hoàn hảo và không có lỗi nào tồn tại - điều mà trong thế giới thực chắc chắn là không thể đối với một chương trình có kích thước bất kỳ.

2. Thật thiếu sót khi nghĩ đến các bài kiểm tra đơn vị sẽ thất bại. Hoặc chắc chắn đưa ra các bài kiểm tra đơn vị sẽ khó để sửa chữa.

3. Nếu tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị đều vượt qua, thì không có bức tranh lớn nào về trạng thái của phần mềm tại bất kỳ thời điểm nào. Không có lộ trình / mục tiêu.

4. Nó ngăn chặn các bài kiểm tra đơn vị viết lên trước - trước khi thực hiện.

Tôi thậm chí sẽ đề nghị rằng ngay cả việc phát hành phần mềm với các bài kiểm tra đơn vị không thành công là không cần thiết. Ít nhất thì bạn cũng biết rằng một số khía cạnh của phần mềm có những hạn chế.

Am i thiếu cái gì ở đây? Tại sao các tổ chức mong đợi tất cả các bài kiểm tra đơn vị vượt qua? Đây không phải là sống trong một thế giới giấc mơ sao? Và nó không thực sự ngăn cản sự hiểu biết thực sự về mã?

Câu hỏi này chứa IMHO một số quan niệm sai lầm, nhưng vấn đề chính tôi muốn tập trung vào là nó không phân biệt giữa các nhánh phát triển địa phương, thân cây, dàn dựng hoặc phát hành các nhánh.

Trong một nhánh dev địa phương, nó có khả năng có một số bài kiểm tra đơn vị thất bại bất cứ lúc nào. Trong thân cây, nó chỉ được chấp nhận ở một mức độ nào đó, nhưng đã là một chỉ số mạnh để sửa chữa mọi thứ càng sớm càng tốt. Lưu ý rằng các bài kiểm tra đơn vị thất bại trong thân cây có thể làm phiền các thành viên còn lại trong nhóm, vì họ yêu cầu mọi người kiểm tra xem liệu thay đổi mới nhất của anh ấy / cô ấy có gây ra lỗi không.

Trong một nhánh dàn dựng hoặc phát hành, các thử nghiệm thất bại là "báo động đỏ", cho thấy đã có một cái gì đó hoàn toàn sai với một số thay đổi, khi nó được sáp nhập từ thân cây vào nhánh phát hành.

Tôi thậm chí sẽ đề nghị rằng ngay cả việc phát hành phần mềm với các bài kiểm tra đơn vị không thành công là không cần thiết.

Phát hành phần mềm với một số lỗi đã biết dưới mức nghiêm trọng nhất định không hẳn là xấu. Tuy nhiên, những trục trặc đã biết không nên gây ra một bài kiểm tra đơn vị thất bại. Mặt khác, sau mỗi lần chạy thử đơn vị, người ta sẽ phải xem xét 20 thử nghiệm đơn vị thất bại và kiểm tra từng cái một nếu lỗi có thể chấp nhận được hay không. Điều này trở nên cồng kềnh, dễ bị lỗi và loại bỏ một phần rất lớn trong khía cạnh tự động hóa của các bài kiểm tra đơn vị.

Nếu bạn thực sự có các bài kiểm tra về các lỗi đã biết, có thể chấp nhận được, hãy sử dụng tính năng vô hiệu hóa / bỏ qua công cụ kiểm tra đơn vị của bạn (để bạn không chạy theo mặc định, chỉ theo yêu cầu). Ngoài ra, thêm một vé ưu tiên thấp vào trình theo dõi vấn đề của bạn, để vấn đề không bị lãng quên.

... tất cả các bài kiểm tra đơn vị chuyển qua màu xanh lá cây - được cho là tốt.

Nó là tốt Không "được cho là" về nó.

Nó thúc đẩy ý tưởng rằng mã phải hoàn hảo và không có lỗi nào tồn tại - điều mà trong thế giới thực chắc chắn là không thể đối với một chương trình có kích thước bất kỳ.

Không. Điều đó chứng tỏ rằng bạn đã kiểm tra mã cũng như bạn có thể tính đến thời điểm này. Hoàn toàn có thể là các xét nghiệm của bạn không bao gồm mọi trường hợp. Nếu vậy, bất kỳ lỗi nào cuối cùng cũng sẽ xuất hiện trong các báo cáo lỗi và bạn sẽ viết các bài kiểm tra [không] để tái tạo các vấn đề và sau đó sửa ứng dụng để các bài kiểm tra vượt qua.

Thật thiếu sót khi nghĩ đến các bài kiểm tra đơn vị sẽ thất bại.

Thất bại hoặc kiểm tra tiêu cực đặt ra giới hạn vững chắc cho những gì ứng dụng của bạn sẽ và không chấp nhận. Hầu hết các chương trình tôi biết sẽ phản đối một "ngày" của ngày 30 tháng 2. Ngoài ra, Nhà phát triển, loại sáng tạo mà chúng tôi đang có, không muốn phá vỡ "những đứa con của họ". Kết quả tập trung vào các trường hợp "đường dẫn hạnh phúc" dẫn đến các ứng dụng dễ vỡ bị hỏng - thường.

Để so sánh suy nghĩ của Nhà phát triển và Người kiểm tra:

• Nhà phát triển dừng lại ngay khi mã thực hiện những gì họ muốn.
• Người kiểm tra dừng lại khi họ không còn có thể làm cho mã bị hỏng.

Đây là những quan điểm hoàn toàn khác nhau và một quan điểm rất khó cho nhiều Nhà phát triển để điều hòa.

Hoặc chắc chắn đưa ra các bài kiểm tra đơn vị sẽ khó để sửa chữa.

Bạn không viết bài kiểm tra để làm việc cho chính mình. Bạn viết các bài kiểm tra để đảm bảo rằng mã của bạn đang thực hiện những gì nó phải làm và quan trọng hơn là nó tiếp tục làm những gì nó phải làm sau khi bạn thay đổi triển khai nội bộ.

• Gỡ lỗi "chứng minh" rằng mã thực hiện những gì bạn muốn ngày hôm nay .
• Các thử nghiệm "chứng minh" rằng mã vẫn thực hiện những gì bạn muốn theo thời gian .

Nếu tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị đều vượt qua, thì không có bức tranh lớn nào về trạng thái của phần mềm tại bất kỳ thời điểm nào. Không có lộ trình / mục tiêu.

Thử nghiệm "hình ảnh" duy nhất mang lại cho bạn là một ảnh chụp nhanh mà mã "hoạt động" tại thời điểm mà nó được thử nghiệm. Làm thế nào nó phát triển sau đó là một câu chuyện khác nhau.

Nó ngăn chặn các bài kiểm tra đơn vị viết lên trước - trước khi thực hiện.

Đó chính xác là những gì bạn nên làm. Viết một thử nghiệm thất bại (vì phương thức mà thử nghiệm chưa được triển khai) sau đó viết mã phương thức để làm cho phương thức hoạt động và do đó, vượt qua thử nghiệm. Đó là khá nhiều mấu chốt của Phát triển dựa trên thử nghiệm.

Tôi thậm chí sẽ đề nghị rằng ngay cả việc phát hành phần mềm với các bài kiểm tra đơn vị không thành công là không cần thiết. Ít nhất thì bạn cũng biết rằng một số khía cạnh của phần mềm có những hạn chế.

Phát hành mã với các bài kiểm tra bị hỏng có nghĩa là một phần chức năng của nó không còn hoạt động như trước. Đó có thể là hành động có chủ ý vì bạn đã sửa lỗi hoặc cải tiến một tính năng (nhưng sau đó bạn nên thay đổi thử nghiệm trước để nó thất bại, sau đó mã hóa sửa chữa / nâng cao, làm cho quá trình thử nghiệm hoạt động trong quá trình). Quan trọng hơn: tất cả chúng ta đều là Con người và chúng ta phạm sai lầm. Nếu bạn phá vỡ mã, thì bạn nên phá vỡ các bài kiểm tra và những bài kiểm tra bị hỏng đó sẽ đặt chuông báo thức.

Đây không phải là sống trong một thế giới giấc mơ sao?

Nếu bất cứ điều gì, nó sống trong thế giới thực , thừa nhận rằng phát triển là không phải toàn trí cũng không infallable, mà chúng ta làm sai lầm và rằng chúng ta cần một mạng lưới an toàn để đón chúng tôi nếu và khi chúng ta làm lộn xộn lên!
Nhập các bài kiểm tra.

Và nó không thực sự ngăn cản sự hiểu biết thực sự về mã?

Có lẽ. Bạn không nhất thiết phải hiểu việc thực hiện một cái gì đó để viết bài kiểm tra cho nó (đó là một phần quan điểm của chúng). Các thử nghiệm xác định hành vi và giới hạn của ứng dụng và đảm bảo rằng các thử nghiệm đó giữ nguyên trừ khi bạn cố tình thay đổi chúng.

Tại sao các bài kiểm tra đơn vị không được xem là xấu?

Họ không - phát triển theo hướng thử nghiệm được xây dựng dựa trên khái niệm thử nghiệm thất bại. Không kiểm tra đơn vị để thúc đẩy phát triển, không kiểm tra chấp nhận để lái một câu chuyện ....

Những gì bạn đang thiếu là bối cảnh ; các bài kiểm tra đơn vị được phép thất bại ở đâu?

Câu trả lời thông thường là các bài kiểm tra đơn vị chỉ được phép thất bại trong các hộp cát riêng.

Khái niệm cơ bản là thế này: trong một môi trường mà các thử nghiệm thất bại được chia sẻ, phải mất thêm nỗ lực để hiểu liệu một thay đổi đối với mã sản xuất có đưa ra một lỗi mới hay không. Sự khác biệt giữa 0 và không 0 là dễ dàng phát hiện và quản lý hơn nhiều so với sự khác biệt giữa N và không phải là N.

Hơn nữa, giữ cho mã được chia sẻ sạch sẽ có nghĩa là các nhà phát triển có thể tiếp tục nhiệm vụ. Khi tôi hợp nhất mã của bạn, tôi không cần phải thay đổi bối cảnh từ vấn đề tôi đang được trả tiền để giải quyết để hiệu chỉnh sự hiểu biết của tôi về việc có bao nhiêu bài kiểm tra sẽ thất bại. Nếu mã được chia sẻ vượt qua tất cả các thử nghiệm, bất kỳ lỗi nào xuất hiện khi tôi hợp nhất trong các thay đổi của mình phải là một phần của sự tương tác giữa mã của tôi và đường cơ sở sạch hiện có.

Tương tự như vậy, trong khi lên máy bay, một nhà phát triển mới có thể trở nên hiệu quả nhanh hơn, vì họ không cần phải dành thời gian để khám phá những thử nghiệm thất bại nào là "chấp nhận được".

Nói chính xác hơn: kỷ luật là các bài kiểm tra chạy trong quá trình xây dựng phải vượt qua.

Có điều, tốt nhất tôi có thể nói, không có gì sai khi có các bài kiểm tra thất bại bị vô hiệu hóa .

Chẳng hạn, trong môi trường "tích hợp liên tục", bạn sẽ chia sẻ mã với nhịp điệu cao. Tích hợp thường không nhất thiết có nghĩa là các thay đổi của bạn phải được phát hành sẵn sàng. Có một loạt các kỹ thuật triển khai tối ngăn chặn lưu lượng truy cập được phát hành vào các phần của mã cho đến khi chúng sẵn sàng.

Những kỹ thuật tương tự cũng có thể được sử dụng để vô hiệu hóa các bài kiểm tra thất bại.

Một trong những bài tập tôi đã trải qua khi phát hành điểm là đối phó với việc phát triển một sản phẩm với nhiều thử nghiệm thất bại. Câu trả lời chúng tôi đưa ra chỉ đơn giản là thông qua bộ phần mềm, vô hiệu hóa các bài kiểm tra thất bại và ghi lại từng tài liệu . Điều đó cho phép chúng tôi nhanh chóng đạt đến điểm mà tất cả các thử nghiệm được kích hoạt đã vượt qua và nhà tài trợ / chủ sở hữu vàng / quản lý mục tiêu đều có thể thấy những giao dịch mà chúng tôi đã thực hiện để đạt được điểm đó và có thể đưa ra quyết định sáng suốt về việc dọn dẹp so với công việc mới.

Tóm lại: có những kỹ thuật khác để theo dõi công việc không được thực hiện ngoài việc để lại một loạt các bài kiểm tra thất bại trong bộ phần mềm đang chạy.

Có rất nhiều câu trả lời tuyệt vời, nhưng tôi muốn thêm một góc độ khác mà tôi tin là vẫn chưa được đề cập đầy đủ: chính xác điểm quan trọng của việc kiểm tra là gì.

Kiểm tra đơn vị không có ở đó để kiểm tra xem mã của bạn không có lỗi.

Tôi nghĩ rằng đây là quan niệm sai lầm chính. Nếu đây là vai trò của họ, bạn thực sự mong đợi sẽ có những bài kiểm tra thất bại ở mọi nơi. Nhưng thay vì,

Kiểm tra đơn vị kiểm tra xem mã của bạn làm những gì bạn nghĩ nó làm.

Trong các trường hợp cực đoan, nó có thể bao gồm kiểm tra rằng các lỗi đã biết không được sửa. Vấn đề là phải kiểm soát cơ sở mã của bạn và tránh những thay đổi ngẫu nhiên. Khi bạn thực hiện một thay đổi, nó vẫn ổn và thực sự dự kiến ​​sẽ phá vỡ một số thử nghiệm - bạn đang thay đổi hành vi của mã. Bài kiểm tra mới bị phá vỡ bây giờ là một dấu vết tốt đẹp của những gì bạn đã thay đổi. Kiểm tra xem tất cả các phá vỡ có phù hợp với những gì bạn muốn từ thay đổi của bạn. Nếu vậy, chỉ cần cập nhật các bài kiểm tra và tiếp tục. Nếu không - tốt, mã mới của bạn chắc chắn có lỗi, hãy quay lại và sửa nó trước khi gửi!

Bây giờ, tất cả các công việc trên chỉ hoạt động nếu tất cả các thử nghiệm đều có màu xanh lá cây, cho kết quả dương tính mạnh mẽ: đây chính xác là cách mã hoạt động. Các xét nghiệm đỏ không có tài sản đó. "Đây là những gì mã này không làm" hiếm khi là một thông tin hữu ích.

Kiểm tra chấp nhận có thể là những gì bạn đang tìm kiếm.

Có những thứ như thử nghiệm chấp nhận. Bạn có thể viết một tập các bài kiểm tra phải hoàn thành để gọi cột mốc tiếp theo. Chúng có thể có màu đỏ, vì đó là những gì chúng được thiết kế cho. Nhưng chúng là những thứ rất khác so với các bài kiểm tra đơn vị và cũng không thể thay thế chúng.

Tôi xem nó như là phần mềm tương đương với hội chứng cửa sổ bị hỏng .

Các thử nghiệm làm việc cho tôi biết rằng mã có chất lượng nhất định và chủ sở hữu của mã quan tâm đến nó.

Về thời điểm bạn nên quan tâm đến chất lượng, điều đó phụ thuộc vào chi nhánh / kho lưu trữ mã nguồn mà bạn đang làm việc. Mã dev rất có thể có các bài kiểm tra bị hỏng cho thấy công việc đang tiến triển (hy vọng!).

Các thử nghiệm bị hỏng trên một nhánh / kho lưu trữ cho một hệ thống trực tiếp sẽ ngay lập tức đặt chuông báo thức. Nếu các bài kiểm tra bị hỏng được phép tiếp tục thất bại hoặc nếu chúng được đánh dấu vĩnh viễn là "bỏ qua" - hy vọng số lượng của chúng sẽ tăng lên theo thời gian. Nếu những điều này không được xem xét thường xuyên, tiền lệ sẽ được đặt ra rằng việc các bài kiểm tra bị hỏng sẽ không còn nữa.

Các thử nghiệm bị hỏng được xem rất phổ biến ở nhiều cửa hàng để có một hạn chế về việc liệu mã bị hỏng thậm chí có thể được cam kết hay không .

Đây là sai lầm logic cơ bản:

Nếu nó tốt khi tất cả các bài kiểm tra vượt qua, thì nó phải xấu nếu có bất kỳ bài kiểm tra nào thất bại.

Với bài kiểm tra đơn vị, nó LÀ tốt khi tất cả các bài kiểm tra qua. Nó C GNG TỐT khi thử nghiệm thất bại. Hai người không cần phải đối lập.

Thử nghiệm thất bại là một vấn đề đã được bắt gặp bởi công cụ của bạn trước khi nó đến tay người dùng. Đó là một cơ hội để sửa chữa một lỗi trước khi nó được xuất bản. Và đó là một điều tốt.

Câu trả lời của Phill W rất hay. Tôi không thể thay thế nó.

Tuy nhiên, tôi muốn tập trung vào một phần khác có thể là một phần của sự nhầm lẫn.

Trong một số tổ chức, rõ ràng, một phần của quy trình phát hành phần mềm là sử dụng thử nghiệm đơn vị, nhưng tại bất kỳ thời điểm nào, tất cả các thử nghiệm đơn vị đều phải vượt qua

"Tại bất kỳ thời điểm nào" đang nói quá về trường hợp của bạn. Điều quan trọng là các bài kiểm tra đơn vị vượt qua sau khi một thay đổi nhất định đã được thực hiện, trước khi bạn bắt đầu thực hiện một thay đổi khác.
Đây là cách bạn theo dõi những thay đổi gây ra lỗi phát sinh. Nếu các kiểm tra đơn vị bắt đầu thất bại sau khi thực hiện thay đổi 25 nhưng trước khi thực hiện thay đổi 26, thì bạn biết rằng thay đổi 25 đã gây ra lỗi.

Trong quá trình thực hiện thay đổi, tất nhiên các bài kiểm tra đơn vị có thể thất bại; tat rất nhiều phụ thuộc vào sự thay đổi lớn như thế nào. Nếu tôi đang phát triển một tính năng cốt lõi, không chỉ là một tinh chỉnh nhỏ, tôi có thể sẽ phá vỡ các thử nghiệm trong một thời gian cho đến khi tôi hoàn thành việc thực hiện phiên bản logic mới của mình.

Điều này có thể tạo ra xung đột như các quy tắc nhóm. Tôi thực sự đã gặp điều này một vài tuần trước:

• Mỗi cam kết / đẩy gây ra một bản dựng. Việc xây dựng không bao giờ thất bại (nếu có hoặc bất kỳ thử nghiệm nào thất bại, nhà phát triển cam kết bị đổ lỗi).
• Mọi nhà phát triển dự kiến ​​sẽ thúc đẩy các thay đổi của họ (ngay cả khi không đầy đủ) vào cuối ngày, vì vậy các nhóm trưởng có thể viết mã đánh giá vào buổi sáng.

Hoặc là quy tắc sẽ tốt. Nhưng cả hai quy tắc không thể làm việc cùng nhau. Nếu tôi được chỉ định một thay đổi lớn mất vài ngày để hoàn thành, tôi sẽ không thể tuân thủ cả hai quy tắc cùng một lúc. Trừ khi tôi sẽ nhận xét những thay đổi của tôi mỗi ngày và chỉ cam kết chúng không bị lỗi sau khi mọi thứ đã được thực hiện; đó chỉ là công việc vô nghĩa.

Trong kịch bản này, vấn đề ở đây không phải là các bài kiểm tra đơn vị không có mục đích; đó là công ty có những kỳ vọng không thực tế . Quy tắc tùy ý của họ không bao gồm tất cả các trường hợp và việc không tuân thủ các quy tắc được coi là thất bại của nhà phát triển hơn là lỗi quy tắc (trong trường hợp của tôi).

Nếu bạn không sửa tất cả các bài kiểm tra đơn vị, bạn có thể nhanh chóng vào trạng thái nơi không ai sửa bất kỳ bài kiểm tra bị hỏng nào.

1. Không chính xác vì vượt qua các bài kiểm tra đơn vị không cho thấy mã là hoàn hảo

2. Thật không phù hợp khi đưa ra mã rất khó kiểm tra, điều này tốt từ quan điểm thiết kế

3. Bảo hiểm mã có thể giúp đỡ ở đó (mặc dù nó không phải là thuốc chữa bách bệnh). Ngoài ra kiểm tra đơn vị chỉ là một khía cạnh của kiểm tra - bạn cũng muốn kiểm tra tích hợp / chấp nhận.

Để thêm một vài điểm cho câu trả lời đã tốt ...

nhưng tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị phải vượt qua

Điều này cho thấy sự thiếu hiểu biết về một quá trình phát hành. Một lỗi thử nghiệm có thể chỉ ra một tính năng được lên kế hoạch theo TDD chưa được triển khai; hoặc nó có thể chỉ ra một vấn đề đã biết có kế hoạch khắc phục được phát hành trong tương lai; hoặc nó có thể chỉ đơn giản là một cái gì đó mà quản lý đã quyết định điều này không đủ quan trọng để khắc phục vì khách hàng không có khả năng nhận thấy. Điều quan trọng tất cả những chia sẻ này là quản lý đã đưa ra lời kêu gọi về sự thất bại.

Nó thúc đẩy ý tưởng rằng mã phải hoàn hảo và không có lỗi nào tồn tại - điều mà trong thế giới thực chắc chắn là không thể đối với một chương trình có kích thước bất kỳ.

Các câu trả lời khác đã bao gồm các giới hạn của thử nghiệm.

Tôi không hiểu tại sao bạn nghĩ loại bỏ lỗi là một nhược điểm. Nếu bạn không muốn cung cấp mã mà bạn đã kiểm tra (với khả năng tốt nhất của bạn) sẽ làm những gì nó được yêu cầu, tại sao bạn thậm chí làm việc trong phần mềm?

Nếu tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị đều vượt qua, thì không có bức tranh lớn nào về trạng thái của phần mềm tại bất kỳ thời điểm nào. Không có lộ trình / mục tiêu.

Tại sao phải có lộ trình?

Kiểm tra đơn vị ban đầu kiểm tra xem chức năng có hoạt động không, nhưng sau đó (như kiểm tra hồi quy) kiểm tra xem bạn có vô tình làm hỏng bất cứ thứ gì không. Đối với tất cả các tính năng với các bài kiểm tra đơn vị hiện có, không có lộ trình . Mọi tính năng đều được biết là hoạt động (trong giới hạn kiểm tra). Nếu mã đó kết thúc, nó không có lộ trình vì không cần thêm công việc về nó.

Là kỹ sư chuyên nghiệp, chúng ta cần tránh bẫy mạ vàng. Người chơi có thể đủ khả năng để lãng phí thời gian mày mò quanh các cạnh với một cái gì đó hoạt động. Là chuyên gia, chúng tôi cần cung cấp một sản phẩm. Điều đó có nghĩa là chúng tôi có một cái gì đó hoạt động, xác minh rằng nó đang hoạt động và chuyển sang công việc tiếp theo.

Nó thúc đẩy ý tưởng rằng mã phải hoàn hảo và không có lỗi nào tồn tại - điều mà trong thế giới thực chắc chắn là không thể đối với một chương trình có kích thước bất kỳ.

Không đúng. Tại sao bạn nghĩ rằng nó không thể? đây là ví dụ cho chương trình mà nó hoạt động:

public class MyProgram {
  public boolean alwaysTrue() {
    return true;
  }

  @Test
  public void testAlwaysTrue() {
    assert(alwaysTrue() == true);
  }
}

Thật thiếu sót khi nghĩ đến các bài kiểm tra đơn vị sẽ thất bại. Hoặc chắc chắn đưa ra các bài kiểm tra đơn vị sẽ khó để sửa chữa.

Trong trường hợp đó, nó có thể không phải là thử nghiệm đơn vị, nhưng thử nghiệm tích hợp nếu nó phức tạp

Nếu tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị đều vượt qua, thì không có bức tranh lớn nào về trạng thái của phần mềm tại bất kỳ thời điểm nào. Không có lộ trình / mục tiêu.

đúng, nó được gọi là kiểm tra đơn vị vì một lý do, nó kiểm tra một đơn vị mã nhỏ.

Nó ngăn chặn các bài kiểm tra đơn vị viết lên trước - trước khi thực hiện.

Nhà phát triển sẽngăn chặn viết bất kỳ bài kiểm tra nào nếu họ không hiểu lợi ích của nóbởi bản chất của họ (trừ khi họ đến từ QA)

Nó thúc đẩy ý tưởng rằng mã phải hoàn hảo và không có lỗi nào tồn tại

Chắc chắn là không. Nó thúc đẩy ý tưởng rằng các bài kiểm tra của bạn không nên thất bại, không hơn không kém. Giả sử rằng có các bài kiểm tra (thậm chí rất nhiều trong số họ) nói bất cứ điều gì về "hoàn hảo" hoặc "không có lỗi" là sai lầm. Quyết định mức độ nông hoặc sâu của các bài kiểm tra của bạn là một phần quan trọng trong việc viết các bài kiểm tra tốt và lý do tại sao chúng tôi có các loại bài kiểm tra riêng biệt (bài kiểm tra "đơn vị", bài kiểm tra tích hợp, "kịch bản" theo nghĩa dưa chuột, v.v.).

Thật thiếu sót khi nghĩ đến các bài kiểm tra đơn vị sẽ thất bại. Hoặc chắc chắn đưa ra các bài kiểm tra đơn vị sẽ khó để sửa chữa.

Trong phát triển theo hướng thử nghiệm, điều bắt buộc là mọi thử nghiệm đơn vị đều thất bại trước, trước khi bắt đầu viết mã. Nó được gọi là "chu trình đỏ-xanh" (hay "chu trình tái cấu trúc đỏ-xanh") vì lý do này.

• Nếu không thử nghiệm thất bại, bạn không biết liệu mã có thực sự được thử nghiệm hay không. Hai có thể không liên quan gì cả.
• Bằng cách thay đổi mã để chính xác làm cho thử nghiệm chuyển từ màu đỏ sang màu xanh lá cây, không hơn không kém, bạn có thể khá tự tin rằng mã của bạn làm những gì nó phải làm, và không nhiều hơn nữa (mà bạn có thể không bao giờ cần).

Nếu tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị đều vượt qua, thì không có bức tranh lớn nào về trạng thái của phần mềm tại bất kỳ thời điểm nào. Không có lộ trình / mục tiêu.

Các xét nghiệm là loại mục tiêu vi mô hơn. Trong phát triển dựa trên thử nghiệm, lập trình viên sẽ viết một thử nghiệm (số ít) trước, và sau đó có một mục tiêu rõ ràng để thực hiện một số mã; sau đó là bài kiểm tra tiếp theo, v.v.

Chức năng của các bài kiểm tra là không có ở đó hoàn toàn trước khi mã được viết.

Khi được thực hiện chính xác, bằng ngôn ngữ và với thư viện thử nghiệm phù hợp với phương pháp này, điều này thực sự có thể tăng tốc độ phát triển một cách ồ ạt, vì các thông báo lỗi (ngoại lệ / stacktraces) có thể trực tiếp hướng nhà phát triển đến nơi anh ta cần thực hiện công việc kế tiếp.

Nó ngăn chặn các bài kiểm tra đơn vị viết lên trước - trước khi thực hiện.

Tôi không thấy tuyên bố này sẽ đúng như thế nào. Bài kiểm tra viết lý tưởng nên là một phần của việc thực hiện.

Am i thiếu cái gì ở đây? Tại sao các tổ chức mong đợi tất cả các bài kiểm tra đơn vị vượt qua?

Bởi vì các tổ chức mong đợi các bài kiểm tra có liên quan đến mã. Viết các bài kiểm tra thành công có nghĩa là bạn đã ghi lại một phần của ứng dụng của mình và đã chứng minh rằng ứng dụng thực hiện những gì nó (bài kiểm tra) nói. Không hơn không kém.

Ngoài ra, một phần rất lớn của việc kiểm tra là "hồi quy". Bạn muốn có thể tự tin phát triển hoặc cấu trúc lại mã mới. Có một số lượng lớn các bài kiểm tra màu xanh lá cây cho phép bạn làm điều đó.

Điều này đi từ tổ chức đến một mức độ tâm lý. Một nhà phát triển biết rằng các lỗi của anh ta sẽ có khả năng cao bị bắt bởi các bài kiểm tra sẽ tự do hơn nhiều để đưa ra các giải pháp thông minh, táo bạo cho các vấn đề anh ta cần giải quyết. Mặt khác, một nhà phát triển không có các bài kiểm tra, sau một thời gian, sẽ bị nghiền nát (do sợ hãi) bởi vì anh ta không bao giờ biết liệu một thay đổi mà anh ta có làm hỏng phần còn lại của ứng dụng hay không.

Đây không phải là sống trong một thế giới giấc mơ sao?

Không. Làm việc với một ứng dụng dựa trên thử nghiệm là niềm vui thuần túy - trừ khi bạn không thích khái niệm này vì bất kỳ lý do gì ("nỗ lực nhiều hơn", v.v.) mà chúng ta có thể thảo luận trong một câu hỏi khác.

Và nó không thực sự ngăn cản sự hiểu biết thực sự về mã?

Hoàn toàn không, tại sao nó?

Bạn tìm thấy rất nhiều dự án nguồn mở lớn (trong đó việc quản lý "hiểu" và hiểu biết về mã là một chủ đề rất cấp bách) thực sự sử dụng các thử nghiệm làm tài liệu chính của phần mềm, ngoài việc là các thử nghiệm, cũng cung cấp các ví dụ thực tế, hoạt động, chính xác cho người dùng hoặc nhà phát triển ứng dụng / thư viện. Điều này thường làm việc lộng lẫy.

Rõ ràng, viết bài kiểm tra xấu là xấu. Nhưng điều đó không liên quan gì đến chức năng kiểm tra mỗi lần.

(Từ ý kiến ​​ban đầu của tôi)

Có sự khác biệt giữa chức năng cần thiết và mục tiêu trong tương lai. Các thử nghiệm dành cho chức năng được yêu cầu: chúng chính xác, chính thức, có thể thực thi được và nếu chúng không thành công thì phần mềm không hoạt động. Các mục tiêu trong tương lai có thể không chính xác hoặc chính thức, hãy để một mình thực thi, vì vậy chúng tốt hơn nên để ngôn ngữ tự nhiên như trong trình theo dõi vấn đề / lỗi, tài liệu, nhận xét, v.v.

Như một bài tập, hãy thử thay thế cụm từ "kiểm tra đơn vị" trong câu hỏi của bạn bằng "lỗi trình biên dịch" (hoặc "lỗi cú pháp", nếu không có trình biên dịch). Rõ ràng là một bản phát hành không nên có lỗi trình biên dịch, vì nó sẽ không sử dụng được; nhưng lỗi trình biên dịch và lỗi cú pháp là trạng thái thông thường trên máy của nhà phát triển khi họ đang viết mã. Các lỗi chỉ biến mất khi chúng kết thúc; và đó chính xác là khi mã nên được đẩy. Bây giờ thay thế "lỗi trình biên dịch" trong đoạn này bằng "kiểm tra đơn vị" :)

Mục đích của kiểm tra tự động là cho bạn biết khi nào bạn đã phá vỡ thứ gì đó càng sớm càng tốt . Quy trình làm việc trông hơi giống như thế này:

1. Thay đổi
2. Xây dựng và kiểm tra sự thay đổi của bạn (lý tưởng tự động)
3. Nếu các bài kiểm tra thất bại, điều đó có nghĩa là bạn đã phá vỡ thứ gì đó đã hoạt động trước đó
4. nếu các bài kiểm tra vượt qua, bạn nên tự tin rằng thay đổi của mình không có hồi quy mới (tùy thuộc vào phạm vi kiểm tra)

Nếu các thử nghiệm của bạn đã thất bại thì bước 3 không hoạt động hiệu quả - các thử nghiệm sẽ thất bại, nhưng bạn không biết liệu điều đó có nghĩa là bạn đã phá vỡ thứ gì đó hay không mà không cần điều tra. Có thể bạn có thể đếm số lần thử nghiệm thất bại, nhưng sau đó một thay đổi có thể sửa một lỗi và phá vỡ một lỗi khác hoặc thử nghiệm có thể bắt đầu thất bại vì một lý do khác. Điều này có nghĩa là bạn cần đợi một khoảng thời gian trước khi bạn biết nếu một cái gì đó đã bị hỏng, cho đến khi tất cả các vấn đề đã được khắc phục hoặc cho đến khi từng thử nghiệm thất bại đã được điều tra.

Khả năng kiểm tra đơn vị để tìm ra các lỗi mới được giới thiệu càng sớm càng tốt là điều có giá trị nhất đối với kiểm thử tự động - lỗi càng lâu không được phát hiện thì càng tốn kém để sửa.

Nó thúc đẩy ý tưởng rằng mã phải hoàn hảo và không tồn tại lỗi nào.
Thật thiếu sót khi nghĩ ra các thử nghiệm đơn vị sẽ thất bại

Các thử nghiệm cho những thứ không hoạt động không cho bạn biết bất cứ điều gì - hãy viết các bài kiểm tra đơn vị cho những việc đang làm hoặc bạn sắp sửa. Điều đó không có nghĩa là phần mềm của bạn không có lỗi, điều đó có nghĩa là không có lỗi nào bạn viết trước đây để kiểm tra đơn vị đã quay trở lại.

Nó ngăn chặn các bài kiểm tra viết đơn vị lên phía trước

Nếu nó hiệu quả với bạn thì hãy viết các bài kiểm tra lên phía trước, chỉ cần không kiểm tra chúng vào chủ / thân của bạn cho đến khi chúng vượt qua.

Nếu tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị đều vượt qua, thì không có bức tranh lớn nào về trạng thái của phần mềm tại bất kỳ thời điểm nào. Không có lộ trình / mục tiêu.

Các bài kiểm tra đơn vị không phải để thiết lập lộ trình / mục tiêu, có thể sử dụng một hồ sơ tồn đọng cho điều đó thay vào đó? Nếu tất cả các bài kiểm tra của bạn vượt qua thì "bức tranh lớn" là phần mềm của bạn không bị hỏng (nếu phạm vi kiểm tra của bạn tốt). Làm tốt!

Các câu trả lời hiện tại chắc chắn là tốt, nhưng tôi chưa thấy ai giải quyết quan niệm sai lầm cơ bản này trong câu hỏi:

tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị phải vượt qua

Không. Chắc chắn nhất, điều này sẽ không đúng. Trong khi tôi đang phát triển phần mềm, NCrunch thường là màu nâu (lỗi xây dựng) hoặc màu đỏ (thử nghiệm thất bại).

Trường hợp NCrunch cần có màu xanh (tất cả các thử nghiệm đã qua) là khi tôi sẵn sàng đẩy một cam kết đến máy chủ kiểm soát nguồn, vì tại thời điểm đó, những người khác có thể phụ thuộc vào mã của tôi.

Điều này cũng đưa vào chủ đề tạo các thử nghiệm mới: các thử nghiệm phải khẳng định logic và hành vi của mã. Điều kiện biên, điều kiện lỗi, v.v. Khi tôi viết bài kiểm tra mới, tôi cố gắng xác định những "điểm nóng" này trong mã.

Đơn vị kiểm tra tài liệu về cách tôi mong đợi mã của mình được gọi - điều kiện tiên quyết, đầu ra dự kiến, v.v.

Nếu một thử nghiệm bị phá vỡ sau một thay đổi, tôi cần phải quyết định xem mã hoặc thử nghiệm có bị lỗi hay không.

Là một lưu ý phụ, thử nghiệm đơn vị đôi khi đi đôi với Phát triển hướng thử nghiệm. Một trong những nguyên tắc của TDD là các bài kiểm tra bị hỏng là kim chỉ nam của bạn. Khi kiểm tra thất bại, bạn cần sửa mã để kiểm tra vượt qua. Đây là một ví dụ cụ thể từ đầu tuần này:

Bối cảnh : Tôi đã viết và hiện hỗ trợ một thư viện được sử dụng bởi các nhà phát triển của chúng tôi được sử dụng để xác thực các truy vấn của Oracle. Chúng tôi đã có các thử nghiệm khẳng định rằng truy vấn phù hợp với một số giá trị dự kiến, điều này làm cho trường hợp quan trọng (không phải trong Oracle) và được phê duyệt một cách vui vẻ các truy vấn không hợp lệ miễn là chúng hoàn toàn khớp với giá trị mong đợi.

Thay vào đó, thư viện của tôi phân tích cú pháp truy vấn bằng Antlr và cú pháp Oracle 12c, sau đó kết thúc các xác nhận khác nhau trên chính cây cú pháp. Những thứ như, nó hợp lệ (không có lỗi phân tích cú pháp nào), tất cả các tham số của nó được thỏa mãn bởi bộ sưu tập tham số, tất cả các cột dự kiến ​​được đọc bởi trình đọc dữ liệu đều có trong truy vấn, v.v ... Tất cả đều là các mục được chuyển qua sản xuất ở nhiều thời điểm

Một trong những kỹ sư đồng nghiệp của tôi đã gửi cho tôi một truy vấn vào thứ Hai đã thất bại (hay đúng hơn, đã thành công khi đáng lẽ nó phải thất bại) vào cuối tuần. Thư viện của tôi nói rằng cú pháp là tốt, nhưng nó đã nổ tung khi máy chủ cố gắng chạy nó. Và khi anh nhìn vào truy vấn, rõ ràng là tại sao:

UPDATE my_table(
SET column_1 = 'MyValue'
WHERE id_column = 123;

Tôi đã tải lên dự án và thêm một bài kiểm tra đơn vị khẳng định rằng truy vấn này không hợp lệ. Rõ ràng, thử nghiệm thất bại.

Tiếp theo, tôi đã gỡ lỗi bài kiểm tra thất bại, bước qua mã mà tôi dự đoán sẽ đưa ra ngoại lệ và nhận ra rằng Antlr đang đưa ra một lỗi trên paren mở, không phải theo cách mà mã trước đó đang mong đợi. Tôi đã sửa đổi mã, xác minh rằng thử nghiệm hiện tại màu xanh lá cây (đã qua) và không có ai khác bị hỏng trong quá trình, cam kết và đẩy.

Việc này có thể mất 20 phút và trong quá trình tôi thực sự đã cải thiện thư viện một cách đáng kể vì giờ đây nó đã hỗ trợ toàn bộ một loạt các lỗi mà trước đây nó đã bỏ qua. Nếu tôi không có bài kiểm tra đơn vị cho thư viện, việc nghiên cứu và khắc phục sự cố có thể mất nhiều giờ.

Một điểm mà tôi không nghĩ xuất phát từ các câu trả lời trước đó là có sự khác biệt giữa thử nghiệm nội bộ và thử nghiệm bên ngoài (và tôi nghĩ rằng nhiều dự án không đủ cẩn thận để phân biệt hai loại này). Một thử nghiệm nội bộ kiểm tra rằng một số thành phần nội bộ đang hoạt động theo cách nó nên; một thử nghiệm bên ngoài cho thấy rằng toàn bộ hệ thống đang hoạt động theo cách nó nên. Tất nhiên, hoàn toàn có khả năng xảy ra lỗi trong các thành phần không dẫn đến lỗi hệ thống (có lẽ có một tính năng của thành phần mà hệ thống không sử dụng hoặc có lẽ hệ thống phục hồi từ lỗi của thành phần). Một lỗi thành phần không dẫn đến lỗi hệ thống sẽ không khiến bạn ngừng phát hành.

Tôi đã thấy các dự án bị tê liệt do có quá nhiều thử nghiệm thành phần nội bộ. Mỗi lần bạn thử và thực hiện cải tiến hiệu suất, bạn sẽ phá vỡ hàng chục bài kiểm tra, bởi vì bạn đang thay đổi hành vi của các thành phần mà không thực sự thay đổi hành vi có thể nhìn thấy bên ngoài của hệ thống. Điều này dẫn đến sự thiếu nhanh nhẹn trong toàn bộ dự án. Tôi tin rằng đầu tư vào các thử nghiệm hệ thống bên ngoài thường có tỷ lệ hoàn trả tốt hơn nhiều so với đầu tư vào các thử nghiệm thành phần bên trong, đặc biệt là khi bạn đang nói về các thành phần cấp thấp.

Khi bạn đề xuất rằng các bài kiểm tra đơn vị thất bại không thực sự quan trọng, tôi tự hỏi liệu đây có phải là điều bạn nghĩ đến không? Có lẽ bạn nên đánh giá giá trị của các bài kiểm tra đơn vị và bỏ qua những bài kiểm tra gây ra nhiều rắc rối hơn giá trị của chúng, trong khi tập trung nhiều hơn vào các bài kiểm tra xác minh hành vi có thể nhìn thấy bên ngoài của ứng dụng.

"nhưng tại bất kỳ thời điểm nào, tất cả các bài kiểm tra đơn vị phải vượt qua"

Nếu đó là thái độ trong công ty của bạn, đó là một vấn đề. Tại thời điểm CERTAIN, cụ thể là khi chúng tôi tuyên bố rằng mã đã sẵn sàng để chuyển sang môi trường tiếp theo, tất cả các thử nghiệm đơn vị sẽ vượt qua. Nhưng trong quá trình phát triển, chúng ta nên thường xuyên mong đợi nhiều bài kiểm tra đơn vị thất bại.

Không có người hợp lý mong đợi một lập trình viên có thể hoàn thành công việc của mình ngay lần thử đầu tiên. Những gì chúng tôi mong đợi một cách hợp lý là anh ấy sẽ tiếp tục làm việc cho đến khi không có vấn đề gì được biết đến.

"Thật là thiếu tôn trọng khi nghĩ ra các bài kiểm tra đơn vị sẽ thất bại. Hoặc chắc chắn đưa ra các bài kiểm tra đơn vị sẽ rất khó để sửa chữa." Nếu ai đó trong tổ chức của bạn nghĩ rằng họ không nên đề cập đến một thử nghiệm khả thi vì nó có thể thất bại và khiến họ phải làm việc nhiều hơn để khắc phục, thì người đó hoàn toàn không đủ tiêu chuẩn cho công việc của họ. Đây là một thái độ tai hại. Bạn có muốn một bác sĩ nói: "Khi tôi đang phẫu thuật, tôi cố tình không kiểm tra xem các mũi khâu có đúng không, bởi vì nếu tôi thấy họ không phải là tôi sẽ phải quay lại và làm lại chúng và điều đó sẽ làm chậm kết thúc hoạt động "?

Nếu nhóm thù địch với các lập trình viên xác định lỗi trước khi mã đi vào sản xuất, bạn có vấn đề thực sự với thái độ của nhóm đó. Nếu quản lý trừng phạt các lập trình viên xác định lỗi làm chậm việc giao hàng, tỷ lệ cược là công ty của bạn đang hướng tới phá sản.

Vâng, chắc chắn đúng là đôi khi những người có lý trí nói: "Chúng ta sắp hết thời hạn, đây là một vấn đề không quan trọng và không đáng để dành tài nguyên ngay bây giờ mà nó sẽ phải sửa chữa nó." Nhưng bạn không thể đưa ra quyết định hợp lý nếu bạn không biết. Tuyệt vời kiểm tra một danh sách các lỗi và chỉ định các ưu tiên và lịch trình để sửa chúng là hợp lý. Cố tình làm cho bản thân không biết gì về các vấn đề để bạn không phải đưa ra quyết định này là ngu ngốc. Bạn có nghĩ rằng khách hàng sẽ không tìm ra chỉ vì bạn không muốn biết?

Đây là một ví dụ cụ thể về xu hướng xác nhận , trong đó mọi người có xu hướng tìm kiếm thông tin xác nhận niềm tin hiện có của họ.

Một ví dụ nổi tiếng về điều này xảy ra, là trong trò chơi 2,4,6.

• Tôi có một quy tắc trong đầu rằng bất kỳ chuỗi ba số nào sẽ vượt qua hoặc thất bại,
• 2,4,6 là một vượt qua
• bạn có thể liệt kê các bộ gồm ba số và tôi sẽ cho bạn biết nếu chúng vượt qua hay thất bại.

Hầu hết mọi người chọn một quy tắc, nói rằng "khoảng cách giữa số 1 và số 2 giống như khoảng cách giữa số 2 và số 3".

Họ sẽ kiểm tra một số con số:

• 4, 8, 12? Vượt qua
• 20, 40, 60? Vượt qua
• 2, 1004, 2006? Vượt qua

Họ nói "Vâng, mọi quan sát đều xác nhận giả thuyết của tôi, nó phải là sự thật". Và thông báo quy tắc của họ cho người đưa ra câu đố.

Nhưng họ không bao giờ nhận được một "thất bại" cho bất kỳ bộ ba số nào. Quy tắc có thể chỉ là "ba số cần phải là số" cho tất cả thông tin họ thực sự có.

Quy tắc thực sự chỉ là các số theo thứ tự tăng dần. Mọi người thường chỉ nhận được câu đố này đúng nếu họ kiểm tra thất bại. Hầu hết mọi người đều hiểu sai, bằng cách chọn một quy tắc cụ thể hơn và chỉ kiểm tra các số đáp ứng quy tắc cụ thể này.

Về lý do tại sao mọi người rơi vào sai lệch xác nhận và có thể thấy các bài kiểm tra đơn vị thất bại là bằng chứng của một vấn đề, có nhiều nhà tâm lý học có thể giải thích sai lệch xác nhận tốt hơn tôi, về cơ bản, mọi người không thích sai và cố gắng thực sự cố gắng để chứng minh mình sai.