我可以报到考试不及格吗[结业]

我要说的是,你不仅不应该签入新的失败测试,还应该禁用“10个左右的长期失败测试”。当然,最好是修复它们,但是在每晚都有一个失败的构建和每个包含的测试都通过(有些被排除在外)之间-你最好是绿色的。现在的情况是,当你改变了在你现有的测试套件中导致新的失败的东西时,你很可能会错过它。

禁用失败的测试,并为每个测试输入一张票证;这样您就可以得到它。你也会对你的自动化构建系统感觉好多了。

我和一个朋友讨论过这个问题,我们的第一条评论是最近的一个极客:)(附)

更具体地说,所有测试都应该在之前编写(sa,只要它应该是TDD),但是那些检查未实现功能的测试应该在其值前面加上否定。如果它没有实现-它就不应该工作。[如果它有效-测试不好]在实现测试之后,删除 ! 它起作用[或者失败了,但它就是这样做的:)]。

你不应该认为测试是一次写的,而且总是正确的。测试也可能有错误。所以编辑测试应该是正常的。

我想说的是,检查(已知的)失败的测试当然应该只是暂时的,如果有的话。如果构建总是失败,它就失去了它的意义(我们去过那里,但那并不漂亮)。

否则我会说使用你的票证系统作为待办事项列表,而不是构建。

这取决于你如何使用测试。在我的团队中,运行测试是在提交之前执行的操作,目的是检查您(可能)没有破坏任何东西。

当您即将提交时,如果发现失败的测试似乎与您的更改有模糊的可能,但仍然很奇怪,请调查几个小时,然后意识到这不可能是因为您的更改,请执行干净的签出、编译,并发现测试失败确实来自主干。

显然,你不会用同样的方式使用测试,否则你甚至不会问。

如果您使用的是DVCS(例如g it),那么这就不是问题,因为您会将失败的测试提交到本地存储库,使其正常工作,然后将整个测试(测试和修复)推回到团队的主存储库。工作完成了,大家都很高兴。

看起来你做不到,最好的办法是首先确保测试已经被编写并且在沙盒中失败,然后在提交之前修复它。这可能是也可能不是很好的TDD,但这是对其他人工作实践的合理妥协;工作 你的同事在各个方面都比遵循象牙塔原则更重要,因为原则的作者不在隔壁的隔间里

每晚构建的目的是让您确信前一天编写的代码没有破坏任何东西。如果测试经常失败,那么你就没有信心了。

您应该首先修复任何可以修复的失败测试,并删除或注释掉/忽略其他失败的测试。每晚的建筑都应该是绿色的。如果不是,那就有问题了,现在很明显,因为它应该是绿色的。

如果人们想先编写代码,然后再测试,这是可以的(虽然我更喜欢TDD),但只有运行绿色的测试代码才应该签入。

最后,我建议将夜间构建更改为持续集成构建(在每次代码签入时运行),这可能会改变人们关于代码签入的习惯。

我看得出来你有很多问题。

1) 你在写失败的测试。

2) 您往往会忘记具有[忽略]属性的测试。

3) 您的团队正在编写代码之后编写测试。

4) 你在练习TDD。