Có được coi là 'thực hành xấu' để kiểm tra nội dung tệp / mã hóa trong các bài kiểm tra đơn vị không?

84

Một chút bối cảnh: Trước đó hôm nay tôi đã phải cập nhật một số mã SQL mà một đồng nghiệp khác của tôi đã cung cấp và vì nó là một tập lệnh khá lớn, nó được lưu trữ dưới dạng một tệp riêng biệt (sau đó được đọc và thực thi trong thời gian chạy). Trong khi làm điều này, tôi vô tình giới thiệu lại hai lỗi mà chúng tôi đã có một vài tháng trước đó là:

Vì bất kỳ lý do gì, tệp ASCII đã được mã hóa trong UTF-16 (đồng nghiệp đã gửi email cho tôi tệp, có thể đã gây ra nó).
Kịch bản bị thiếu các SETbáo cáo ban đầu (bắt buộc do một số điều của trình điều khiển khi sản xuất, nhưng không phải là cài đặt sạch cục bộ).

Sau khi gỡ lỗi này khoảng một giờ (một lần nữa), tôi quyết định viết một số bài kiểm tra đơn vị để đảm bảo điều này sẽ không bao giờ xảy ra nữa (và bao gồm một cách nhanh chóng để sửa nó trong thông báo xác nhận để cung cấp một bản sửa lỗi dễ dàng cho các nhà phát triển trong tương lai).

Tuy nhiên, khi tôi đẩy mã này, một đồng nghiệp khác (cũng là trưởng nhóm của chúng tôi) bước đến gần tôi và nói với tôi rằng tôi không nên làm những điều này một lần nữa bởi vì:

"Những điều này không thuộc về bài kiểm tra đơn vị"

"Các thử nghiệm đơn vị chỉ nên được sử dụng để kiểm tra luồng mã của bạn"

Bây giờ tôi khá mâu thuẫn vì tôi vẫn nghĩ những gì tôi làm không sai, vì lỗi này sẽ không được giới thiệu lại trong tương lai, tuy nhiên đồng nghiệp này làm việc như một cấp cao và cuối ngày sẽ quyết định điều gì chúng tôi dành thời gian của chúng tôi trên. Tôi nên làm gì? Tôi có sai khi làm theo cách này không? Có được coi là thực hành xấu?

unit-testing

— Nghịch lý
nguồn

7

Có thể trùng lặp có thể bạn có nên viết kiểm tra tự động để kiểm tra dữ liệu đó có đúng không (nội dung của tệp cấu hình, cơ sở dữ liệu, v.v.)?

— gnat

35

"Các bài kiểm tra đơn vị chỉ nên được sử dụng để kiểm tra luồng mã của bạn " Tôi nói điều đó thật nhảm nhí. Theo truyền thống, họ nên bao gồm tất cả các thử nghiệm cần thiết để đảm bảo rằng "đơn vị" được xem xét tách biệt là chính xác. Nếu bạn chỉ viết những bài kiểm tra đơn vị hữu ích để "kiểm tra dòng chảy", bất kể điều đó có nghĩa là gì, tôi hy vọng bạn cũng có các bộ kiểm tra mở rộng riêng biệt (được viết bởi bộ phận QA?).

— gbr

8

Vấn đề của đồng nghiệp của bạn dù sao cũng có thể chỉ là nơi bạn đặt những bài kiểm tra đó. Tôi tập trung vào đó, bỏ qua các cuộc thảo luận về mệnh giá / thánh chiến. Có thể các bài kiểm tra đó quá chậm so với bộ bạn đã thêm chúng vào, nhưng cũng hoàn toàn có khả năng đồng nghiệp của bạn chỉ sửa lỗi về ý tưởng kiểm tra đơn vị của anh ấy và đang tạo ra một vấn đề từ một vấn đề không tồn tại; Vì vậy, tốt hơn hết là làm rõ vấn đề thực sự là gì.

— gbr

2

Nhân tiện, các bài kiểm tra đó trông giống như một cái gì đó bạn muốn chạy mỗi khi bạn sửa đổi tệp SQL đó. Ở đây, vấn đề chính có thể là các công cụ kiểm tra, có thể không hỗ trợ chế độ hoạt động "chỉ chạy nếu được sửa đổi"; nó làm phát sinh những vấn đề thực tế, cụ thể, có thể đáng để bao gồm chức năng "chỉ khi được sửa đổi" bằng tay với một số loại bùn chỉ dành cho những thử nghiệm cụ thể đó.

— gbr

5

Thay vì kiểm tra rằng tập tin có nội dung và mã hóa chính xác tại sao không kiểm tra rằng nó hoạt động ?

