什么是TDD的好git工作流?

前端之家收集整理的这篇文章主要介绍了什么是TDD的好git工作流?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我很喜欢 Gitflow branching model
http://nvie.com/img/git-model@2x.png

但是我不知道在哪里放置TDD周期 – 应该只要使用一个特征分支,并且每次写入或者通过测试(加上重构之后),都​​会提交它。创建子分支并将“已完成”单元合并到要素分支中?我应该提交每个失败的测试,还是在通过之后?

这是我目前所做的,在功能部门:

写一个测试,提交
>测试可能由于不存在的接口而导致错误,修复这个修改提交
>使(现在只有失败)测试通过,修改提交
>重构,新提交
> goto 1

@H_502_11@
我不确定这是否具有代表性,但只是说一个开发者,我使用git-flow,这里(大概)我的工作流程是一个新功能

>创建一个特征分支
>写入失败的高级验收测试(黄瓜)失败与一个@wip(工作进行中)标签,所以它现在被遗漏在测试套件之外,并提交到新的分支
(有时)写rspec请求测试用于边缘情况的集成测试,并将其提交到特征分支
>为特征的各个组件编写下级测试(rspec / jasmine),并为每个粗略定义的“单位”写入下级测试(rspec / jasmine),提交到特征分支
>当功能完成后,通过验收测试,取出@wip标签,确保它通过并提交到功能分支
>使用git merge(而不是git flow finish)将特征分支合并到开发分支中。这使得功能分支在那里,所以我可以稍后更新功能,如果需要的话。
>一旦分支合并开发,travis-ci将运行完整的测试套件,如果有任何问题,我会收到一封电子邮件。 (我只包括我的.travis.yml文件中的开发和主分支。)

我应该说,这是我的“理想”工作流程 – 在实际实践中,我打破了这些规则:在编写测试之前提交未经测试的更改,在实际完成高级验收测试之前开始部分功能的开发,我基本上是唯一承诺这个项目的人,所以我有自由去做;如果你在一个更大的团队工作,我想你必须更严格地坚持你所拥有的任何工作流程。

无论如何,我该怎么做我也很乐意听别人的话,所以我提出了这个问题。

更新:

在写这个之后,我意识到有一种我偏离上述流程的感觉,那就是当我添加功能”时,这并不是严格地说正常的面向用户的类型(即不是用户意识到的东西)的)。例如,在开发应用程序的早期,我们决定我们想使用backbone.js来构建我们的js代码 – 所以我为它创建了一个功能部件,并且添加了@javascript标签到现有的黄瓜功能。一旦分支大致能够(使用backbone.js),原始应用程序正在使用HTML视图,我将它合并回来。

我也打算使用require.js,在这种情况下,我也会创建一个功能部门来完成这个操作,一旦完成它的合并就可以了。不会有任何高级别的集成测试 – 只要现有测试通过,这一切都很好。

猜你在找的设计模式相关文章