2015-04-12 28 views
0

我有一个方法,我想单元测试,一个检查三张卡之间的匹配。由于卡片是随机生成的,因此无法设置我知道会匹配或不匹配的三张卡片。我需要这样做来单元测试我的isMatch()方法。修改源代码以使单元测试有效吗?

是否可以改变我的卡类添加一个方法来显式设置它的值,所以我可以单元测试它?一般情况下,对源代码进行小的添加以使单元测试成为可能或者是否有更好的或正确的方法可以接受?

+1

你应该将随机性的来源“随机”实例注入你的类中。在你的测试中,你可以创建一个已知的随机序列并测试逻辑。代码应该写成可测试的。如果它不是可测试的,那么应该改变它。 –

+0

你是不是在为你的随机性使用种子?没有小写日志文件,所以你可以重新创建? –

+0

@BoristheSpider,你可以详细说明注入'Random'实例吗?我不清楚你的意思。 – Hal50000

回答

1

不知道你的设置是什么,但为什么不让卡片发生器成为你班级的可插拔组件,并且fake保证返回三张匹配的卡片?

然后,你可以fake一个类,保证返回三张不匹配的卡。

+0

我考虑过使用卡片发生器,或者更具体地说使用CardFactory或CardBuilder。问题是Card类不需要大量的自上而下创建。所以我写了卡片类来管理自己的随机化。当其他类需要一张卡片时,他们只需要调用默认的构造函数,他们可以期待随机卡片。我相信自下而上的设计会更好,但它确实需要添加更多的代码才能明确地创建卡片,因此可以测试“isMatch”方法。 – Hal50000

+0

做你正在做的事情当然很好,但是现在向卡类添加随机化,你永远不会有用于生成卡片的不同策略。这是一个很好的决定,但它确实会带来一些后果,因为你很可能已经注意到了。就像无法写出清晰简洁的单元测试一样。 [Bob叔叔](https://sites.google.com/site/unclebobconsultingllc/)会说你的卡片类有两件事,一般来说一个班只能做一件事。 – hooknc

+1

将卡接口改为接受配置对象将是微不足道的。毕竟,我并没有写一个API,所以“从来没有一个不同的策略来生成卡”并不完全是一成不变的。你的建议是一个很好的建议,我最初写它时确实考虑过。问题是没有自我配置,Card类只是一个数据结构,持有卡的属性;那也不是很好的设计。正如你所提到的那样,整个设置并不为你所知,但我认为你的答案是最有用的。 – Hal50000

-3

不可以。你不应该为你的单元测试修改你的代码并修改它,所以“代码运行”。对于所描述的问题,您有@Before。围绕此设计你的课程。构建三张确定性卡并进行比较。通过这个注释,您可以测试代码的功能,而无需“修改代码进行单元测试”。

+0

我正在使用@before。这不是问题,问题是当前的界面没有创建卡片的确定性方法。这不是代码运行的问题。它运行在两种情况下,在原来的,如果我添加一个方法,使卡确定性。我只是问是否向源添加方法是“正确的”,以便测试可以完成。 – Hal50000

+2

@ Hal50000这绝对没错。 – Turing85

相关问题