— dùng253751

156

Nhiều khả năng các bài kiểm tra bạn đã viết gần với kiểm tra tích hợp hoặc hồi quy hơn các bài kiểm tra đơn vị. Mặc dù dòng này có thể rất mờ nhạt và đôi khi bị phá hủy thành phương pháp giáo dục về những gì là hoặc không phải là một bài kiểm tra đơn vị, tôi sẽ quay lại với đồng nghiệp của bạn và hỏi các bài kiểm tra bạn đã viết nên ở đâu vì chúng làm tăng giá trị đảm bảo tính chính xác của mã.

Tôi sẽ không tập trung nhiều vào những gì là hoặc không phải là một bài kiểm tra đơn vị và nhận ra rằng ngay cả khi đó là một bài kiểm tra tích hợp, vẫn có thể có giá trị trong bài kiểm tra.

— Cao su
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 .

— Thomas Owens

36

Về mặt kỹ thuật, đây không phải là một bài kiểm tra đơn vị, và nhiều hơn một bước xác nhận. Cách tiếp cận phù hợp thực sự phụ thuộc vào quy trình công việc của bạn cần là gì. Trưởng nhóm của bạn là chính xác về mục đích của bài kiểm tra đơn vị là gì. Cảm giác của tôi là đây là một trường hợp sử dụng sai công cụ cho một công việc vẫn cần phải được thực hiện. Vì vậy, bắt đầu với điều này:

Vấn đề tôi đang cố gắng giải quyết là gì?

Theo mô tả, bạn cần xác thực rằng bất kỳ tập lệnh cơ sở dữ liệu nào tuân thủ một số tiêu chuẩn.

Những công cụ / quy trình có sẵn để giải quyết vấn đề?

Chất lượng mã nguồn thường được kiểm tra bởi các công cụ phân tích tĩnh . Nếu bạn không có công cụ phân tích tĩnh để xác thực SQL của mình, thì bạn có thể tạo một công cụ nhanh và bẩn để thực hiện kiểm tra bất kỳ tệp SQL nào được truyền vào nó. Sẽ không hại gì nếu kiểm tra xem có công cụ phân tích tĩnh nào có thể xử lý các vấn đề bạn đang nói không.

Nếu bạn tạo một phần của cơ sở hạ tầng xây dựng của mình, chẳng hạn như kết hợp nó vào Jenkins hoặc một cái gì đó tương tự, nó có thể được áp dụng cho tất cả các tệp SQL trong dự án của bạn.

Các bài kiểm tra đơn vị chỉ giải quyết vấn đề cho tập tin hiện tại của bạn.

Làm thế nào để tôi truyền đạt sự cần thiết của công cụ?

Điều này là khá dễ dàng, bạn nói chuyện với trưởng nhóm của bạn. Anh ta có thể làm việc với chủ sở hữu sản phẩm và bạn để xác định rủi ro / phần thưởng khi đầu tư vào dụng cụ. Nếu đây có thể là sự cố một lần thì công cụ có thể sẽ là quá mức cần thiết. Nếu công cụ để nắm bắt các vấn đề lớn nhất là dễ dàng, nó có thể đáng giá chỉ để kiểm tra độ tỉnh táo.

Trưởng nhóm của bạn có thể có một số ý tưởng mà bạn (hoặc tôi) chưa xem xét, có thể giải quyết vấn đề chính xác hơn.

— Berin Loritsch
nguồn

21

Khi thảo luận về chi phí so với rủi ro, điều quan trọng cần lưu ý là nó đã gây mất thời gian do giới thiệu lại các lỗi đã được giải quyết trước đó. Điều này một mình là một đối số mạnh mẽ để tự động hóa xác minh. +1

— jpmc26

1

@ jpmc26, tôi hoàn toàn đồng ý. Cuộc thảo luận sẽ bắt đầu với thực tế là bạn đã mất tuy nhiên nhiều giờ để tìm ra điều gì sai và bài kiểm tra đơn vị của bạn là nỗ lực đầu tiên của bạn để ngăn các thành viên còn lại mất cùng một khoảng thời gian. Tuy nhiên, làm việc với trưởng nhóm, người phải trả lời cho quản lý và các bên liên quan thường rất được đánh giá cao. Với tư cách là trưởng nhóm, tôi muốn có thể bảo vệ các công cụ / thực hành / mã mà chúng tôi quản lý. Nếu tôi thấy các bài kiểm tra đơn vị không thể theo dõi được các yêu cầu thực tế thì tôi cũng lo ngại.

— Berin Loritsch

1

