什么是TDD的良好git工作流程？

Question

我非常喜欢Gitflow分支模型
http://nvie.com/img/git-model@2x.png,
但我不确定在哪里放置TDD周期 - 我应该只使用一个功能分支并在每次写入或提交时提交通过测试(加上重构后)？创建一个子分支并将"已完成"单元合并到功能分支中？我是应该每次都进行失败的测试,还是只有在通过之后？

以下是我目前在功能分支上所做的事情:

1. 写一个测试,提交
2. 由于不存在接口,测试可能会产生错误,修复此问题,修改提交
3. 使(现在只有失败的)测试通过,修改提交
4. 重构,新提交
5. 转到1

Answer 1

我不确定这是否具有代表性,但只是作为一名开发人员发言,我使用git-flow和(大致)我的工作流程来获取新功能:

• 创建功能分支
• 写入失败的高级验收测试(黄瓜)失败并带有@wip(正在进行中)标记,因此暂时将其排除在测试套件之外,并将其提交给新分支
• (有时)为边缘情况的集成测试编写rspec请求测试,并将其提交给功能分支
• 为功能的各个组件编写低级测试(rspec/jasmine),对于每个粗略定义的"单元",提交功能分支
• 当功能完成足以通过验收测试时,取下@wip标签,确保它通过并提交到功能分支
• 使用git merge(而不是git flow finish)将功能分支合并到开发分支中.这将功能分支留在那里,以便我可以在以后需要时更新功能.
• 一旦分支合并到开发中,travis-ci就会运行完整的测试套件,如果有任何问题,我会收到一封电子邮件.(我只在我的.travis.yml文件中包含了开发和主分支.)

我应该说,这是我的"理想"工作流程 - 在实际操作中我违反了这些规则:在编写测试之前提交未经测试的更改,在实际充实高级验收测试之前开始处理部分功能,我基本上是唯一一个承诺这个项目的人,所以我有自由这样做; 如果你在一个更大的团队中工作,我认为你必须更严格地坚持你所拥有的任何工作流程.

无论如何,我就是这样做的.我也热衷于听取其他人的意见,所以我提出了这个问题.

更新:

在写完之后我意识到有一种感觉,我偏离了上面的流程,这就是我在添加"功能"时,这些功能并不严格地说是普通的面向用户的类型(即用户不会意识到的东西)的).例如,在开发应用程序的早期,我们决定使用backbone.js来构造我们的js代码 - 所以我为它创建了一个功能分支,并@javascript为各种现有的黄瓜功能添加了标签.一旦分支大致能够(使用backbone.js)原始应用程序使用HTML视图执行的操作,我就将其合并.

我还计划切换到使用require.js,在这种情况下,我还将创建一个功能分支来执行此操作,并在完成后将其合并回来.它不会有任何高级集成测试 - 只要现有的测试通过,它就是好的.

Answer 2

我认为一个好的和简单的指导方针是在你每次“绿色”时提交，或者至少在每个测试周期：

• 红色 -> 绿色 -> 重构 ->提交
• 或红色 -> 绿色 ->提交-> 重构 ->提交

Answer 3

我的工作流程非常相似，但考虑更好地利用暂存区域。

1. 写一个测试，git add。
2. 由于不存在的接口，测试可能会产生错误，请修复此问题，git add。
3. 使测试通过（现在只是失败），git commit。
4. 重构，git commit 修改。
5. 转到 1。

这强制执行了每次提交时所有测试都通过的纪律。在第 1-3 阶段，我可以随时使用 git checkout 回滚到最后一个 git add。