我有多个单独的测试类,它们都使用相同的测试对象。目前我在每个类中使用@Before,这显然不是一个很好的解决方案。
当然,一种选择是从创建此对象的抽象类继承。如上所述here,这也不是一个好主意。
另一种选择是外部资源,但就其名称而言 - 是资源而非测试对象。</ p>
我觉得我错过了一些东西,因为这一定是JUnit中的基本任务。
答案 0 :(得分:3)
您可能正在寻找TestRule
。引用Javadoc:
TestRule
是对测试方法或测试方法集的运行和报告方式的更改。TestRule
可能会添加额外的检查,导致测试无法通过,或者可能会对测试执行必要的设置或清理,或者可能会观察测试执行以在其他地方报告。 TestRules可以使用Before
,After
,BeforeClass
或AfterClass注释的方法完成之前可以完成的所有操作,但它们更强大,更容易在项目和类之间共享。 / p>
然后继续列出几种类型,其中ExternalResource
是一种;但也有其他人。
鉴于你谈到的事情要比使用@Before
方法更好,并且你想要在课堂之间分享,这听起来非常像你所描述的。
答案 1 :(得分:1)
恭喜您在设计中发现了一些需要改进的地方!这是编写测试的绝佳结果。
您说您在多个测试中使用相同的测试对象。我假设您的测试正在测试不同的类。我希望你在那些可以抽象成新类的不同类中发现了一些常见的行为。
之后,您的测试对象将测试新类,您可以将其从其他测试中删除,并且每次保留的行为都不同。好像是一个好结果!
答案 2 :(得分:0)
您可以在测试包中添加一个通用类,使其可用于静态。由于静态引用,它将使您在测试中更容易使用它。但我不确定它是否会在测试时消耗中获胜......
在单元测试的情况下,我实际上认为静态对象的获胜时间较少,因为它们都是从头开始再次构建每个测试类,但我记得JVM在某处更快地完成了它。 (请任何可以确认或以其他方式告诉我,因为我对此感到好奇)
答案 3 :(得分:0)
不要将您在interwebz上阅读的所有内容都视为面值。每个人都有一个意见,并在博客中写下它,那是什么。继承可能不是您遇到的问题的最佳解决方案,但它是一种解决方案。替代解决方案不是更漂亮。我曾多次尝试过继承测试,它们就像魅力一样。只是不要对它疯狂,不要创建完整的继承层次结构,你会没事的。
如果您真的想远离继承,您可以使用参数化测试。我认为你使用的是JUnit 4,所以你可以在这里阅读它们:org.junit.runners Class Parameterized
参数化测试并非完全是出于您想要的目的而发明的;它们为单个类的测试方法和您提供的一些测试数据元素的交叉产品创建实例,但是如果您使用单个数据元素,并且您使用工厂为所有您实例化相同的数据元素测试类,然后你可以实现你想要的效果。
就个人而言,我仍然更喜欢继承。