Anyway, I'm curious to read what the thoughts are on this process? Please keep them brief. Does your team includes units tests in the build. If so, do you follow TDD? Do you always strive to keep your builds with tests as all passing?
Well, we're not always perfectly consisten about it, but in principle: yes, and yes.
Point 1:
IMHO, you really must run your tests in the daily build. Otherwise test failures in places where you didn't expect them will go unnoticed for a while - this defeats the whole purpose of unit testing. It's only useful if test failures are noticed immediately.
Obviously, during development there will be phases where you break tests (e.g. refactoring). But these should be as short as possible (minutes, ideally), and you typically only check in once they pass (just as you only check in once stuff compiles). If you need to do more extensive rework, you need a private branch :-).
Point 2:
As to what happens when tests break: Well, you fix them (you, or whoever broke them). Strict reprimands should be unnecessary in a good team. But that is really a social question...
build should run the tests, always passing, and yes for TDD
also, if you have automated functional testing, that should be run also. With functional testing you may not have all the tests passing, however you should never start failing a test that was passing.
(ie.... you can have a bunch of functional tests that will demonstrate that current stuff being worked on is doing the right thing, but until its completed it won't pass. )
Whether or not you use TDD, don't checkin unless/until it passes its tests. Or if you like/must, you can checkin broken code/tests to a 'private' branch whose testing isn't asserted.
发布评论
评论（3）
好吧，我们并不总是完全一致，但原则上：是的，是的。
第 1 点：
恕我直言，您确实必须在日常构建中运行测试。否则，在您没有预料到的地方的测试失败将在一段时间内被忽视——这违背了单元测试的全部目的。仅当立即发现测试失败时，它才有用。
显然，在开发过程中会有破坏测试的阶段（例如重构）。但这些应该尽可能短（理想情况下是几分钟），并且您通常只在它们通过后才签入（就像您只在东西编译后签入一样）。如果您需要进行更广泛的返工，您需要一个私有分支:-)。
第 2 点：
至于测试失败时会发生什么：好吧，你修复它们（你，或者任何破坏它们的人）。在一个好的团队中，严厉的斥责是不必要的。但这确实是一个社会问题......
Well, we're not always perfectly consisten about it, but in principle: yes, and yes.
Point 1:
IMHO, you really must run your tests in the daily build. Otherwise test failures in places where you didn't expect them will go unnoticed for a while - this defeats the whole purpose of unit testing. It's only useful if test failures are noticed immediately.
Obviously, during development there will be phases where you break tests (e.g. refactoring). But these should be as short as possible (minutes, ideally), and you typically only check in once they pass (just as you only check in once stuff compiles). If you need to do more extensive rework, you need a private branch :-).
Point 2:
As to what happens when tests break: Well, you fix them (you, or whoever broke them). Strict reprimands should be unnecessary in a good team. But that is really a social question...
build 应该运行测试，总是通过，对于 TDD
也是如此，如果您有自动化功能测试，也应该运行。通过功能测试，您可能不会让所有测试都通过，但是您永远不应该开始让正在通过的测试失败。
（即......你可以进行一堆功能测试，以证明当前正在处理的事情正在做正确的事情，但在完成之前它不会通过。）
build should run the tests, always passing, and yes for TDD
also, if you have automated functional testing, that should be run also. With functional testing you may not have all the tests passing, however you should never start failing a test that was passing.
(ie.... you can have a bunch of functional tests that will demonstrate that current stuff being worked on is doing the right thing, but until its completed it won't pass. )
无论您是否使用 TDD，都不要签入，除非/直到它通过测试。或者，如果您喜欢/必须，您可以将损坏的代码/测试签入未断言测试的“私有”分支。
Whether or not you use TDD, don't checkin unless/until it passes its tests. Or if you like/must, you can checkin broken code/tests to a 'private' branch whose testing isn't asserted.