Hàm của bạn gọi API thời tiết. Bài kiểm tra của bạn không nên phụ thuộc vào Internet, khóa API hoặc thời tiết ngày mai. Tính năng tích hợp sẵn của Python unittest.mock cho phép bạn thay thế lệnh gọi đó bằng một lệnh thay thế trả về chính xác những gì bạn chọn.

Chúng tôi đã viết một mô-đun weather nhỏ và chín bài kiểm tra, tất cả đều chạy bằng Python 3.13 nhỏ nhất. Tất cả chín đều vượt qua và kết quả đầu ra được in bên dưới là từ lần chạy đó.

Tại sao lại chế nhạo?

• Tốc độ: không cần gọi mạng hoặc thiết lập cơ sở dữ liệu.
• Độ tin cậy: các thử nghiệm không thất bại do dịch vụ của bên thứ ba không hoạt động.
• Kiểm soát: bạn có thể mô phỏng thời gian chờ, lỗi và dữ liệu kỳ lạ theo yêu cầu.
• Cách ly: bạn kiểm tra logic của mình chứ không phải máy chủ của người khác.

Mô phỏng chủ yếu thuộc về kiểm thử đơn vị. Kiểm tra tích hợp vẫn phải nói chuyện với các phần phụ thuộc thực tế hoặc thực tế.

Mô phỏng cơ bản

from unittest.mock import Mock

api = Mock()
api.get_price.return_value = 499

print(api.get_price("pen"))                # 499
api.get_price.assert_called_once_with("pen")
print(api.get_price.call_args_list)        # [call('pen')]
print(api.anything_at_all())               # <Mock name='mock.anything_at_all()' ...>

Mock ghi lại mọi cuộc gọi để bạn có thể kiểm tra xem nó được sử dụng như thế nào. Tuy nhiên, hãy chú ý đến dòng cuối cùng. Một Mock đơn giản sẽ phát minh ra bất kỳ thuộc tính nào bạn yêu cầu. Sự linh hoạt đó rất thuận tiện nhưng cũng nguy hiểm, như chúng ta sẽ thấy.

MagicMock là ý tưởng tương tự nhưng cũng hỗ trợ các phương thức “ma thuật” như __len__ và __iter__. patch() sử dụng MagicMock theo mặc định.

side_effect: lỗi và trình tự

side_effect kiểm soát những gì xảy ra trên mỗi cuộc gọi. Đặt nó thành một ngoại lệ để mô phỏng lỗi:

api.fetch.side_effect = ConnectionError("down")
api.fetch()   # raises ConnectionError

Đặt nó vào danh sách để trả về các kết quả khác nhau trong các cuộc gọi liên tiếp. Điều này là hoàn hảo để thử nghiệm logic thử lại:

def fetch_with_retry(api, attempts=3):
    for _ in range(attempts):
        try:
            return api.fetch()
        except ConnectionError:
            continue
    raise ConnectionError("all attempts failed")

api = Mock()
api.fetch.side_effect = [ConnectionError("busy"), {"ok": True}]
print(fetch_with_retry(api))    # {'ok': True}
print(api.fetch.call_count)     # 2

Cuộc gọi đầu tiên không thành công, cuộc gọi thứ hai thành công và quá trình kiểm tra đã chứng minh chức năng được thử lại chính xác một lần. Việc mô phỏng điều này với một dịch vụ thực tế là gần như không thể.

patch(): thay thế tạm thời một cái gì đó

Thường thì phần phụ thuộc không được truyền vào. Nó được nhập vào bên trong mô-đun. patch() hoán đổi nó trong suốt thời gian thử nghiệm và khôi phục nó sau đó:

# weather.py
from http_client import get as requests_get

def report(city):
    data = requests_get(f"https://api.example.com/weather?city={city}")
    return f"{city}: {data['temp_c']}°C"

from unittest.mock import patch

with patch("weather.requests_get") as fake_get:
    fake_get.return_value = {"temp_c": 31}
    print(weather.report("Pune"))   # Pune: 31°C
    fake_get.assert_called_once_with(
        "https://api.example.com/weather?city=Pune")

Bạn có thể sử dụng patch làm trình quản lý bối cảnh như thế này hoặc làm công cụ trang trí, chuyển mô hình này làm đối số.

