由于我一直在编写测试,所以我一直坚持每个测试一个断言的原则。现在假设我有一个简单的应用程序,我想使用以下三个测试用例执行系统测试:
- 测试用户是否可以注册新帐户
- 测试用户是否可以登录
- 测试登录用户是否可以添加帖子
我知道在单元测试中,所有三个测试都可以通过模拟其他组件来独立执行。但是,在系统测试中,2. 取决于 1.,而 3. 取决于 2。
我一直在思考如何在测试中对这种依赖关系进行建模,同时仍然保持每个测试原则的一个断言。直到最近,我只是简单地编写三个独立的测试用例,其中每个必要的步骤都在测试代码中重复。然而,这通常会导致测试代码重复,从而导致难以维护测试代码。所以我开始像这个伪代码示例一样级联我的测试:
def test_register_user():
new_user = app.register new user()
assert(new_user in app.list_of_users())
return new_user
def test_login():
user = test_register_user()
logged_in_user = app.log_in_user(user)
assert(logged_in_user in app.list_of_logged_in_users())
return logged_in_user
def test_write_post():
app.write_post(text="text", user=test_login())
assert("text" in app.list_posts())
所以如果test_write_post()
被执行,它会调用test_login()
and test_register_user()
。我喜欢这种方法,因为它确实减少了测试代码的重复。但是,我不确定它是否违反了“每个测试一个断言”的原则。一方面,只有一个断言直接属于被测试的方法。另一方面,如果您遵循测试用例的执行路径,则会检查多个断言。
我的问题是:所呈现的级联测试风格是否违反了“每个测试一个断言”的原则?如果是这样,是否有更好的做法可以处理系统测试中的依赖关系,同时保持测试代码的可维护性?