对于 C# 中的单元测试,我从实现新功能或开始新解决方案的想法中看到了这一点,最好从那时开始进行单元测试。
但是,当已经建立了一个完全成熟的解决方案而几乎没有创建单元测试时,如果已经有足够的异常处理,那么测试的意义何在?
我正在编写单元测试,但是当我无法将格式错误的数据传递到任何我正在测试的东西中时,我没有看到这一点,因为我主要使用的是 ENUM!
除非我错过了一些绝对疯狂的东西。我是否在浪费时间回到旧代码来集成单元测试?
对于 C# 中的单元测试,我从实现新功能或开始新解决方案的想法中看到了这一点,最好从那时开始进行单元测试。
但是,当已经建立了一个完全成熟的解决方案而几乎没有创建单元测试时,如果已经有足够的异常处理,那么测试的意义何在?
我正在编写单元测试,但是当我无法将格式错误的数据传递到任何我正在测试的东西中时,我没有看到这一点,因为我主要使用的是 ENUM!
除非我错过了一些绝对疯狂的东西。我是否在浪费时间回到旧代码来集成单元测试?
当您当前或将来要使用现有代码时,为现有代码编写单元测试很有帮助。这些测试可帮助您确保不会引入任何新错误或不情愿地改变某些行为。
此外,为现有代码编写测试有助于确定可能未知或复杂实现的实际功能。
在极少数情况下,开发人员再也不会接触到无错误软件,添加单元测试可能对您没有太大帮助。但在任何其他情况下,它都有助于记录行为并为未来建立安全网。
哦,既然您提到它:使用enums
不会保护您免于在 C# 中传递无效参数。
不,为现有代码编写测试不会浪费时间。如果您以任何方式维护代码,最好进行单元测试。
你的主要挑战将是工作的范围——为大量代码编写单元测试并不容易,当然也不好玩。我强烈建议您采用迭代方法。在第一轮中,关注提供良好类覆盖率的单元测试可能是一个好主意,这是一个基本指标,也是一个很好的起点。
在达到您认为有意义的类覆盖率水平之后,您可以将注意力扩展到代码覆盖率之外的其他领域。
使用像 NCover 这样的覆盖工具将真正有助于在这里提供一些指标。