状态/交互测试和混合(或滥用)它们的混淆

我认为理解基于状态/交互的测试的定义(阅读Fowler的东西等)。我发现我开始基于状态,但一直在做更多的基于交互的工作,我对如何测试某些东西有点困惑。

我在MVC中有一个控制器,一个操作调用一个服务来拒绝包:

public ActionResult Deny(int id)
{
    service.DenyPackage(id);

    return RedirectToAction("List");
}

我觉得这很清楚。提供模拟服务,验证是否正确调用,完成。

现在,我有了一个视图的操作,该视图允许用户将证书与包相关联:

public ActionResult Upload(int id)
{
    var package = packageRepository.GetPackage(id);
    var certificates = certificateRepository.GetAllCertificates();

    var view = new PackageUploadViewModel(package, certificates);

    return View(view);
}

这个我有点受不了。我正在做规范风格的测试(可能不正确),所以为了测试这个方法,我有一个类,然后进行两个测试:验证包存储库是否被调用,验证证书存储库是否被调用。实际上,我想让第三个测试来验证是否调用了构造函数,但不知道如何这样做!我觉得这是完全错误的。

因此,对于基于状态的测试,我将传入ID,然后测试actionResult的视图。好吧,这是有道理的。但是,我不是要对PackageUploadViewModel构造函数进行测试吗?因此,如果我对构造函数进行了测试,那么我的一部分只想确认我调用了构造函数,并且操作返回与构造函数返回的内容匹配。

现在,我可以想到的另一个选项是,我有一个PackageUploadViewModelBuilder(或者同样名字很模糊的东西),它依赖于两个存储库,然后我只需将ID传递给一个CreateViewModel方法或其他东西。然后我可以模仿这个对象,验证所有的东西,并且快乐。但是…好。。。看起来很奢侈。我在做一些简单的事情…不简单。另外,controller.action(id)返回builder.create(id)似乎是无故添加层(控制器负责构建视图模型)。对吗?)

我不知道…我认为更多的基于状态的测试是必要的,但是我担心如果我开始测试返回值,那么如果方法A可以在8种不同的上下文中被调用,我会有一个测试爆炸式的重复。我一直在使用基于交互的测试将一些上下文传递给方法B,这样我所要做的就是验证方法A(称为方法B),并且我测试了方法B,这样方法A就可以信任这些上下文是被处理的。因此,基于交互的测试正在构建这种测试层次结构,但是基于状态的测试将使它变得更平坦一些。

我不知道这是否有意义。

哇,这太长了…