我正在重构整个项目,通过类的构造函数注入依赖关系,从而使其单元可测试。这消除了对象以独立方式实例化的情况(这不是单元可测试的,因为我不再直接控制这些对象)。我很困惑是否应该注入python内置模块,如os或json。
我创建了一个工厂,它具有返回类或对象的静态方法。这使得依赖注入成为可能。
最初:
import json
def do_something(self):
object_a = UserClassA()
some_value = json.dumps({})目前:
def do_something(self, factory_object):
object_a = factory_object.get_user_class_a()
some_value = factory_object.get_json().dumps({})后一种实现使它具有可测试性。已经处理了定制类A和内置模块json。但是,以这种方式注入json是否是使代码单元可测试的正确方法呢?还是修补它更好?
发布于 2019-09-04 12:41:24
TL;DR :你在这里走的太远了!
虽然在某些用例中使用依赖注入是有意义的,但至少可以说,这里的方法有点极端。您是否计划为内置类型和功能提供DI?)
Python是动态的--非常动态--所以很容易用您想要的任何东西(手动或mock )对模块的顶级名称进行猴子孵化。
wrt/您的示例,保持原始代码如下:
import json
class UserClassA():
# ....
class Foo(object):
def do_something(self):
object_a = UserClassA()
some_value = json.dumps({})在您的测试中,monkeypatch或模拟yourmodule.json和/或yourmodule.UserClassA --并保留DI以供正常使用时使用(IOW,不要只为统一使用而添加DI,除非您有一个特殊情况,即monkeypatch/模拟解决方案确实不方便,但这实际上非常罕见)。
编写代码更容易统一(通过支持纯函数、使函数和类更好地专注于单个响应性等)--这是一个很好的选择--它通常会导致代码更容易阅读和维护。但是单元测试并不是目标--目标是一个程序,即(按重要性排序) 1/正确(做它应该做的事情)、2/健壮(正确地处理角落情况和意外情况而不损坏宝贵的数据或产生错误的结果)和3/可维护。
拥有一个完整的覆盖范围有助于实现这三个目标,但前提是它不能将您的代码库变成一个过度设计的、不可阅读的混乱,没有任何其他的无用的间接级别,实际上只会取悦“敏捷”狂热者。有疑问的时候,看看这个
哦,是的:单元测试并不是免费的--您必须编写它们,但更重要的是,您必须在代码更改时维护它们。所以,也不要落入"100%单一覆盖“的陷阱,你主要想测试(我是说)关键内容的自动化测试。
https://stackoverflow.com/questions/57787498
复制相似问题