测试始终返回 True 的函数
如何为以下函数编写测试?
bool IsAnInterger(int ignore)
{
return true
}
我没有足够的时间来迭代每个整数(对于实际代码,参数甚至不是整数)。
这用作规范模式的一部分,以便我可以实现空对象。
How would one write a test for the following function?
bool IsAnInterger(int ignore)
{
return true
}
I don't have enough time to iterate over every integer (for the actual code the parameter isn't even an integer).
This is used as part of the Specification Pattern, so that I can implement a Null Object.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我想说,尝试彻底地黑盒测试这个函数是没有意义的。最好在与使用它的环境类似的环境中对其进行测试。
I'd say that it's pointless to try to exhaustively black box test this function. It is better to test it in a context similar to where it will be used.
在 TDD 中,您首先编写测试,并且该测试应该指定特定的行为。因此,问题应该始终是:我期望发生什么? - 然后编写测试来验证该行为 - 最后编写解决方案以使测试通过。
编辑:理解问题
你的意思是这个函数是不存在的规范的行为,例如空规范?您当然可以测试这个空规范,它是否以某种方式表现。但据猜测,这几乎是硬编码的单行返回值(如果有的话)。然后,对该 null 对象的测试基本上只会记录 null 规范应该做什么。它不会给系统增加任何其他额外的业务价值。
In TDD, you write the test first and that test should specify a specific behavior. So the question should always be: What do I expect to happen? - and then write the test to verify that behavior - finally write the solution to make the test pass.
edit: Understanding the question
Do you mean that this function is the behavior for a non-existent specification, e.g. a Null specification? You can of course test this null specification that it behaves in a certain way. At a guess though, this will pretty much be hard-coded one-line return values (if anything). The tests for this null object would then basically only document what the null specification should do. It won't add any other extra business value to the system.
由于您无法合理地测试每种情况,因此您可以使用数学归纳法作为基础 供您测试。您无法通过代数计算,但可以为
n
选择任意值。编辑
坚持住!
那么它是什么?
您的函数具有 100% 的测试覆盖率,并且您的单元测试准确地记录了它的行为方式。在 TDD 中,您只需要编写足够代码,以便单元测试通过。您已完成此操作并可以继续。
Since you cannot reasonably test every case, you can use Mathematical Induction as a basis for your tests. You can't do this algebraically, but you can pick an arbitrary value for
n
.Edit
Hold on!
What is it then?
Your function has 100% test coverage and your unit tests accurately document how it behaves. In TDD you only need to write just enough code so that your unit tests pass. You're done with this and can move on.