我项目中的需求变化太频繁。维护测试用例变得非常不方便。仍然建议使用测试用例吗？或者有什么好的方法来处理这个问题？
问问题
601 次
5 回答
3
如果您必须更改代码，那么我认为维护测试工具比以往任何时候都更重要。测试工具是一种文档形式。
于 2012-07-30T13:11:22.723 回答
3
这是进行单元测试的痛苦的一部分。你应该坚持下去。
- 当需求稳定下来时，您将处于一个更好的位置。
- 没有测试，你会更容易受到攻击——当快速变化发生时，事情很可能会被意外破坏。
- 如果你现在放弃测试，你很可能不会再把它捡回来......
于 2012-07-30T13:13:53.503 回答
0
由于您已将此问题标记为“TDD”，因此请考虑如何通过测试驱动开发来实现更改的需求。在新需求的情况下，您将编写一个失败的测试来证明缺少新功能。在需求更改的情况下，您可能已经有测试显示（通过传递）该功能处于其原始状态。因此，测试驱动您的开发。更改您通过的测试，以便它们现在需要新行为 - 并且失败 - 现在通过实施更改的行为使它们通过。
于 2012-07-30T13:24:33.510 回答
0
您应该借此机会审查您的设计，看看是否有零件经常随着需求的变化而变化。您甚至可以对当前设计进行更改，将部件移动到两个分区中：一个大部分保持不变，一个大部分发生变化。
您可能能够隔离变化的部分，以便在需求发生变化时只需要添加新的代码/类。
于 2012-07-31T19:13:02.237 回答
0
我要对任何试图说服我 100% 测试覆盖率的人说的另一个论点是圣杯。
项目需求不会完全改变（除非这是一个非常小的项目）。毕竟总是有一些假设，断言，物理定律规定的限制:)
我建议检查需求并将它们分成不同的层。与第 2 层相比，第 1 层的需求发生变化的可能性较小。这样您就可以专注于波动较小的部分。最终需求生产者会感到疲倦（被替换，无聊）。
开发人员必须处于较差的状态。快速的需求更改将获得意大利面条代码。测试工具在某种程度上可能是意大利面条，但它确实是他们的救命稻草。保持它与这样的项目组织相适应是非常重要的。
于 2012-07-30T13:19:22.877 回答