Bản vá nơi nó được sử dụng, không phải nơi nó được xác định

Đây là sai lầm hầu như ai cũng mắc phải một lần. Hàm get thực sự tồn tại trong http_client, vì vậy việc vá nó ở đó là điều tự nhiên:

with patch("http_client.get") as fake_get:
    fake_get.return_value = {"temp_c": 99}
    weather.report("Pune")

# ConnectionError: no network in tests: https://api.example.com/weather?city=Pune

Chức năng thực sự đã chạy. Khi weather.py thực hiện from http_client import get as requests_get, nó tạo ra tên riêng trỏ vào hàm ban đầu. Bản vá http_client.get đã đổi tên khác nên weather chưa bao giờ thấy bản mô phỏng. http_client.get của chúng tôi cố tình tăng cược nên sai sót rất lớn. Trong một dự án thực, nó có thể lặng lẽ gọi một API trực tiếp.

spec và autospec: làm cho các bản mô phỏng trở nên nghiêm ngặt

Một Mock đơn giản chấp nhận mọi thứ, kể cả lỗi chính tả. Với một thông số kỹ thuật, nó chỉ cho phép các thuộc tính mà lớp thực có:

api = Mock(spec=weather.WeatherClient)
api.get_temprature("Pune")
# AttributeError: Mock object has no attribute 'get_temprature'

loose = Mock()
loose.get_temprature("Pune")    # returns a Mock, no error at all

Bản mô phỏng lỏng lẻo vui vẻ chấp nhận phương pháp sai chính tả, vì vậy một bài kiểm tra sử dụng nó có thể vượt qua mặc dù mã thực sẽ bị lỗi. autospec đi xa hơn và kiểm tra chữ ký phương thức:

with patch("weather.WeatherClient", autospec=True) as Fake:
    client = Fake.return_value
    client.get_temperature("Pune", "extra", "args")
# TypeError: too many positional arguments

Thích autospec=True hoặc create_autospec() khi chế nhạo lớp học của riêng bạn. Nó giữ cho các mô tả trung thực khi mã thực thay đổi.

Ngày và giờ chế nhạo

Mã phụ thuộc vào ngày hôm nay rất khó kiểm tra. Bọc đồng hồ trong một chức năng nhỏ và vá:

def today():
    return datetime.date.today()

def is_weekend():
    return today().weekday() >= 5

@patch("weather.today")
def test_date(self, fake_today):
    fake_today.return_value = datetime.date(2026, 11, 7)
    print(weather.is_weekend())   # True (a Saturday)

Bạn không thể dễ dàng vá trực tiếp datetime.date.today vì các loại tích hợp không cho phép đặt thuộc tính của chúng. Các thư viện như Freezegun và Time-machine xử lý việc này một cách đầy đủ hơn.

Khẳng định trên mô hình

Khi một xác nhận không thành công, thông báo sẽ rõ ràng. Chúng tôi đã gọi assert_called_once() trên một phương thức chưa bao giờ chạy:

AssertionError: Expected 'save' to have been called once. Called 0 times.

Các phiên bản Python cũ hơn cho phép các phương thức xác nhận sai chính tả, chẳng hạn như assret_called_once, được chuyển âm thầm. Các phiên bản hiện đại có lỗi đối với các tên bắt đầu bằng assert hoặc các lỗi chính tả phổ biến của nó, nhưng thông số kỹ thuật vẫn là biện pháp bảo vệ mạnh mẽ hơn.

pytest và mocks

Mọi thứ ở trên cũng hoạt động trong pytest. Nhiều người dùng pytest cũng sử dụng công cụ cố định monkeypatch tích hợp để thay thế đơn giản hoặc plugin pytest-mock, cung cấp công cụ cố định mocker tự động hoàn tác các bản vá. Quy tắc “bản vá được sử dụng” áp dụng cho tất cả chúng. Xem hướng dẫn pytest của chúng tôi để biết cách thiết lập và cố định.

Khi nào không nên chế giễu

