我正在使用nunit,moq并尝试进行TDD。
我有一个返回一些用户帐户的查询。我有另一个查询可以获取一系列条件。
我将浏览每个帐户并根据收集项检查每个帐户,并查看用户帐户属于哪种情况(如果有)。
public void Test()
{
var accounts = GetAccounts();
var conditions = GetConditions();
foreach(var a in accounts)
{
var found = conditions.Where(x => x.condition1 >= a.condition1 && x.condition2 <= a.condition2).FirstOrDefault();
if(found)
{
// move on to next condition in flow chart
}
else
{
continue;
}
}
}
我如何在TDD中测试它。我想验证是否找到了合适的条件?我不认为这是一个公共方法是明智的,我没有看到我的应用程序检查条件的任何意义。
所以我不确定实际测试的是什么,因为这个条件后来用来计算一个数字,这是我可以用来验证调用的条件是否合适的东西。事情是,这基本上意味着方法的结束和数字可能已经受到任何其他东西的影响,并将打败我如何理解TDD(你一次写一个方法,但首先进行单元测试测试它)
修改
是的,这就是我开始做的事情。我做了我的嘲笑和假物品。并设置了一切,但后来我被困在用于验证结果的东西上。 我正在制作的方法很可能会保持无效(它会记录错误或在某个时候更新客户帐户)。它确实是应用程序中唯一的公共方法,因为应用程序将作为计划任务运行(它是一个控制台应用程序),因此它基本上是“运行”方法。它将在业务层中包含许多私有方法,包含所有业务案例。最后,用户会被跳过,或者如果他们满足条件,他们将受到惩罚。 罚款将更新到他们的帐户。
是的我可以将条件方法设为公共或内部,但我没有看到业务层之外的任何方法应该知道它们。它只是与该业务层相关,然后仅在该“运行”方法运行时才会发生。
这就是让TDD对我这么难的原因。他们说只测试公共方法,如果我说的是一个与用户交互的网站,并且很可能会向用户发送某种反馈(即成功消息/结果),那么什么是正常的。但是当你得到一个应该作为计划任务运行的应用程序,它只运行一个公共方法而其余的只是业务规则时,我很难弄清楚如何测试它。
什么是SUT内部?
答案 0 :(得分:0)
您在备注中提到了流程图。那么,为什么不创建一个流程图对象并对其进行测试。你将有一个方法,如GetNextStep接收一个帐户,然后你看到返回的步骤是你期望的步骤。
答案 1 :(得分:0)
与任何测试一样,您需要指定一些假依赖项(在这种情况下是用户和条件),并将您正在测试的函数的输出与预定义的预期结果进行比较(在这种情况下,如果我理解的话)正确地说,您想验证每个帐户是否具有预期条件。)
您可以编写一个测试,将假用户列表和伪规则列表注入您的SUT(被测系统),并将实际的用户列表及其条件与预期列表进行比较。
您的测试看起来像这样:
[Test]
public void Rules_matcher_with_premium_users_should_have_free_access()
{
var customer = Mock<IAccount>>);
var condition = Mock<ICondition>();
customer.Setup(c => ...); // set up condition
condition.Setup(co => ...); // set up condition
var sut = new MyBusinessLogic(customer.object, condition.object);
var result = sut.DoConditionCheck();
Assert.AreEqual(condition.object.Id, customer.object.Condition.Id);
}
我在这里所做的是一个测试的例子,如你所说,客户应该拥有合适的条件。我使用存根条件和客户,并假设规则引擎应该有效,客户应该 那个条件。
至于封装:根据大多数TDD纯粹主义者,您只测试公共API。其他任何内容都将作为您测试的公共API 调用的副作用进行测试。如果它不公开,则是实施细节,无需直接 进行测试。如果需要进行测试,请将其公开。
我稍稍放松一下。您可以将SUT设置为内部,并使用 InternalsVisibleTo
属性公开它以进行单元测试,并指定测试程序集。