@BerinLoritsch Về mặt kỹ thuật, đây không phải là bài kiểm tra đơn vị tôi thực sự muốn biết về "kỹ thuật" nào mà bạn dựa trên khẳng định này. Theo như tôi có thể nói, không có định nghĩa chính thức nào về các bài kiểm tra đơn vị và mọi người đều có ý tưởng riêng về " chúng là gì ".

— gbr

2

@gbr Có một thỏa thuận không chính thức giữa các nhà phát triển rằng các bài kiểm tra đơn vị là các bài kiểm tra được chạy tách biệt với các hệ thống bên ngoài. Họ chỉ kiểm tra mã, không tương tác với các tệp, cơ sở dữ liệu hoặc các dịch vụ bên ngoài khác. Wikipedia ghi lại sự hiểu biết này: en.wikipedia.org/wiki/Unit_testing#External_work .

— jpmc26

1

@BerinLoritsch Cũng có thể là tất cả chúng ta đều diễn giải câu hỏi theo một cách khác, dù sao đi nữa, nó không chi tiết lắm và tác giả vẫn chưa quay lại với ai. Dù sao tôi cũng không quan tâm đến việc thảo luận thêm về việc phân loại các thử nghiệm này, điều quan trọng là liệu chúng có tồn tại hay không (tôi khá chắc chắn là chúng nên) và tần suất để chúng chạy (ở mọi thay đổi trong IDE, ở mọi thay đổi cam kết cục bộ, tại mỗi lần đẩy đến kho lưu trữ trung tâm, tại mọi thời điểm ...).

— gbr

19

Đó là thực tế xấu để gọi các bài kiểm tra truy cập các tập tin "Bài kiểm tra đơn vị".

Anh ấy: "Những thứ này không thuộc về bài kiểm tra đơn vị"

Bạn: "Có ý nghĩa, nhưng tôi không thể tìm thấy một nơi tốt hơn để đặt chúng. Chúng thuộc về đâu?"

Thật không may, những loại thử nghiệm tồn tại và cách chúng được tổ chức là hoàn toàn cụ thể của công ty. Vì vậy, bạn sẽ cần tìm hiểu làm thế nào công ty của bạn xử lý các thử nghiệm này.

Nếu bạn chưa có cách nào để chạy thử nghiệm tự động ngoài Thử nghiệm đơn vị, cách tiếp cận thực tế là đánh dấu các Thử nghiệm đơn vị không thực sự là Thử nghiệm đơn vị với tiền tố, cho đến khi bạn có đủ chúng để bắt đầu tìm ra loại nào kiểm tra bạn thực sự có / cần. Sau đó, bạn có thể bắt đầu tổ chức.

— Peter
nguồn

2

Đó là thực tế xấu để gọi các bài kiểm tra truy cập các tập tin "Bài kiểm tra đơn vị". Ở đây tập tin đang được truy cập là tập tin nguồn . Nó sẽ được truy cập nhiều như bất kỳ tệp nguồn nào (để phân tích nó). Việc kiểm tra có thể sẽ không được thực hiện trong cùng ngôn ngữ của "đơn vị" đang được kiểm tra (SQL) làm cho nó không chính thống nhưng không ảnh hưởng đến phân loại của nó như một bài kiểm tra đơn vị. tiếp tục ...

— gbr

1

... Trên thực tế, mã hóa chính xác của tệp là một "thử nghiệm" được tạo bởi bất kỳ trình biên dịch nào mỗi khi nó đọc tệp nguồn. Vấn đề ở đây là việc một tệp bên ngoài được giải thích vào thời gian chạy, "kiểm tra trình biên dịch" sẽ không được chạy tự động, và do đó hoàn toàn thích hợp để thêm chúng một cách rõ ràng và tôi nghĩ rằng nó có thể được coi là "kiểm tra đơn vị" một cách chính xác Đoạn mã SQL. Và có vẻ hợp lý khi đưa nó vào bộ thử nghiệm (tiềm năng) chạy ở mọi sửa đổi của tệp.

— gbr

3

Nhân tiện, những gì thường được đề nghị chống lại là truy cập các tệp bên ngoài khi có thể được thay thế bằng một bản giả hoặc một cái gì đó theo cách đó. Và theo hầu hết các định nghĩa, các bài kiểm tra đơn vị có thể truy cập các tệp bên ngoài hoặc bất cứ điều gì, nó chỉ được khuyến khích mạnh mẽ, vì nó có thể làm mọi thứ chậm lại rất nhiều. Một cửa hàng có thể quy định rằng bạn không thể thêm các bài kiểm tra truy cập các tệp vào bộ kiểm tra được chạy thường xuyên nhất, nhưng điều đó không làm cho các bài kiểm tra đó không xứng đáng với chỉ định "kiểm tra đơn vị", họ chỉ làm cho chúng "không được đưa vào bộ thử nghiệm chạy thường xuyên nhất của dự án này ".

