什么是TDD的良好git工作流?

什么是TDD的良好git工作流?,git,tdd,workflow,git-flow,Git,Tdd,Workflow,Git Flow,我很喜欢 但我不确定TDD循环应该放在哪里——我是否应该在每次编写或通过测试时(以及重构后)简单地使用特性分支并提交?创建一个子分支并将“完工”单元合并到要素分支中?我应该提交每个失败的测试,还是只有在通过测试后才提交 以下是我目前在功能分支上所做的工作: 编写测试、提交 由于不存在接口,测试可能会产生错误,请修复此问题,并修改提交 使(现在唯一失败的)测试通过,修改提交 重构,新提交 转到1 我不确定这是否具有代表性,但作为一名开发人员,我使用git flow,下面(大致)是我的新功能工作流程

我很喜欢
但我不确定TDD循环应该放在哪里——我是否应该在每次编写或通过测试时(以及重构后)简单地使用特性分支并提交?创建一个子分支并将“完工”单元合并到要素分支中?我应该提交每个失败的测试,还是只有在通过测试后才提交

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

  • 编写测试、提交
  • 由于不存在接口,测试可能会产生错误,请修复此问题,并修改提交
  • 使(现在唯一失败的)测试通过,修改提交
  • 重构,新提交
  • 转到1

  • 我不确定这是否具有代表性,但作为一名开发人员,我使用git flow,下面(大致)是我的新功能工作流程:

    • 创建要素分支
    • 使用
      @wip
      (work-in-progress)标记编写失败的高级验收测试(cucumber),以便将其暂时排除在测试套件之外,并将其提交给新分支
    • (有时)为边缘案例的集成测试编写rspec请求测试,并将其提交给特性分支
    • 为特性的各个组件编写低级测试(rspec/jasmine),并为每个粗略定义的“单元”提交特性分支
    • 当功能足够完成并通过验收测试时,取下
      @wip
      标记,确保它通过并提交到功能分支
    • 使用
      git Merge
      (而不是
      git flow finish
      )将功能分支合并到开发分支中。这就留下了特性分支,以便在以后需要时可以更新特性
    • 一旦分支合并到一起进行开发,travis ci将在其上运行完整的测试套件,如果有任何问题,我会收到一封电子邮件。(我只在我的.travis.yml文件中包括开发和主分支。)
    我应该说,这是我的“理想”工作流程——在实际操作中,我经常违反这些规则:在编写测试之前提交未经测试的更改,在实际充实高级验收测试之前开始处理部分功能,等等。我基本上是唯一一个致力于该项目的人,所以我有这样做的自由;如果你在一个更大的团队中工作,我认为你必须更严格地遵守你的工作流程

    不管怎样,我就是这样做的。我也很想听听其他人的意见,所以我对这个问题投了赞成票

    更新:

    在写了这篇文章之后,我意识到有一种感觉我偏离了上面的流程,那就是当我添加“功能”时,严格来说,这些功能不是正常的面向用户的类型(即,用户不会意识到的东西)。例如,在开发应用程序的早期,我们决定使用backbone.js来构建js代码——因此我为它创建了一个功能分支,并在现有的各种功能中添加了
    @javascript
    标记。当分支大致能够(使用backbone.js)完成原始应用程序在HTML视图中所做的工作时,我将其合并回来


    我还计划切换到使用require.js,在本例中,我还将为此创建一个功能分支,完成后将其合并回来。它不会有任何高级集成测试——只要现有测试通过,一切都很好。

    考虑何时提交的简单方法是:

  • 我可以用一条有意义的提交消息来描述我正在提交的内容吗
  • 我有什么理由想回到这一点或与这一点有所不同
  • 这意味着这取决于人。如果您从未发现自己在某个阶段进行了差异化,可能是因为您修复它的速度足够快,以至于您仍然能够记住您所更改的内容,那么您就不需要进行承诺。但是,除了键入命令所需的时间之外,它也没有什么坏处


    如果您真的觉得某个步骤不足以保证长期提交,那么另一种选择是只执行
    git add
    。这样,
    git diff
    将显示自添加以来发生的更改,而
    git diff--cached
    将显示之前发生的更改。这就是我所做的,因为我希望我的提交是可编译的,并且通过单元测试。这样,很容易返回到已知的良好状态。

    我不相信有一个特定于TDD的提交工作流,我尝试遵守的唯一相关规则是,我尝试不将有中断测试的提交推送到主分支(除非它已经中断)。在我的功能分支上,通常只测试与功能相关的测试,但在执行“合并回主功能”时,所有测试都将被检查。如果我知道提交确实会导致某些特性测试中断,或者是其他原因导致它中断,那么我只会将其指示为wip。从更实际的角度来看,我认为格外小心以避免将提交推到错误的分支会有更多的好处。

    我认为一个好而简单的指导原则是每次“绿色”时提交,或者至少在每个测试周期:

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

    我的工作流程非常相似,但请考虑更好地利用临时区域

  • 编写一个测试,git add
  • 由于不存在接口,测试可能会产生错误,请修复此问题,git add
  • 使(现在唯一失败的)测试通过git commit
  • 重构,git提交修改
  • 转到1

  • 这加强了规则,即在每次提交时,所有测试都通过。在第1-3阶段,我可以随时使用git checkout回滚到最后一个git add。

    @shioyama那么,您是提交新的但失败的测试,还是仅在通过测试后提交?如果你确认我的假设已经是回答你问题的答案,请随时将此作为答案发布:我尽量不做任何违反测试的事情