Chào mừng trở lại.
Hãy tiếp tục với các bài kiểm tra đơn vị của chúng tôi.
Bây giờ, một điều tôi nhận thấy ở đây là khi xem tài liệu, chúng tôi thực sự có một xác
nhận là ví dụ.
Vì vậy, chúng tôi thực sự có thể thay vì nói khẳng định đúng, chỉ cần sử dụng ví dụ khẳng định là A và B, một lần nữa,
tất cả các phương pháp khẳng định này, không có phương pháp nào đúng, bạn có thể sử dụng bất kỳ phương thức nào bạn muốn
làm công cụ để cải thiện mã của mình .
Vì vậy, trong trường hợp của tôi, chúng ta chỉ cần thay đổi điều này để xác nhận là ví dụ và sửa lỗi này.
Như thế này.
Vì vậy, chỉ cần sạch hơn một chút.
Hãy xem nếu nó hoạt động.
Được rồi.
Mọi thứ vẫn tốt.
Được rồi, chúng ta hãy thử và phá mã của chúng ta một lần nữa.
Vì vậy, mọi thứ đang có vẻ tốt.
Nhưng nếu chúng ta làm điều gì đó khác biệt thì sao?
Nếu chúng ta làm như thế nào?
Giả sử, thêm một bài kiểm tra khác và chúng tôi sẽ nói bài kiểm tra.
Làm cả công cụ nữa.
Thông thường, bạn muốn đặt tên cho các hàm này tốt hơn nhiều, vì vậy chúng mang tính mô tả cao hơn.
Nhưng trong trường hợp của chúng tôi, điều này là tốt, chỉ để chúng tôi có thể xem cách chúng hoạt động trong thời gian này.
Hãy làm bài kiểm tra ram sẽ bằng nhau.
Làm thế nào về một không?
Vì vậy, bây giờ nếu tôi chạy đoạn mã này, hãy chạy lại đoạn mã này.
Nhân tiện, bạn có thể nhận thấy ở đây cách tôi đang sao chép mã trong một bài kiểm tra và bạn có thể nghĩ, Chà, chúng ta có
thể làm cho việc này đơn giản hơn không?
Và không lặp lại chính mình.
Và bạn hoàn toàn có thể làm được điều đó và biến mọi thứ trở nên dễ dàng hơn rất nhiều.
Nhưng khi nói đến các bài kiểm tra, vì chúng không được đưa vào sản xuất và điều này chỉ dành cho
mục đích phát triển, bạn thực sự muốn có các bài kiểm tra dễ đọc để người khác hiểu được các bài kiểm tra
của bạn.
Bởi vì khi nói đến thử nghiệm, khả năng đọc thực sự, thực sự quan trọng.
Chúng tôi không quan tâm nhiều đến việc không lặp lại chính mình và làm cho mã của chúng tôi hiệu quả, đẹp và nhỏ.
Vì vậy, tôi thích viết các bài kiểm tra thực sự mô tả, thực sự rõ ràng.
Tất cả đúng ở đây, chúng ta hãy nói tự, dấu chấm, khẳng định bằng và.
Hmm, cái này phải là cái gì?
Trong trường hợp này, tôi đang mong đợi một lỗi giá trị.
Vì vậy, chúng ta hãy làm điều này.
Tôi hy vọng rằng kết quả sẽ là một lỗi giá trị.
Tôi sẽ lưu và chạy thử nghiệm của mình.
Được rồi, tôi có không khí.
Nó cho biết đây là lỗi loại thành đối số.
Phải là một chuỗi.
Và tôi đang cho nó không phải là loại.
Được rồi.
Vì vậy, điều này không xử lý nó đúng cách vì nó không hoạt động với int mà chúng ta gặp lỗi kiểu.
Vì vậy, làm thế nào chúng ta có thể sửa chữa điều này?
Làm thế nào chúng ta có thể điều chỉnh nó trong trường hợp chúng ta nhận được một loại tham số không?
Trước hết, hãy cung cấp cho nó một tham số mặc định.
Giả sử tham số mặc định là 0.
Nếu tôi chạy cái này.
Lại.
Tôi vẫn nhận được lỗi.
Được rồi, vì vậy chúng tôi vẫn chưa sửa nó.
Lập luận phải chặt chẽ.
Một bi như đối tượng hoặc một số, không phải loại.
Vì vậy, chúng tôi vẫn chưa kiểm tra loại không.
Vì vậy, một điều khác chúng ta có thể làm là nói.
Nếu số.
Vì vậy, chúng tôi đang kiểm tra xem chúng tôi có giá trị số hay không.
Bởi vì hãy nhớ rằng, điều này sẽ được mặc định thành true nếu nó có bất kỳ loại số nào hoặc tốt, bất kỳ giá trị nào,
nhưng nếu nó không phải là loại, nó sẽ chuyển thành false.
Vì vậy, ở đây, nếu số chúng ta có thể nói trả lại cái này.
Khác.
Nếu không, chúng tôi sẽ trở lại.
Xin vui lòng.
Nhập số.
Vì vậy, tôi sẽ nói điều này và bây giờ thay đổi điều này bởi vì bây giờ chúng ta nên mong đợi vui lòng nhập số vào bài
kiểm tra của tôi và tôi sẽ nói khẳng định bằng nhau.
Kết quả đó.
Sẽ được.
Vui lòng nhập số.
Nếu bây giờ tôi chạy thử nghiệm của mình, hãy xóa điều này.
Ầm ầm.
Có vẻ như tôi sẽ chạy hai bài kiểm tra trong 0 giây, nhưng chúng tôi có ba bài kiểm tra và đó là bởi vì.
Bạn thấy ở đây rằng tôi đã đặt tên cho tôi giống nhau.
Hãy nhớ rằng, nếu bạn đặt tên giống nhau, thì, bạn sẽ chỉ chạy một trong số chúng.
Vì vậy, hãy đảm bảo rằng tất cả các tên thử nghiệm là duy nhất.
Vì vậy, tôi sẽ chạy cái này.
Được rồi.
Đã chạy ba bài kiểm tra và mọi thứ đều hoạt động tốt.
Rất, rất tuyệt.
Vì vậy, bạn có thể thấy ở đây chúng tôi đã đi từ một hàm rất đơn giản như thế nào và
chúng tôi bắt đầu bắt những lỗi này và bắt đầu nhận ra rằng hàm của chúng tôi quá đơn giản nếu chúng tôi nhận được đầu vào sai.
Giống.
Một chuỗi hoặc một kiểu không.
Chà, ngay sau khi chúng tôi làm điều đó, chức năng của chúng tôi không thành công.
Vì vậy, bằng cách sử dụng các bài kiểm tra cũng như kiểm tra và phá vỡ mọi thứ, tôi đã có thể cải thiện chức năng này.
Vì vậy, nó bền hơn nên bây giờ nó hoạt động tốt hơn rất nhiều trong sản xuất.
Đúng?
Và đây là sức mạnh của các bài kiểm tra.
Nó cho phép chúng tôi kiểm tra bất kỳ lỗi nào mà chúng tôi có thể đã mắc phải bởi vì có thể ban đầu chúng tôi sẽ không nghĩ
đến việc làm điều gì đó như thế này.
Nhưng bằng cách viết các bài kiểm tra cùng với mã của chúng tôi, chúng tôi đã có thể cải thiện chức năng.
Bây giờ, một điều cuối cùng tôi muốn thêm.
Hãy chỉ thêm một cái khác trong các bài kiểm tra và nói rằng điều này làm công việc gì nếu tham số kiểm tra
chỉ là một chuỗi trống?
Chúng ta nên lấy.
Vui lòng nhập một số.
Vì vậy, nếu tôi chạy cái này.
Được rồi.
Bốn bài kiểm tra đang vượt qua, vì vậy có vẻ như mã của chúng tôi đang hoạt động tốt.
Bây giờ để kết thúc ở đây, tôi muốn chỉ ra một vài điều.
Tôi đang gọi đây tại Unit Test Main.
Nhưng điều này không liên quan gì đến thực tế.
Tập tin.
Đó là chúng tôi đã viết, đó là tệp chính.
Nếu giả sử tôi đổi tên cái này, vậy hãy chuyển đến màn hình của tôi.
Và nói rằng, tôi muốn thay đổi điều này thành.
Script, dot pie.
Bây giờ hãy mở trường hợp này của tôi với văn bản tuyệt vời.
Hãy quay lại đây.
Vì vậy, bạn thấy ở đây rằng pi chính đã tốt, không tồn tại nữa.
Nó đang yêu cầu tôi cứu.
Vì vậy, đây là một tập tin hoàn toàn khác.
Bây giờ, nếu tôi thực hiện script ở đây và chỉ cần thay đổi tất cả các phiên bản thành script.
Nếu tôi lưu cái này và bây giờ chạy.
Điều này vẫn hoạt động thử nghiệm đơn vị trên Main chỉ đơn giản nói, Này, chỉ cần chạy tất cả các thử nghiệm ở đây.
Bây giờ một điều, và đây là một thực tế phổ biến mà chúng ta đã nói trước đây là vì bạn muốn nói
chạy tệp này nếu đây là tệp chính đang được chạy, bởi vì chúng tôi không thực sự muốn nhập tệp chính kiểm tra hoặc bất kỳ
thứ gì tương tự. vào các tệp khác.
Đây là những tệp riêng lẻ chỉ nên chạy khi chúng tôi chạy thử nghiệm của mình.
Vì vậy, tôi chỉ có thể nói nếu gạch dưới, gạch dưới tên.
Bằng nhau.
Gạch dưới gạch dưới chính.
Sau đó chạy đoạn mã này.
Vì vậy, bây giờ nếu tôi lưu nó và chạy.
Của bạn đây.
Mọi thứ vẫn đang hoạt động.
Nhưng bây giờ tôi đảm bảo rằng đây là một tệp thử nghiệm.
Và tôi sẽ chỉ chạy mã này nếu đó là tệp đang được chạy, nếu đó là tệp chính đang được
chạy.
Vì vậy, đây là một cách tiêu chuẩn mà bạn sẽ thực hiện kiểm tra đơn vị của mình với mô-đun kiểm tra đơn vị.
Hãy tạm nghỉ và nói một chút về các bài kiểm tra trong video tiếp theo.