— gbr

2

@Warbo Việc truy cập các tệp (nói chung) là một thực tế tồi và lý do (quan trọng nhất) là chúng không chậm nếu chúng liên quan đến "GB đọc qua liên kết NFS không ổn định", chúng chậm nếu ví dụ như trích dẫn Michael Feathers , họ mất 1/10 giây. Đó là bởi vì bạn muốn chạy thử nghiệm của mình thường xuyên nhất có thể, lý tưởng nhất là ở mọi thay đổi bạn thực hiện trong IDE và khi bạn có rất nhiều trong số chúng (như bạn nên) thậm chí là 10 giây tích lũy đến hàng giờ. (tiếp tục ...)

— gbr

1

@Warbo .. Điều đó nói rằng, điều quan trọng là tổng thời gian họ thực hiện, vì vậy nếu bạn có một dự án rất nhỏ mà bạn chắc chắn sẽ ở mức nhỏ, bạn có thể khoan dung hơn nhiều về tốc độ của các bài kiểm tra riêng lẻ. Và nếu bạn thực sự không quan tâm đến việc chạy chúng thường xuyên, bạn hoàn toàn tự do thậm chí nhờ họ gọi cho nhân viên OPMROC để lấy và fax cho họ một tệp từ tủ. Bạn cũng có thể chọn để lỏng lẻo hơn trong khi bạn vẫn có một vài bài kiểm tra và quay lại để tăng tốc chúng khi chúng bắt đầu nhận quá nhiều, nhưng bạn phải tính đến rằng đây là khoản nợ mà bạn đang tích lũy.

— gbr

14

Michael Feathers nói điều này trong cuốn sách của ông làm việc hiệu quả với Bộ luật kế thừa:

Trong ngành, mọi người thường qua lại về việc các bài kiểm tra cụ thể có phải là bài kiểm tra đơn vị hay không. [...] Tôi quay trở lại với hai phẩm chất: Bài kiểm tra có chạy nhanh không? Nó có thể giúp chúng tôi bản địa hóa lỗi nhanh chóng?

Thử nghiệm của bạn sẽ giúp bản địa hóa lỗi nhanh chóng và chạy nhanh? Nếu có, sau đó làm điều đó! Nếu không, thì đừng! Nó đơn giản như vậy!

Điều đó đang được nói, bạn đang làm việc trong một môi trường với những người khác và phải hòa đồng với họ. Bạn có thể phải làm theo cách của mình, ngay cả khi bạn không đồng ý với nó.

— Dennis
nguồn

Đó là một quy tắc tốt, nhưng anh ta sẽ tránh được sự nhầm lẫn nếu anh ta đã viết " có nên thêm các bài kiểm tra cụ thể vào bộ kiểm tra chạy thường xuyên nhất không ", thay vào đó làm rối với thuật ngữ "kiểm tra đơn vị".

— gbr

1

@gbr Nếu kết quả kiểm tra là chính xác, điều duy nhất quan trọng khác là nó chạy nhanh như thế nào. Nếu tôi có 100 bài kiểm tra mà mỗi bài kiểm tra dưới 0,1 giây, tổng cộng chúng sẽ chạy trong vòng dưới 10 giây. Tôi rất vui khi chạy chúng thường xuyên. Nếu tôi có 1000 bài kiểm tra, họ sẽ mất tới 1m40. Quá lâu, tôi sẽ không chạy chúng thường xuyên, nhưng tôi sẽ chạy chúng một khi tôi đã thực hiện các thay đổi với nhóm 100 thử nghiệm nhỏ hơn. Tôi không quan tâm nếu về mặt kỹ thuật đó là một bài kiểm tra chấp nhận hoặc một cái gì đó khác. Nếu giúp tôi tìm ra lỗi sớm hơn, tôi sẽ làm việc đó bất kể ngữ nghĩa. Một thử nghiệm chỉ cung cấp giá trị khi nó chạy.

— CJ Dennis

Tôi hầu như đồng ý (tính độc lập là một điều rất quan trọng khác, ví dụ), nhưng dù sao, sẽ tốt hơn nếu Michael Feathers không gây nhầm lẫn về "kiểm tra đơn vị" nghĩa là gì. Không phải là anh ấy đặc biệt đổ lỗi cho sự nhầm lẫn đó (và cuốn sách của anh ấy là tuyệt vời, trong những phần mà tôi đọc lướt qua cho đến nay). Dù sao thì tôi cũng đã đưa ra một quan điểm khá nhỏ.

— gbr

