我有一个方法,我想单元测试,一个检查三张卡之间的匹配。由于卡片是随机生成的,因此无法设置我知道会匹配或不匹配的三张卡片。我需要这样做来单元测试我的isMatch()
方法。修改源代码以使单元测试有效吗?
是否可以改变我的卡类添加一个方法来显式设置它的值,所以我可以单元测试它?一般情况下,对源代码进行小的添加以使单元测试成为可能或者是否有更好的或正确的方法可以接受?
我有一个方法,我想单元测试,一个检查三张卡之间的匹配。由于卡片是随机生成的,因此无法设置我知道会匹配或不匹配的三张卡片。我需要这样做来单元测试我的isMatch()
方法。修改源代码以使单元测试有效吗?
是否可以改变我的卡类添加一个方法来显式设置它的值,所以我可以单元测试它?一般情况下,对源代码进行小的添加以使单元测试成为可能或者是否有更好的或正确的方法可以接受?
我考虑过使用卡片发生器,或者更具体地说使用CardFactory或CardBuilder。问题是Card类不需要大量的自上而下创建。所以我写了卡片类来管理自己的随机化。当其他类需要一张卡片时,他们只需要调用默认的构造函数,他们可以期待随机卡片。我相信自下而上的设计会更好,但它确实需要添加更多的代码才能明确地创建卡片,因此可以测试“isMatch”方法。 – Hal50000
做你正在做的事情当然很好,但是现在向卡类添加随机化,你永远不会有用于生成卡片的不同策略。这是一个很好的决定,但它确实会带来一些后果,因为你很可能已经注意到了。就像无法写出清晰简洁的单元测试一样。 [Bob叔叔](https://sites.google.com/site/unclebobconsultingllc/)会说你的卡片类有两件事,一般来说一个班只能做一件事。 – hooknc
将卡接口改为接受配置对象将是微不足道的。毕竟,我并没有写一个API,所以“从来没有一个不同的策略来生成卡”并不完全是一成不变的。你的建议是一个很好的建议,我最初写它时确实考虑过。问题是没有自我配置,Card类只是一个数据结构,持有卡的属性;那也不是很好的设计。正如你所提到的那样,整个设置并不为你所知,但我认为你的答案是最有用的。 – Hal50000
你应该将随机性的来源“随机”实例注入你的类中。在你的测试中,你可以创建一个已知的随机序列并测试逻辑。代码应该写成可测试的。如果它不是可测试的,那么应该改变它。 –
你是不是在为你的随机性使用种子?没有小写日志文件,所以你可以重新创建? –
@BoristheSpider,你可以详细说明注入'Random'实例吗?我不清楚你的意思。 – Hal50000