具有具体类作为返回类型的单元测试工厂方法 [英] Unit testing factory methods which have a concrete class as a return type

查看:79
本文介绍了具有具体类作为返回类型的单元测试工厂方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我有一个工厂类,我正在尝试确定单元测试应该做什么.通过这个问题,我可以验证返回的接口是我期望的特定具体类型.

So I have a factory class and I'm trying to work out what the unit tests should do. From this question I could verify that the interface returned is of a particular concrete type that I would expect.

如果工厂正在返回具体类型,我应该检查什么(因为目前(不需要)使用接口)?目前,我正在执行以下操作:

What should I check for if the factory is returning concrete types (because there is no need - at the moment - for interfaces to be used)? Currently I'm doing something like the following:

[Test]
public void CreateSomeClassWithDependencies()
{
    // m_factory is instantiated in the SetUp method
    var someClass = m_factory.CreateSomeClassWithDependencies();

    Assert.IsNotNull(someClass);
}

此问题是Assert.IsNotNull似乎有点多余.

The problem with this is that the Assert.IsNotNull seems somewhat redundant.

此外,我的工厂方法可能正在设置该特定类的依赖项,如下所示:

Also, my factory method might be setting up the dependencies of that particular class like so:

public SomeClass CreateSomeClassWithDependencies()
{
    return new SomeClass(CreateADependency(), CreateAnotherDependency(),
                         CreateAThirdDependency());
}

我想确保我的工厂方法正确设置了所有这些依赖项.没有其他方法可以执行这些依赖项public/internal属性,然后在单元测试中检查这些属性? (我不太喜欢修改测试主题以适合测试)

And I want to make sure that my factory method sets up all these dependencies correctly. Is there no other way to do this then to make those dependencies public/internal properties which I then check for in the unit test? (I'm not a big fan of modifying the test subjects to suit the testing)

针对Robert Harvey的问题,我使用NUnit作为我的单元测试框架(但我不认为这会带来太大的改变)

In response to Robert Harvey's question, I'm using NUnit as my unit testing framework (but I wouldn't have thought that it would make too much of a difference)

推荐答案

通常,创建可用于基于状态的测试的公共属性没有错.是:您创建的用于启用测试方案的代码,但这是否会损害您的API?可以想象其他客户以后会发现相同的属性有用吗?

Often, there's nothing wrong with creating public properties that can be used for state-based testing. Yes: It's code you created to enable a test scenario, but does it hurt your API? Is it conceivable that other clients would find the same property useful later on?

特定于测试的代码与测试驱动的设计"之间有一条细线.我们不应该引入除了满足测试要求之外没有其他潜力的代码,但是引入遵循公认设计原则的新代码是完全可以的.我们让测试驱动是我们的设计-这就是为什么我们称其为TDD:)

There's a fine line between test-specific code and Test-Driven Design. We shouldn't introduce code that has no other potential than to satisfy a testing requirement, but it's quite alright to introduce new code that follow generally accepted design principles. We let the testing drive our design - that's why we call it TDD :)

在我看来,为类提供一个或多个属性以使用户有更好的机会检查该类通常是一件合理的事情,因此,我认为您不应该拒绝引入此类属性.

Adding one or more properties to a class to give the user a better possibility of inspecting that class is, in my opinion, often a reasonable thing to do, so I don't think you should dismiss introducing such properties.

除此之外,我第二个纳德的回答:)

Apart from that, I second nader's answer :)

这篇关于具有具体类作为返回类型的单元测试工厂方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