@gbr Anh ấy không xác định lại các bài kiểm tra đơn vị, anh ấy nói rằng không nên là tiêu chí của bạn để đưa vào. Tiêu chí của bạn nên hữu ích, và đó là những gì anh ấy xác định.

— CJ Dennis

Tôi đọc lại phần đó; Tôi không chắc chắn, nó không rõ ràng với tôi nếu đó có nghĩa là một định nghĩa (loại) hoặc chỉ là một tiêu chí. Nhưng thực ra " Nó có thể giúp chúng tôi bản địa hóa các lỗi một cách nhanh chóng " rất có thể ngụ ý những điều mà anh ấy nói trước đây, về sự cô lập, v.v. Vì vậy, tôi có thể đã làm ầm ĩ lên về bất cứ điều gì (mặc dù câu trả lời của bạn vẫn có thể bị hiểu sai)

— gbr

10

Tôi đã viết các bài kiểm tra tương tự, đôi khi, đối với các tệp mã nguồn, các tệp cấu hình, v.v. Tôi sẽ không gọi chúng là kiểm tra đơn vị vì (a) chúng đang truy cập hệ thống tệp và có thể không cực nhanh (b) Tôi không quan tâm nếu chúng được thực hiện trên mỗi lần đăng ký (trái ngược với hàng đêm Máy chủ CI).

Bạn có thể gọi chúng là các bài kiểm tra tích hợp; chắc chắn, họ gần với quan điểm đó hơn là kiểm tra đơn vị.

Thuật ngữ riêng của tôi cho họ là kiểm tra tài nguyên . IMHO, chúng hoàn toàn hợp lý nếu được thực hiện hàng đêm trên máy chủ CI: có chi phí tối thiểu và khi được sử dụng một cách thận trọng, rõ ràng sẽ tăng thêm giá trị. Một định nghĩa về mặt thận trọng : nếu thử nghiệm đang kiểm tra một vấn đề gây ra sự cố (chẳng hạn như mã hóa mà bạn đề cập).

— Michael Phục Sinh
nguồn

4

Một bài kiểm tra đơn vị là tất cả về kiểm tra một phương thức hoặc 'đơn vị' mã. Bạn đang kiểm tra nhóm logic và mã nhỏ nhất trong phần mềm của mình.

Sau này, khi bạn tham gia cùng với các đơn vị khác, bạn sẽ thực hiện kiểm tra tích hợp.

Tôi hy vọng trưởng nhóm của bạn khuyến khích sáng kiến của bạn và nên đưa ra đề xuất thay thế. Bạn chắc chắn có ý tưởng đúng.

SQL của bạn là mã giống như bất kỳ ngôn ngữ thế hệ thấp hơn như C # hoặc Java và nên được kiểm tra như vậy. Và xác minh và xác nhận thuộc về tất cả các cấp độ thử nghiệm. Vì vậy, mã hóa và câu lệnh SET được bao gồm, nhưng không nhất thiết phải được kiểm tra riêng. Những thứ chung chung như kết thúc dòng hoặc kèm theo bạn thường chỉ có thể sử dụng móc hoặc tính năng SCM.

Thực hành tốt nhất là kiểm tra hồi quy để đảm bảo rằng các lỗi trong quá khứ không được giới thiệu lại. Nói chung, các bài kiểm tra được tạo ra cùng với bất kỳ độ phân giải của lỗi. Nếu các lỗi này không nằm trong các bài kiểm tra hồi quy ở cấp độ đơn vị / tích hợp hoặc hệ thống và sau đó giới thiệu lại thì đó là vấn đề nhóm, vấn đề về quy trình, không phải là vấn đề cá nhân.

Vấn đề là ... lỗi cú pháp, thiếu câu lệnh hoặc khối logic bên trong 'đơn vị' thường không được kiểm tra. Bạn đang kiểm tra đầu vào và đầu ra của đơn vị theo các kết hợp khác nhau, kiểm tra nhiều khả năng có thể được tạo.

Quay trở lại các câu lệnh SET bị thiếu - chúng giúp thông báo nhiều khả năng của đầu vào và đầu ra để kiểm tra. Bài kiểm tra nào bạn sẽ viết sẽ FAIL nếu bạn thiếu bất kỳ SET nào được chọn?

— Ross
nguồn

Thử nghiệm "Đơn vị mã" là một cách tiếp cận để thử nghiệm đơn vị. Theo kinh nghiệm của tôi, điều này dẫn đến các bài kiểm tra mỏng manh và phình to (ví dụ như chế giễu quá mức). Một cách khác, và IMHO tốt hơn, cách tiếp cận kiểm thử đơn vị là "đơn vị chức năng". Sẽ không có vấn đề gì nếu một số chức năng (giả sử, "đặt cookie khi đăng nhập") yêu cầu một phương thức hoặc hàng tá quy trình liên thông, đó vẫn là một đơn vị.

