在实际实现和模拟中混合是一种测试味道吗？
我有一个消费者类，负责使用字符串并决定如何处理它。它可以解析并将解析数据插入数据库或通知管理员。
下面是我的实现。
public void Consume(string email)
{
if(_emailValidator.IsLocate(email))
{
var parsedLocate = _parser.Parse(email);
// Insert locate in database
}
else if(_emailValidator.IsGoodNightCall(email))
{
// Notify email notifying them that a locate email requires attention.
_notifier.Notify();
}
}
以下是我的单元测试。
// Arrange
var validator = new EmailValidator();
var parser = new Mock<IParser>();
var notifier = new Mock<INotifier>();
var consumer = new LocateConsumer(validator, parser.Object, notifier.Object);
var email = EmailLiterals.Locate;
// Act
consumer.Consume(email);
// Assert
parser.Verify(x => x.Parse(email), Times.Once());
在单元测试中混合模拟和实际实现是否有代码味道？另外，如何总是必须测试方法 abc() 是否总是运行一次？每次在 if 块中添加函数时都添加新的单元测试，这似乎不太正确。似乎如果我继续添加到我的 Consume 方法中，我就会创建一个陷阱。
谢谢。
I have a consumer class responsible for consuming a string and deciding what to do with it. It can either parse and insert the parse data in a database or notify an administrator.
Below is my implementation.
public void Consume(string email)
{
if(_emailValidator.IsLocate(email))
{
var parsedLocate = _parser.Parse(email);
// Insert locate in database
}
else if(_emailValidator.IsGoodNightCall(email))
{
// Notify email notifying them that a locate email requires attention.
_notifier.Notify();
}
}
Below is my unit test.
// Arrange
var validator = new EmailValidator();
var parser = new Mock<IParser>();
var notifier = new Mock<INotifier>();
var consumer = new LocateConsumer(validator, parser.Object, notifier.Object);
var email = EmailLiterals.Locate;
// Act
consumer.Consume(email);
// Assert
parser.Verify(x => x.Parse(email), Times.Once());
Is it code smell to mix mocks and real implementation in unit tests? Also, how do always having to test whether method abc() always ran once? It doesn't seem right that once I add a new unit test every time I add a function inside my if block. Seems like if I continue adding to my Consume method I'm create a trap.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
严格来说，单元测试是一种独立测试单元的自动化测试。如果组合两个或多个单元，它就不再是单元测试，而是集成测试。
但是，根据您集成的单元的类型，进行大量此类集成测试可能是没问题的。
Krzysztof Kozmic 最近写了一篇关于此的博客文章，其中描述了 Castle Windsor 的单元测试很少，但集成测试很多。 AutoFixture 也有很大一部分此类集成测试。我认为最重要的一点是，作为一般规则，集成不得跨越库边界。
无论如何，您都可以将实际实现视为Test Double Continuum，因此，正如在某些情况下使用存根、模拟、间谍或假货是有意义的一样，也有实际实现可能有意义的情况 。
但是，请记住，您不再孤立地测试单元，因此您确实在单元之间引入了耦合，使得独立改变每个单元变得更加困难。
总而言之，我仍然认为这是一种气味，因为它应该始终是一个停下来思考的机会。然而，气味仅表明这一点，有时，一旦你仔细考虑，你就可以决定继续前进。
To be nitpicking, a unit test is an automated test that tests a unit in isolation. If you combine two or more units, it's not a unit test any more, it's an integration test.
However, depending on the type of units you integrate, having lots of that type of integration tests may be quite okay.
Krzysztof Kozmic recently wrote a blog post about this where he describes how Castle Windsor has very few unit tests, but lots of integration tests. AutoFixture also has a large share of those types of integration tests. I think the most important point is that as a general rule the integration must not cross library boundaries.
In any case you can view the actual implementation as an extreme end of the Test Double Continuum, so just as there are scenarios where it makes sense to use Stubs, Mocks, Spies, or Fakes, there are also scenarios where the actual implementation may make sense.
However, just keep in mind that you are no longer testing the unit in isolation, so you do introduce a coupling between the units that makes it more difficult to vary each independently.
To conclude, I still consider it a smell because it should always be an occasion to stop and think. However, a smell indicates no more than that, and sometimes, once you've thought it over, you can decide to move along.
我会强烈地说“是”。单元测试应该没有组件之间的依赖关系。
I would say a strong yes. Unit testing should be free of dependencies among components.
这是一个集成测试（组合2个或更多模块），而不是单元测试（单独测试一个模块）
我的答案是否：我认为有模拟是可以的在集成测试中。
This is an integration test (combining 2 or more modules) and not a unittest (test one module in isolation)
My answer is No: I think it is ok to have mocks in integration test.