利用Python中的mock库对Python代码进行模拟测试
如何不靠耐心测试
通常，我们编写的软件会直接与那些我们称之为“肮脏的”服务交互。通俗地说，服务对我们的应用来说是至关重要的，它们之间的交互是我们设计好的，但这会带来我们不希望的副作用——就是那些在我们自己测试的时候不希望的功能。
比如，可能我们正在写一个社交软件并且想测试一下“发布到Facebook的功能”，但是我们不希望每次运行测试集的时候都发布到Facebook上。
Python的unittest库中有一个子包叫unittest.mock——或者你把它声明成一个依赖，简化为mock——这个模块提供了非常强大并且有用的方法，通过它们可以模拟或者屏敝掉这些不受我们希望的方面。
注意：mock是最近收录在Python 3.3标准库中的；之前发布的版本必须通过 PyPI下载Mock库。
恐惧系统调用
再举一个例子，考虑系统调用，我们将在余下的文章中讨论它们。不难发现，这些都可以考虑使用模拟：无论你是想写一个脚本弹出一个CD驱动，或者是一个web服务用来删除/tmp目录下的缓存文件，或者是一个socket服务来绑定一个TCP端口，这些调用都是在你单元测试的时候是不被希望的方面。
作为一个开发人员，你更关心你的库是不是成功的调用了系统函数来弹出CD，而不是体验每次测试的时候CD托盘都打开。
作为一个开发人员，你更关心你的库是不是成功调用了系统函数来弹出CD（带着正确的参数等）。而不是体验每次测试的时候CD托盘都打开（或者更糟，很多次，当一个单元测试运行的时候，很多测试点都涉及到了弹出代码）。
同样地，保持你的单元测试效率和性能意味着要还要保留一些自动化测试之外的“缓慢代码”，比如文件系统和网络的访问。
对于我们的第一个例子，我们要重构一个从原始到使用mock的一个标准Python测试用例。我们将会证明如何用mock写一个测试用例使我们的测试更智能、更快，并且能暴露更多关于我们的软件工作的问题。
一个简单的删除功能
有时，我们需要从文件系统中删除文件，因此，我们可以写这样的一个函数在Python中，这个函数将使它更容易成为我们的脚本去完成这件事情。
#!/usr/bin/env python# -*- coding: utf-8 -*-import osdef rm(filename): os.remove(filename)
很明显，在这个时间点上，我们的rm方法不提供比基本os.remove方法更多的功能，但我们的代码将会有所改进，允许我们在这里添加更多的功能。
让我们写一个传统的测试用例，即，不用模拟测试：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import rmimport os.pathimport tempfileimport unittestclass RmTestCase(unittest.TestCase):
tmpfilepath = os.path.join(tempfile.gettempdir(), "tmp-testfile") def setUp(self):
with open(self.tmpfilepath, "wb") as f:
f.write("Delete me!")
def test_rm(self):
# remove the file
rm(self.tmpfilepath) # test that it was actually removed
self.assertFalse(os.path.isfile(self.tempfile), "Failed to remove the file.")
我们的测试用例是相当简单的，但当它每次运行时，一个临时文件被创建然后被删除。此外，我们没有办法去测试我们的rm方法是否传递参数到os.remove中。我们可以假设它是基于上面的测试，但仍有许多需要被证实。
重构与模拟测试
让我们使用mock重构我们的测试用例：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import rmimport mockimport unittestclass RmTestCase(unittest.TestCase):
@mock.patch('mymodule.os')
def test_rm(self, mock_os):
rm("any path") # test that rm called os.remove with the right parameters
mock_os.remove.assert_called_with("any path")
对于这些重构，我们已经从根本上改变了该测试的运行方式。现在，我们有一个内部的对象，让我们可以使用另一个功能验证。
潜在的陷阱
第一件要注意的事情就是，我们使用的mock.patch方法的装饰位于mymodule.os模拟对象，并注入到我们测试案例的模拟方法。是模拟os更有意义，还是它在mymodule.os的参考更有意义？
当然，当Python出现在进口和管理模块时，用法是非常的灵活。在运行时，该mymodule模块有自己的os操作系统——被引入到自己的范围内的模块。因此，如果我们模拟os系统，我们不会看到模拟测试在mymodule模块的影响。
这句话需要深刻的记住：
如果你需要为myproject.app.MyElaborateClass模拟tempfile模型，你可能需要去模拟myproject.app.tempfile的每个模块来保持自己的进口。
这就是用陷阱的方式来模拟测试。
向‘rm'中加入验证
之前定义的 rm 方法相当的简单 . 在盲目的删除之前，我们会拿它来验证一个路径是否存在，并验证其是否是一个文件. 让我们重构 rm 使其变得更加聪明:
#!/usr/bin/env python# -*- coding: utf-8 -*-import osimport os.pathdef rm(filename):
if os.path.isfile(filename):
os.remove(filename)
很好. 现在，让我们调整我们的测试用例来保持测试的覆盖程度.
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import rmimport mockimport unittestclass RmTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# set up the mock
mock_path.isfile.return_value = False
rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
rm("any path")
mock_os.remove.assert_called_with("any path")
我们的测试范例完全变化了. 现在我们可以核实并验证方法的内部功能是否有任何副作用.
将删除功能作为服务
到目前为止，我们只是对函数功能提供模拟测试，并没对需要传递参数的对象和实例的方法进行模拟测试。接下来我们将介绍如何对对象的方法进行模拟测试。
首先，我们先将rm方法重构成一个服务类。实际上将这样一个简单的函数转换成一个对象并不需要做太多的调整，但它能够帮助我们了解mock的关键概念。下面是重构的代码:
#!/usr/bin/env python# -*- coding: utf-8 -*-import osimport os.pathclass RemovalService(object):
"""A service for removing objects from the filesystem."""
def rm(filename):
if os.path.isfile(filename):
os.remove(filename)
你可以发现我们的测试用例实际上没有做太多的改变：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import RemovalServiceimport mockimport unittestclass RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
很好，RemovalService如同我们计划的一样工作。接下来让我们创建另一个以该对象为依赖项的服务:
#!/usr/bin/env python# -*- coding: utf-8 -*-import osimport os.pathclass RemovalService(object):
"""A service for removing objects from the filesystem."""
def rm(filename):
if os.path.isfile(filename):
os.remove(filename)
class UploadService(object):
def __init__(self, removal_service):
self.removal_service = removal_service
def upload_complete(filename):
self.removal_service.rm(filename)
到目前为止，我们的测试已经覆盖了RemovalService， 我们不会对我们测试用例中UploadService的内部函数rm进行验证。相反，我们将调用UploadService的RemovalService.rm方法来进行简单的测试（为了不产生其他副作用），我们通过之前的测试用例可以知道它可以正确地工作。
有两种方法可以实现以上需求:
- 模拟RemovalService.rm方法本身。
- 在UploadService类的构造函数中提供一个模拟实例。
因为这两种方法都是单元测试中非常重要的方法，所以我们将同时对这两种方法进行回顾。
选项1: 模拟实例的方法
该模拟库有一个特殊的方法用来装饰模拟对象实例的方法和参数。@mock.patch.object 进行装饰：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import RemovalService, UploadServiceimport mockimport unittestclass RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
class UploadServiceTestCase(unittest.TestCase):
@mock.patch.object(RemovalService, 'rm')
def test_upload_complete(self, mock_rm):
# build our dependencies
removal_service = RemovalService()
reference = UploadService(removal_service)
# call upload_complete, which should, in turn, call `rm`:
reference.upload_complete("my uploaded file")
# check that it called the rm method of any RemovalService
mock_rm.assert_called_with("my uploaded file")
# check that it called the rm method of _our_ removal_service
removal_service.rm.assert_called_with("my uploaded file")
太棒了！我们验证了上传服务成功调用了实例的rm方法。你是不是注意到这当中有意思的地方了？这种修补机制实际上取代了我们的测试方法的删除服务实例的rm方法。这意味着，我们实际上可以检查该实例本身。如果你想了解更多，可以试着在模拟测试的代码中下断点来更好的认识这种修补机制是如何工作的。
陷阱：装饰的顺序
当使用多个装饰方法来装饰测试方法的时候，装饰的顺序很重要，但很容易混乱。基本上，当装饰方法呗映射到带参数的测试方法中时，装饰方法的工作顺序是反向的。比如下面这个例子：
@mock.patch('mymodule.sys')
@mock.patch('mymodule.os')
@mock.patch('mymodule.os.path')
def test_something(self, mock_os_path, mock_os, mock_sys):
pass
注意到了吗，我们的装饰方法的参数是反向匹配的？ 这是有部分原因是因为Python的工作方式。下面是使用多个装饰方法的时候，实际的代码执行顺序：
patch_sys(patch_os(patch_os_path(test_something)))
由于这个关于sys的补丁在最外层，因此会在最后被执行，使得它成为实际测试方法的最后一个参数。请特别注意这一点，并且在做测试使用调试器来保证正确的参数按照正确的顺序被注入。
选项2: 创建模拟测试接口
我们可以在UploadService的构造函数中提供一个模拟测试实例，而不是模拟创建具体的模拟测试方法。 我推荐使用选项1的方法，因为它更精确，但在多数情况下，选项2是必要的并且更加有效。让我们再次重构我们的测试实例：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import RemovalService, UploadServiceimport mockimport unittestclass RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
class UploadServiceTestCase(unittest.TestCase):
def test_upload_complete(self, mock_rm):
# build our dependencies
mock_removal_service = mock.create_autospec(RemovalService)
reference = UploadService(mock_removal_service)
# call upload_complete, which should, in turn, call `rm`:
reference.upload_complete("my uploaded file")
# test that it called the rm method
mock_removal_service.rm.assert_called_with("my uploaded file")
在这个例子中，我们甚至不需要补充任何功能，只需创建一个带auto-spec方法的RemovalService类，然后将该实例注入到UploadService中对方法验证。
mock.create_autospec为类提供了一个同等功能实例。这意味着，实际上来说，在使用返回的实例进行交互的时候，如果使用了非法的方法将会引发异常。更具体地说，如果一个方法被调用时的参数数目不正确，将引发一个异常。这对于重构来说是非常重要。当一个库发生变化的时候，中断测试正是所期望的。如果不使用auto-spec，即使底层的实现已经破坏，我们的测试仍然会通过。
陷阱：mock.Mock和mock.MagicMock类
mock库包含两个重要的类mock.Mock和mock.MagicMock，大多数内部函数都是建立在这两个类之上的。在选择使用mock.Mock实例，mock.MagicMock实例或auto-spec方法的时候,通常倾向于选择使用 auto-spec方法，因为它能够对未来的变化保持测试的合理性。这是因为mock.Mock和mock.MagicMock会无视底层的API，接受所有的方法调用和参数赋值。比如下面这个用例：
class Target(object):
def apply(value):
return valuedef method(target, value):
return target.apply(value)
我们像下面这样使用mock.Mock实例来做测试：
class MethodTestCase(unittest.TestCase):
def test_method(self):
target = mock.Mock()
method(target, "value")
target.apply.assert_called_with("value")
这个逻辑看似合理，但如果我们修改Target.apply方法接受更多参数：
class Target(object):
def apply(value, are_you_sure):
if are_you_sure: return value else: return None
重新运行你的测试，然后你会发现它仍然能够通过。这是因为它不是针对你的API创建的。这就是为什么你总是应该使用create_autospec方法，并且在使用@patch和@patch.object装饰方法时使用autospec参数。
真实世界的例子: 模仿一次 Facebook API 调用
在结束之际，让我写一个更加实用的真实世界的例子, 这在我们的介绍部分曾今提到过: 向Facebook发送一个消息. 我们会写一个漂亮的封装类，和一个产生回应的测试用例.
import facebookclass SimpleFacebook(object):
def __init__(self, oauth_token):
self.graph = facebook.GraphAPI(oauth_token) def post_message(self, message):
"""Posts a message to the Facebook wall."""
self.graph.put_object("me", "feed", message=message)
下面是我们的测试用例, 它检查到我发送了信息，但并没有实际的发送出这条信息（到Facebook上）:
import facebookimport simple_facebookimport mockimport unittestclass SimpleFacebookTestCase(unittest.TestCase):
@mock.patch.object(facebook.GraphAPI, 'put_object', autospec=True)
def test_post_message(self, mock_put_object):
sf = simple_facebook.SimpleFacebook("fake oauth token")
sf.post_message("Hello World!") # verify
mock_put_object.assert_called_with(message="Hello World!")
就我们目前所看到的，在Python中用 mock 开始编写更加聪明的测试是真的很简单的.
总结
Python的 mock 库, 使用起来是有点子迷惑, 是单元测试的游戏规则变革者. 我们通过开始在单元测试中使用 mock ，展示了一些通常的使用场景, 希望这篇文章能帮助 Python 克服一开始的障碍，写出优秀的，能经得起测试的代码.
핫 AI 도구
Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱
AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.
Undress AI Tool
무료로 이미지를 벗다
Clothoff.io
AI 옷 제거제
AI Hentai Generator
AI Hentai를 무료로 생성하십시오.
인기 기사
뜨거운 도구
메모장++7.3.1
사용하기 쉬운 무료 코드 편집기
SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.
스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경
드림위버 CS6
시각적 웹 개발 도구
SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)
뜨거운 주제
7470
15
1377
52
77
11
48
19
19
29
MySQL은 지불해야합니다
Apr 08, 2025 pm 05:36 PM
MySQL에는 무료 커뮤니티 버전과 유료 엔터프라이즈 버전이 있습니다. 커뮤니티 버전은 무료로 사용 및 수정할 수 있지만 지원은 제한되어 있으며 안정성이 낮은 응용 프로그램에 적합하며 기술 기능이 강합니다. Enterprise Edition은 안정적이고 신뢰할 수있는 고성능 데이터베이스가 필요하고 지원 비용을 기꺼이 지불하는 응용 프로그램에 대한 포괄적 인 상업적 지원을 제공합니다. 버전을 선택할 때 고려 된 요소에는 응용 프로그램 중요도, 예산 책정 및 기술 기술이 포함됩니다. 완벽한 옵션은없고 가장 적합한 옵션 만 있으므로 특정 상황에 따라 신중하게 선택해야합니다.
설치 후 MySQL을 사용하는 방법
Apr 08, 2025 am 11:48 AM
이 기사는 MySQL 데이터베이스의 작동을 소개합니다. 먼저 MySQLworkBench 또는 명령 줄 클라이언트와 같은 MySQL 클라이언트를 설치해야합니다. 1. MySQL-Uroot-P 명령을 사용하여 서버에 연결하고 루트 계정 암호로 로그인하십시오. 2. CreateABase를 사용하여 데이터베이스를 작성하고 데이터베이스를 선택하십시오. 3. CreateTable을 사용하여 테이블을 만들고 필드 및 데이터 유형을 정의하십시오. 4. InsertInto를 사용하여 데이터를 삽입하고 데이터를 쿼리하고 업데이트를 통해 데이터를 업데이트하고 DELETE를 통해 데이터를 삭제하십시오. 이러한 단계를 마스터하고 일반적인 문제를 처리하는 법을 배우고 데이터베이스 성능을 최적화하면 MySQL을 효율적으로 사용할 수 있습니다.
MySQL 다운로드 파일이 손상되어 설치할 수 없습니다. 수리 솔루션
Apr 08, 2025 am 11:21 AM
MySQL 다운로드 파일은 손상되었습니다. 어떻게해야합니까? 아아, mySQL을 다운로드하면 파일 손상을 만날 수 있습니다. 요즘 정말 쉽지 않습니다! 이 기사는 모든 사람이 우회를 피할 수 있도록이 문제를 해결하는 방법에 대해 이야기합니다. 읽은 후 손상된 MySQL 설치 패키지를 복구 할 수있을뿐만 아니라 향후에 갇히지 않도록 다운로드 및 설치 프로세스에 대해 더 깊이 이해할 수 있습니다. 파일 다운로드가 손상된 이유에 대해 먼저 이야기합시다. 이에 대한 많은 이유가 있습니다. 네트워크 문제는 범인입니다. 네트워크의 다운로드 프로세스 및 불안정성의 중단으로 인해 파일 손상이 발생할 수 있습니다. 다운로드 소스 자체에도 문제가 있습니다. 서버 파일 자체가 고장 났으며 물론 다운로드하면 고장됩니다. 또한 일부 안티 바이러스 소프트웨어의 과도한 "열정적 인"스캔으로 인해 파일 손상이 발생할 수 있습니다. 진단 문제 : 파일이 실제로 손상되었는지 확인하십시오
다운로드 후 MySQL을 설치할 수 없습니다
Apr 08, 2025 am 11:24 AM
MySQL 설치 실패의 주된 이유는 다음과 같습니다. 1. 권한 문제, 관리자로 실행하거나 Sudo 명령을 사용해야합니다. 2. 종속성이 누락되었으며 관련 개발 패키지를 설치해야합니다. 3. 포트 충돌, 포트 3306을 차지하는 프로그램을 닫거나 구성 파일을 수정해야합니다. 4. 설치 패키지가 손상되어 무결성을 다운로드하여 확인해야합니다. 5. 환경 변수가 잘못 구성되었으며 운영 체제에 따라 환경 변수를 올바르게 구성해야합니다. 이러한 문제를 해결하고 각 단계를 신중하게 확인하여 MySQL을 성공적으로 설치하십시오.
MySQL 설치 후 시작할 수없는 서비스에 대한 솔루션
Apr 08, 2025 am 11:18 AM
MySQL이 시작을 거부 했습니까? 당황하지 말고 확인합시다! 많은 친구들이 MySQL을 설치 한 후 서비스를 시작할 수 없다는 것을 알았으며 너무 불안했습니다! 걱정하지 마십시오.이 기사는 침착하게 다루고 그 뒤에있는 마스터 마인드를 찾을 수 있습니다! 그것을 읽은 후에는이 문제를 해결할뿐만 아니라 MySQL 서비스에 대한 이해와 문제 해결 문제에 대한 아이디어를 향상시키고보다 강력한 데이터베이스 관리자가 될 수 있습니다! MySQL 서비스는 시작되지 않았으며 간단한 구성 오류에서 복잡한 시스템 문제에 이르기까지 여러 가지 이유가 있습니다. 가장 일반적인 측면부터 시작하겠습니다. 기본 지식 : 서비스 시작 프로세스 MySQL 서비스 시작에 대한 간단한 설명. 간단히 말해서 운영 체제는 MySQL 관련 파일을로드 한 다음 MySQL 데몬을 시작합니다. 여기에는 구성이 포함됩니다
고로드 애플리케이션의 MySQL 성능을 최적화하는 방법은 무엇입니까?
Apr 08, 2025 pm 06:03 PM
MySQL 데이터베이스 성능 최적화 안내서 리소스 집약적 응용 프로그램에서 MySQL 데이터베이스는 중요한 역할을 수행하며 대규모 트랜잭션 관리를 담당합니다. 그러나 응용 프로그램 규모가 확장됨에 따라 데이터베이스 성능 병목 현상은 종종 제약이됩니다. 이 기사는 일련의 효과적인 MySQL 성능 최적화 전략을 탐색하여 응용 프로그램이 고 부하에서 효율적이고 반응이 유지되도록합니다. 실제 사례를 결합하여 인덱싱, 쿼리 최적화, 데이터베이스 설계 및 캐싱과 같은 심층적 인 주요 기술을 설명합니다. 1. 데이터베이스 아키텍처 설계 및 최적화 된 데이터베이스 아키텍처는 MySQL 성능 최적화의 초석입니다. 몇 가지 핵심 원칙은 다음과 같습니다. 올바른 데이터 유형을 선택하고 요구 사항을 충족하는 가장 작은 데이터 유형을 선택하면 저장 공간을 절약 할 수있을뿐만 아니라 데이터 처리 속도를 향상시킬 수 있습니다.
MySQL 설치 후 데이터베이스 성능을 최적화하는 방법
Apr 08, 2025 am 11:36 AM
MySQL 성능 최적화는 설치 구성, 인덱싱 및 쿼리 최적화, 모니터링 및 튜닝의 세 가지 측면에서 시작해야합니다. 1. 설치 후 innodb_buffer_pool_size 매개 변수와 같은 서버 구성에 따라 my.cnf 파일을 조정해야합니다. 2. 과도한 인덱스를 피하기 위해 적절한 색인을 작성하고 Execution 명령을 사용하여 실행 계획을 분석하는 것과 같은 쿼리 문을 최적화합니다. 3. MySQL의 자체 모니터링 도구 (showprocesslist, showstatus)를 사용하여 데이터베이스 건강을 모니터링하고 정기적으로 백업 및 데이터베이스를 구성하십시오. 이러한 단계를 지속적으로 최적화함으로써 MySQL 데이터베이스의 성능을 향상시킬 수 있습니다.
MySQL은 인터넷이 필요합니까?
Apr 08, 2025 pm 02:18 PM
MySQL은 기본 데이터 저장 및 관리를위한 네트워크 연결없이 실행할 수 있습니다. 그러나 다른 시스템과의 상호 작용, 원격 액세스 또는 복제 및 클러스터링과 같은 고급 기능을 사용하려면 네트워크 연결이 필요합니다. 또한 보안 측정 (예 : 방화벽), 성능 최적화 (올바른 네트워크 연결 선택) 및 데이터 백업은 인터넷에 연결하는 데 중요합니다.