— Warbo

@Warbo - Tôi sẽ gọi nó gần hơn với (nhưng không) thử nghiệm tích hợp. Kiểm tra đơn vị không yêu cầu quá nhiều hoặc lớn bất cứ điều gì. Bài kiểm tra đơn vị nên nhỏ và nhanh. Thực tế kiểm tra bằng chức năng dẫn đến những gì bạn mô tả .. Các bài kiểm tra dễ vỡ là những bài kiểm tra 1. lớn hơn hoặc làm nhiều hơn mức cần thiết. 2. rất ghép đôi 3. không có một trách nhiệm.

— Ross

3

Nếu bạn có các tệp trở thành một phần của sản phẩm, thì nội dung của chúng phải chính xác. Không có lý do tại sao bạn sẽ không xác minh điều này. Ví dụ: nếu bạn cần sáu hình ảnh 1024x 1024 trong một số thư mục, thì bằng mọi cách, hãy viết một bài kiểm tra đơn vị kiểm tra bạn có chính xác không.

Nhưng có lẽ bạn không chỉ có các tệp, bạn cũng có một số mã đọc các tệp. Bạn có thể viết một bài kiểm tra đơn vị cho mã đó. Trong ví dụ trên, chức năng đọc một trong sáu hình ảnh sẽ trả về hình ảnh 1024 x 1024 trong bộ nhớ (hoặc bất cứ thứ gì nó được cho là tạo ra).

Dù sao, nó có thể không phải là một bài kiểm tra đơn vị, nhưng nó là một bài kiểm tra hữu ích. Và nếu bạn sử dụng khung kiểm tra đơn vị cho phép bạn thực hiện kiểm tra hữu ích (đó không phải là kiểm tra đơn vị), tại sao không sử dụng khung kiểm tra đơn vị?

— gnasher729
nguồn

2

Có lẽ tôi đang hiểu nhầm vấn đề của bạn, nhưng với tôi điều này nghe có vẻ như là một vấn đề không cần phải nắm bắt bởi bất kỳ loại thử nghiệm chuyên dụng nào mà chỉ đơn giản là bởi hệ thống kiểm soát phiên bản . Bất kỳ thay đổi nào đối với một cơ sở mã phải được xem xét trên cơ sở từng bản vá trước khi cam kết. Một cách đơn giản để làm điều này trong git là thêm các thay đổi với

git add -p

Điều này sẽ cho mỗi thay đổi trong một tệp văn bản, thư mục làm việc hỏi bạn xem bạn có thực sự muốn giữ nó không. Điều đó sẽ cho phép bạn nhìn thấy, ví dụ, việc xóa các SETcâu lệnh ban đầu đó .

Trong trường hợp mã hóa của toàn bộ tệp thay đổi, một số thứ khác sẽ xảy ra: thuật toán sẽ không khác với tệp cũ và mới, và do đó git add -psẽ không thêm bất cứ thứ gì. Điều này sau đó sẽ được hiển thị trong lệnh khác mà tôi thực hiện trước bất kỳ cam kết nào, cụ thể là

git status

Ở đây bạn sẽ thấy tệp được tô sáng màu đỏ, chỉ ra rằng có những thay đổi. Điều tra lý do tại sao những điều này không làm cho nó vào git add -psẽ nhanh chóng làm cho vấn đề rõ ràng.

— bên trái
nguồn

Hãy cầu nguyện, làm thế nào điều này giúp bất kỳ nhà phát triển trong tương lai để tránh chính xác cùng một vấn đề? ... điều về các thử nghiệm tự động (cũng hợp lệ về các xác nhận và thiết kế theo hợp đồng) là chúng, tốt, erm, tự động .

— vaxquis

@vaxquis nó không ngăn chặn cùng một vấn đề chính xác - mặc dù hơi trùng hợp, vì tác dụng phụ của quy trình làm việc đó là một ý tưởng tốt cho các lý do khác nhau. Quan điểm của tôi là, vấn đề này hoàn toàn có thể xảy ra cho thấy nhóm của OP đã không tận dụng rất tốt VCS của họ. - Không có gì chống lại các kiểm tra tự động, nhưng giá trị của chúng là kiểm tra các thuộc tính ngữ nghĩa có thể bị phá vỡ bởi những thay đổi vô hại đối với logic chương trình. Nó không phải là để kiểm tra mọi cách ngu ngốc có thể trong đó mã nguồn có thể thay đổi.

— leftaroundabout

