|
|
6 回复 | 直到 16 年前
|
1
8
我会选择一个测试并将其更改为需要新功能。如果没有任何明显的候选者,也就是说,它确实是新的,我会创建一个。然后我将编写代码以通过该测试。在这一点上,我会运行我的其他测试,并注意到其中一些失败。在这一点上,我将依次重新访问每个测试,或者更正测试以反映新特性(因此它将在没有其他代码更改的情况下通过),或者根据新特性更新测试(这可能需要对测试中的代码进行进一步更改)。 |
|
|
2
4
我将为新特性创建新测试,并更新现有测试以适应您的特性。如果你破坏了一个已经在运行的测试,你应该修复它。 |
|
3
4
包括 编写/更新单元测试;这是测试驱动开发的基础。所以你的第二个选择也是TDD,而不仅仅是第一个。在实践中,我怀疑您会希望您的第三个选项与一些MOD:
|
|
|
4
1
我认为所有的方法都是合理的。你会得到同样的结果。 有些人喜欢更小的步骤,并且更多地按照TDD的原意工作:编写一行测试,编写一行代码来修复它,然后重复。如果是您,请先递增地处理旧的测试,将它们演化(或删除)到新系统中。 如果你不介意咬下更大的一块,那就去修理新东西吧。我发现这更自然,尤其是当结对编程时,你可以更大胆一点。
我支持这样一种观点,即理想情况下,一次更改只会破坏一个测试,因此您可能需要重构测试代码,以便这就是您的行为。某种共享设置方法可能是解决方案。 |
|
5
0
摆脱旧的测试,编写新的测试。您可以在一些地方从旧测试中借用代码,但是您最好按照您试图做的事情进行哲学上的测试,而不是试图改变旧测试的性质。 测试是为了支持你想要完成的事情,不应该对你不利。 |
|
|
6
0
我认为这里有两件事要考虑。我不知道你是只考虑一个还是两个。 第一部分是,由于规范(或预期行为)更改,您已经更改了特性。在这种情况下,我认为正确的做法是删除所有描述不再有效的行为的测试。因为我很懒,我会把它们注释掉或者暂时跳过。然后我将开始编写新的测试(或取消注释/修改旧测试),以开始描述新的行为,直到完成为止。
|
推荐文章