Thử nghiệm đơn vị sau khi thử nghiệm

Question

Tôi kiểm soát phiên bản bằng Git và thử nghiệm đơn vị với QUnit. Đôi khi tôi tìm thấy một lỗi trong phần mềm của tôi không có trong phiên bản trước. Thật dễ dàng cho tôi để viết một bài kiểm tra đơn vị cụ thể cho lỗi đó. Với thử nghiệm đơn vị đó, tôi có thể dễ dàng đi qua tất cả các cam kết trong quá khứ của mình và kiểm tra bản dựng với bài kiểm tra đơn vị đó để tôi có thể xác định được cam kết nào gây ra vỡ không? Không.

Answer 1

Sử dụng git bisect cho việc này, vui lòng xem this page.

Vì bạn đang thử nghiệm JavaScript, có thể bạn sẽ phải chạy thử nghiệm bằng tay và chạy git bisect good và git bisect bad nếu thích hợp. Tuy nhiên, nếu bạn có thể chạy thử nghiệm đơn vị của bạn từ dòng lệnh, sau đó bạn có thể sử dụng git bisect run có Git thực hiện kiểm tra nhiều lần và theo dõi các lỗi cam kết tự động:

$ git bisect run my-script.sh 

Đó là ma thuật thuần túy lần đầu tiên bạn nhìn thấy nó ! :-)

Answer 2

Bạn đã mô tả công việc của git bisect. Cuốn sách Git có a good tutorial.

Ngoài ra còn có một số nhầm lẫn trong các điều khoản của câu hỏi của bạn: Khi một thử nghiệm được sử dụng để bảo vệ chống lại giới thiệu các lỗi cố định trước hoặc để chia làm hai đoạn của buggy cam kết, nó được gọi là một thử nghiệm hồi quy, không phải là một kiểm tra đơn vị. Thử nghiệm thứ hai hoàn toàn là thử nghiệm nếu một đơn vị nhỏ của mã hoạt động, và là dưới thời gian hạn chế nặng nề (TDD người chạy thử nghiệm đơn vị vài chục lần trong một ngày). Đối với một dự án lớn, bạn thường có các bài kiểm tra hồi quy dài hơn nhiều so với các bài kiểm tra đơn vị, vì vậy bạn có thể muốn làm sạch các danh mục.

Answer 3

Có, đây được gọi là git bisect và được giới thiệu lần đầu tiên trong git.

Nguyên tắc:

• lấy một cam kết trong quá khứ, nơi bạn có biết nó làm việc, chúng ta hãy gọi nó c1;
• lấy cam kết sau c1 bạn biết không thành công, hãy gọi số c2;
• git bisect start c2 c1.

Bạn thậm chí có thể hạn chế các bisect để subpath nếu bạn biết nó ở đâu không, và nếu bạn có một kịch bản mà có thể chạy không thử nghiệm tương tác, sử dụng git bisect run.

Answer 4

Git có một lệnh để thực hiện chính xác những gì bạn muốn, git bisect

Find bằng cách tìm kiếm nhị phân thay đổi đó đã giới thiệu một lỗi

Trong trường hợp của bạn, bạn muốn sử dụng nó như git bisect run /path/to/script, mà sẽ tự động kiểm tra các cam kết và thực hiện kiểm tra với từng cam kết để tìm cam kết xấu.

Lưu ý rằng tập lệnh (my_script trong ví dụ trên) nên thoát với mã 0 nếu mã nguồn hiện tại tốt và thoát với mã từ 1 đến 127 (bao gồm), trừ 125, nếu nguồn hiện tại mã là xấu.

Bất kỳ mã thoát nào khác sẽ hủy bỏ quá trình chia đôi. Cần lưu ý rằng một chương trình chấm dứt thông qua "exit (-1)" lá $? = 255, (xem trang hướng dẫn thoát (3)), vì giá trị được cắt nhỏ với "& 0377".

Mã thoát đặc biệt 125 phải được sử dụng khi không thể kiểm tra mã nguồn hiện tại. Nếu kịch bản thoát với mã này, bản sửa đổi hiện tại sẽ bị bỏ qua (xem git bisect bỏ qua ở trên). 125 được chọn là giá trị hợp lý cao nhất để sử dụng cho mục đích này, vì 126 và 127 được sử dụng bởi vỏ POSIX để báo hiệu trạng thái lỗi cụ thể (127 không tìm thấy lệnh, 126 là lệnh được tìm thấy nhưng không thực thi được --- các chi tiết này không quan trọng, vì chúng là các lỗi bình thường trong kịch bản, theo như "bisect run" có liên quan).

Vì vậy, tập lệnh của bạn sẽ biên dịch nguồn, chạy bộ kiểm tra đơn vị của bạn và sau đó cung cấp mã thoát tương ứng. Phần ví dụ từ bisect manpage bao gồm điều này độc đáo (bao gồm các bản dựng bị hỏng, cam kết kết hợp hotfix, v.v.)