theo logic của bạn, chúng tôi không cần dây an toàn; chúng ta chỉ cần lái xe cẩn thận hơn và gây ra ít tai nạn hơn ... Bạn đã bỏ lỡ điểm chính mà OP nêu ra - đó là lỗi của con người . Không có số lượng VCS có thể bảo vệ bạn khỏi điều đó . Ngoài ra, FWIW: nếu một bài kiểm tra có thể được tự động, thì nó sẽ được tự động hóa. Con người luôn là mắt xích yếu nhất trong các quy trình kỹ thuật. gitlà ví dụ tốt nhất về điều đó - một công cụ tuyệt vời, nhưng hầu như không sử dụng được cho những người bình thường .

— vaxquis

@vaxquis Không, không! Thắt dây an toàn tương tự như loại thử nghiệm có ý nghĩa: chúng nắm bắt được một loạt các tình huống có khả năng xảy ra do tai nạn. Một thử nghiệm về mã hóa tập tin sẽ tương tự như một robot đi theo bạn xung quanh và ngăn bạn khỏi ngạt thở bằng cách nhét đậu lên mũi.

— leftaroundabout

Theo OP, các tệp ở định dạng sai đã xảy ra hai lần rồi, vì vậy rõ ràng chúng có khả năng xảy ra do tai nạn.

— gnasher729

1

Một góc khác để xem xét: vì hai điều kiện đó là các yêu cầu để chương trình của bạn chạy, bạn có nên nhúng logic gần với logic thực thi không? Ý tôi là: bạn kiểm tra sự tồn tại của một tập tin trước khi đọc nó và / hoặc xác nhận nội dung của nó, phải không? vậy điều này khác nhau như thế nào? Tôi nghĩ rằng vì đây là tài nguyên bên ngoài mã, nên nó phải được xác nhận trong thời gian chạy, trước khi nó thực sự được sử dụng. Kết quả: ứng dụng mạnh hơn, không cần phải viết thêm bài kiểm tra.

— Tiến sĩ Gianluigi Zane Zanettini
nguồn

1

Làm thế nào để thất bại chỉ trong thời gian chạy làm cho nó một ứng dụng mạnh mẽ hơn? Chắc chắn, cũng có thể thích hợp để kiểm tra thời gian chạy gần với nguồn gốc của vấn đề, nhưng nếu bạn có thể phát hiện ra lỗi trước khi chúng gây ra sự cố thời gian chạy, thì tốt hơn nhiều, bạn có nghĩ vậy không? Bạn có chắc là bạn quen thuộc với thử nghiệm tự động?

— gbr

1

"Làm thế nào mà thất bại chỉ trong thời gian chạy làm cho nó trở thành một ứng dụng mạnh hơn?" Ném một ngoại lệ nếu kiểm tra thất bại. Trong thử nghiệm của bạn, chỉ cần kiểm tra xem phần mã được kiểm tra có trả về kết quả mong đợi không: phần này loại bỏ gánh nặng để kiểm tra thêm một lý do cho sự thất bại.

— Tiến sĩ Gianluigi Zane Zanettini

1

Chiến lược của bạn (hầu như) không liên quan gì đến kiểm thử đơn vị và kiểm thử tự động nói chung, đó là một điều khác biệt, với những cách sử dụng khác nhau.

— gbr

1

Tôi sẽ đề nghị điều này. Lỗi là một chi tiết thực hiện; Tôi tưởng tượng các phản hồi sẽ rất khác nhau nếu mã hóa tinh ranh nằm trong một trường riêng chứ không phải là một tệp độc lập! Có vẻ như OP có 2 vấn đề: các tệp tài nguyên có thể được mã hóa kém và quá trình sản xuất hoạt động khác với dev. Bằng cách kiểm tra tệp trong thời gian chạy, ngay trước khi nó được sử dụng, chúng tôi giải quyết vấn đề thứ hai: dev và prod sẽ đưa ra cùng một lỗi. Các bài kiểm tra đơn vị sau đó có thể tập trung vào chức năng thực tế hơn là các chi tiết thực hiện; các kiểm tra "nội bộ" này sẽ được thực hiện giống như các phương thức riêng tư.

— Warbo

1

@ Dr.GianluigiZaneZanettini Bah ... Tôi từ bỏ ... Như tôi thấy, tốt nhất là câu trả lời của bạn, sau khi "làm rõ" trong các bình luận, đã lạc đề (không phải là câu trả lời cho câu hỏi), nhưng thực tế, vì nó đứng, nó hoàn toàn sai! không cần viết thêm bài kiểm tra ??? Tôi không đủ danh tiếng để đánh giá thấp nó, nhưng hãy xem xét như thể tôi đã làm điều đó. Và tôi không nghĩ có nhiều giá trị khi tiếp tục cuộc trò chuyện này.

