(Đây là một đoạn trích ngắn từ Practice Rails. Đăng ký tại đây để nhận chương đầu tiên miễn phí!)
Vì vậy, bạn đang làm việc trên một ứng dụng mới và Rails vừa tạo một thử nghiệm cho bạn:
require 'test_helper'
class BugTest < ActiveSupport::TestCase
# test "the truth" do
# assert true
# end
end
Bạn bỏ ghi chú nó, nghĩ ra một cái tên và bạn đã sẵn sàng để viết bài kiểm tra của mình, phải không? Nhưng sau đó thì? Bạn viết gì đầu tiên? Mã thử nghiệm của bạn trông như thế nào?
Nếu bạn làm theo một mẫu đơn giản, bạn sẽ biến những dòng mã sơ khai đó thành các trường hợp thử nghiệm rõ ràng, có cấu trúc tốt.
Mẫu kiểm tra ba giai đoạn
Các trường hợp thử nghiệm của bạn sẽ hoạt động theo ba giai đoạn:
- Đầu tiên, bạn thiết lập một số nội dung (“Sắp xếp”)
- Sau đó, bạn làm điều gì đó (“Hành động”)
- Sau đó, bạn đảm bảo rằng những gì bạn mong đợi sẽ xảy ra, đã thực sự xảy ra. (“Khẳng định”)
Ví dụ, hãy tưởng tượng bạn đang thử nghiệm một phương thức trên một mảng trong Ruby. Theo mẫu này, bài kiểm tra của bạn có thể trông giống như sau:
test "Array#sort will sort an array of numbers" do
# arrange
unsorted_array = [7, 4, 2, 3]
# act
sorted_array = unsorted_array.sort
# assert
assert_equal [2, 3, 4, 7], sorted_array
end
Đủ đơn giản. Nhưng mỗi phần của bài kiểm tra đều có một chỗ cần thực hiện và mỗi giai đoạn của bài kiểm tra hầu như cho bạn biết cách viết nó.
Đôi khi, bạn sẽ không cần giai đoạn Sắp xếp hoặc giai đoạn Hành động và Khẳng định sẽ được kết hợp. Nhưng vẫn hữu ích khi nghĩ về cả ba giai đoạn khi bạn viết các bài kiểm tra của mình.
Gotcha giai đoạn khẳng định
Có một mẹo đối với giai đoạn Xác nhận: bạn không nên sử dụng cùng một logic mà giai đoạn Hành động được sử dụng trong giai đoạn Xác nhận. Bạn luôn luôn phải đi hai con đường đến cùng một câu trả lời. Nếu không, bạn sẽ không nhận thấy lỗi trong mã bạn đang gọi, vì mã này chỉ được gọi lại trong giai đoạn Xác nhận.
Ví dụ:nếu bạn đang làm một số phép toán:
test "average returns the average of a set of numbers" do
# arrange
numbers = [1, 2, 3, 4]
# act
average = numbers.average
# assert
# this is bad
assert_equal [1, 2, 3, 4].average, average
# this is better
assert_equal 2.5, average
end
Gọi [1, 2, 3, 4].average một lần nữa trong giai đoạn Assert là không tốt, vì average có thể trả lại hầu hết mọi thứ và khẳng định đó sẽ vẫn vượt qua.
Đây, điều đó khá rõ ràng. Nhưng ngay cả khi mọi thứ trở nên phức tạp hơn, hãy đảm bảo rằng bạn không chỉ chạy cùng một mã hai lần. Nếu không, bạn chỉ đang xác minh rằng phương pháp của bạn đã được gọi là , không phải nó hoạt động theo cách bạn mong đợi.
Thông thường, cách dễ nhất để đi đến con đường thứ hai dẫn đến câu trả lời là tìm câu trả lời bằng tay và mã hóa cứng. Nó có thể giòn, nhưng tốt hơn là các thử nghiệm của bạn bị vỡ mà bạn không nhận ra.
Tại sao lại là ba giai đoạn?
Nếu bạn chia các bài kiểm tra của mình thành ba giai đoạn đó, bạn sẽ có những câu hỏi đơn giản hơn để trả lời. Thay vì “Tôi nên viết bài kiểm tra này như thế nào?”, Bạn có thể tập trung vào từng giai đoạn:“Tôi nên thiết lập bài kiểm tra này như thế nào?”, “Tôi đang kiểm tra cái gì?”, “Câu trả lời sẽ như thế nào?”
Những câu hỏi này vẫn có thể không có câu trả lời dễ dàng, nhưng câu trả lời sẽ dễ dàng hơn rất nhiều so với việc suy nghĩ về toàn bộ bài kiểm tra cùng một lúc. Và nếu may mắn, bạn thậm chí có thể chia sẻ các giai đoạn giữa các bài kiểm tra liên quan, giúp bài kiểm tra tiếp theo của bạn đỡ khó viết hơn nhiều.