• Đừng chế nhạo những gì bạn đang thử nghiệm. Nếu mô hình làm được tất cả công việc thì bài kiểm tra không chứng minh được điều gì.
• Tránh chế giễu các đối tượng có giá trị đơn giản. Hãy sử dụng đồ thật.
• Đừng mô phỏng mọi thứ. Các thử nghiệm chứa đầy mô phỏng thường bị hỏng bất cứ khi nào mã được tái cấu trúc, ngay cả khi hành vi đúng.
• Giữ một số thử nghiệm tích hợp thực tế. Bản mô phỏng mã hóa các giả định của bạn về một dịch vụ và những giả định đó có thể sai.

Mô phỏng cũng dễ dàng tăng cường phạm vi bảo hiểm của mã vì các đường dẫn mô phỏng chạy mà không có bất kỳ hành vi thực sự nào đằng sau chúng.

Những lỗi chế giễu thường gặp

• Đổ sai tên. Đã đề cập ở trên và vẫn là nguyên nhân số một khiến “bản mô phỏng của tôi bị bỏ qua”.
• Quên đặt return_value. Mã được kiểm tra sau đó nhận được một đối tượng Mock thay vì dữ liệu. Nó có thể đi thẳng qua hàm của bạn và vô tình vượt qua bài kiểm tra, chẳng hạn như khi bạn chỉ kiểm tra xem kết quả có đúng hay không.
• Xác nhận trên bản mô phỏng thay vì kết quả. Kiểm tra xem save() đã được gọi yếu hơn so với kiểm tra những gì đã được lưu. Sử dụng assert_called_once_with(...) với các đối số thực hoặc tốt hơn là xác nhận kết quả của hàm.
• Các bản vá bị rò rỉ. Gọi patcher.start() mà không có stop() sẽ để lại bản giả tại chỗ cho các lần kiểm tra sau. Sử dụng trình quản lý bối cảnh, trình trang trí hoặc addCleanup(patcher.stop).
• Các trình trang trí được xếp chồng lên nhau không đúng thứ tự. Với một số trình trang trí @patch, trình trang trí ở dưới cùng được chuyển làm đối số đầu tiên. Việc trộn chúng một cách âm thầm sẽ cấu hình sai mô hình.
• Chế nhạo thư viện mà bạn không sở hữu qua nhiều bài kiểm tra. Thay vào đó, hãy gói nó trong một lớp học nhỏ của riêng bạn và mô phỏng nó. Sau đó, các bài kiểm tra của bạn sẽ mô tả nhu cầu của bạn chứ không phải API của thư viện.

Giả, sơ khai và giả mạo

Những từ này thường được sử dụng một cách lỏng lẻo, nhưng sự khác biệt sẽ giúp ích khi thảo luận về các bài kiểm tra. sơ khai chỉ trả về các câu trả lời soạn sẵn. mock cũng ghi lại các cuộc gọi để bạn có thể xác minh cách nó được sử dụng. fake là cách triển khai đơn giản, đang hoạt động, chẳng hạn như kho lưu trữ trong bộ nhớ thay vì cơ sở dữ liệu. Mock của Python có thể hoạt động như một bản sơ khai hoặc một bản mô phỏng. Hàng giả là các lớp thông thường mà bạn tự viết và chúng thường dẫn đến các thử nghiệm tồn tại trong quá trình tái cấu trúc tốt hơn, vì chúng kiểm tra hành vi thay vì các lệnh gọi chính xác.

Một nguyên tắc nhỏ là thử nghiệm các khía cạnh của hệ thống của bạn: mạng, đồng hồ, số ngẫu nhiên, hệ thống tệp và các dịch vụ trả phí của bên thứ ba. Bên trong những cạnh đó, thích đồ vật thật hơn. Các thử nghiệm được xây dựng theo cách này sẽ hoạt động nhanh và vẫn thực thi mã bạn thực sự đã viết.

Lời kết

Mocking là một công cụ chính xác: thay thế các phần phụ thuộc chậm hoặc không thể đoán trước, kiểm soát những gì chúng trả về và kiểm tra cách mã của bạn sử dụng chúng. Hai thói quen ngăn ngừa hầu hết các vấn đề. Vá tên trong mô-đun đang được kiểm tra và sử dụng autospec để các cuộc gọi mô phỏng của bạn từ chối đối tượng thực sẽ từ chối.

Câu hỏi thường gặp

Tiếp tục học hỏi