— gbr

1

Các thử nghiệm có cùng mã với bất kỳ loại nào khác và, nếu đủ phức tạp, cũng được hưởng lợi từ ... thử nghiệm đơn vị. Có vẻ đơn giản nhất để thêm kiểm tra điều kiện tiên quyết như vậy trực tiếp vào thử nghiệm.

Hầu hết các bài kiểm tra đủ đơn giản để không yêu cầu điều này, nhưng nếu một số bài kiểm tra đủ phức tạp, tôi không thấy bất cứ điều gì sai về cơ bản với các kiểm tra tiền điều kiện này. Tất nhiên, bài kiểm tra cũng sẽ thất bại nếu không có chúng, nhưng bài kiểm tra đơn vị tốt cũng cho biết đơn vị nào bị lỗi.

Một tập lệnh được sử dụng như một phần của bài kiểm tra và phải có nội dung nhất định và mã hóa có thể là một đơn vị. Nó có thể có nhiều mã và logic hơn phần còn lại của bài kiểm tra. Một thử nghiệm với kịch bản như vậy không phải là thiết kế tốt nhất từ trước đến nay và, nếu có thể, nên được tái cấu trúc thành một thứ trực tiếp hơn (trừ khi đây là thử nghiệm tích hợp).

— h22
nguồn

1

tác giả không nói bất cứ nơi nào rằng tập lệnh SQL là một phần của một số bài kiểm tra, bạn dường như đã đọc sai câu hỏi

— gbr

Khó hiểu, tôi cho rằng tập lệnh SQL là một phần của bài kiểm tra.

— h22

bình luận của bạn "Khó hiểu" ...

— gbr

Khó để hiểu. Hạ câu hỏi.

— h22

1

Thứ nhất - một trong những mục đích của các bài kiểm tra là để ngăn chặn các vấn đề tái diễn trong mã của bạn - vì vậy bạn tuyệt đối nên tiếp tục viết các bài kiểm tra có tính chất này.

Thứ hai - đặt tên rất khó. Vâng, đây rõ ràng không phải là "thử nghiệm đơn vị", nhưng chúng có thể là những phần cần thiết và cần thiết của quá trình xây dựng, vì chúng bảo vệ bạn khỏi những sai lầm rõ ràng và vì chúng cung cấp cho bạn thông tin phản hồi về lỗi sớm hơn (đặc biệt là bạn không thấy hậu quả trên một hộp dev).

Vì vậy, câu hỏi thực sự là (nên có trong ngữ cảnh của bạn) nhiều hơn về thời điểm và cách các thử nghiệm này được chạy so với những gì chúng là.

Tôi đã sử dụng loại thử nghiệm này trong quá khứ - họ đã cứu chúng tôi một nỗi đau.

— Murph
nguồn

Và nếu ai đó quan tâm giải thích về downvote tôi sẽ đánh giá cao nó

— Murph

1

Các thử nghiệm đơn vị là về việc thực hiện một đơn vị mã riêng rẽ để xác nhận rằng nó đang tạo ra kết quả chính xác cho đầu vào chính xác. Cách ly phải làm cho cả đơn vị được thử nghiệm và bản thân thử nghiệm có thể lặp lại, nghĩa là không nên phụ thuộc hoặc giới thiệu các tác dụng phụ.

SQL không chính xác là thứ gì đó có thể được kiểm tra riêng rẽ, do đó, mọi thử nghiệm về SQL không chính xác là một thử nghiệm đơn vị, và ngoại trừ các câu lệnh CHỌN, gần như chắc chắn có tác dụng phụ. Chúng ta có thể gọi nó là một bài kiểm tra tích hợp hơn là một bài kiểm tra đơn vị.

Luôn luôn là khôn ngoan để đảm bảo rằng bất kỳ khiếm khuyết nào có thể được phát hiện có thể được phát hiện sớm nhất có thể trong chu kỳ phát triển và có lợi để làm như vậy để dễ dàng xác định nguồn gốc của khuyết tật để có thể nhanh chóng sửa chữa

Các xét nghiệm trong câu hỏi có thể được di chuyển một cách thích hợp ra khỏi cơ thể của "các bài kiểm tra đơn vị" và được đặt ở một nơi khác, nhưng không nên được loại bỏ hoàn toàn nếu chúng đang làm một cái gì đó hữu ích như bảo vệ chống lại sự giới thiệu có thể có của một khiếm khuyết có thể mất hàng giờ để theo dõi xuống.

— Zenilogix
nguồn