Test-Driven-Development (TDD) does not necessarily mean you are using an agile approach. Surely, it is a best practice that many of us who do agile use, but TDD can also be used in a Waterfall process, replacing/supplementing the specification.
Continous-Integration on its own means having the code your team produces integrated on an at least daily basis. This does not only force every member of the team having to merge/checkin continously, but also assures you actually can do a release of every build.The unified build process forces you to overcome the "works on my machine syndrom". Because you could do a release everyday this supports an agile process, even though it is not absolutely necessary in the strict sense.
Using tests and integrating them into the build process is a way to enrich your buildprocess with automated Quality Assurance and deepen the level on which integration (integrity) is actually tested.
As long as you are developing in small iterations, focus on getting a working product rather than on getting extensive documentation, and the customer is continuosly involved in the project, it is agile development. Unit testing, TDD and integration testing are of course good and very advisable practices, but they do not decide whether your project is agile or not.
In the absence of Automated tests, CI only verifies that the code under source control is maintained in a compilable state between revisions and that the single-step build works properly. While this is useful, it isn't as useful as the automatic verification that the correctness of the code has been maintained between revisions.
With that said, I'd rather have some verification of code between check-ins than none. I'd rather have partial code coverage or an incomplete set of functional tests than nothing. Or worse.
发布评论
评论（3）
我认为你在这里混淆了事情。
测试驱动开发（TDD）并不一定意味着您正在使用敏捷方法。当然，这是我们许多敏捷开发者使用的最佳实践，但 TDD 也可以用在瀑布流程中，替换/补充规范。
持续集成本身意味着至少每天集成您的团队生成的代码。这不仅迫使团队的每个成员必须不断地合并/签入，而且还确保您实际上可以发布每个构建。统一的构建过程迫使您克服“在我的机器上运行综合症”。因为您可以每天进行发布，所以这支持敏捷流程，尽管从严格意义上来说这并不是绝对必要的。
使用测试并将其集成到构建过程中是一种通过自动化质量保证来丰富构建过程并加深实际测试集成（完整性）的级别的方法。
I think you are mixing up things here.
Test-Driven-Development (TDD) does not necessarily mean you are using an agile approach. Surely, it is a best practice that many of us who do agile use, but TDD can also be used in a Waterfall process, replacing/supplementing the specification.
Continous-Integration on its own means having the code your team produces integrated on an at least daily basis. This does not only force every member of the team having to merge/checkin continously, but also assures you actually can do a release of every build.The unified build process forces you to overcome the "works on my machine syndrom". Because you could do a release everyday this supports an agile process, even though it is not absolutely necessary in the strict sense.
Using tests and integrating them into the build process is a way to enrich your buildprocess with automated Quality Assurance and deepen the level on which integration (integrity) is actually tested.
只要您在小迭代中进行开发，专注于获得工作产品而不是获得大量文档，并且客户持续参与项目，这就是敏捷开发。单元测试、TDD 和集成测试当然是很好且非常可取的实践，但它们并不能决定您的项目是否敏捷。
As long as you are developing in small iterations, focus on getting a working product rather than on getting extensive documentation, and the customer is continuosly involved in the project, it is agile development. Unit testing, TDD and integration testing are of course good and very advisable practices, but they do not decide whether your project is agile or not.
在没有自动化测试的情况下，CI 仅验证源代码控制下的代码在修订之间是否保持可编译状态，以及单步构建是否正常工作。虽然这很有用，但它不如自动验证代码在修订之间保持正确性那么有用。
话虽如此，我宁愿在签入之间进行一些代码验证，也不愿不进行验证。我宁愿有部分代码覆盖率或一组不完整的功能测试，也不愿什么都没有。或者更糟。
In the absence of Automated tests, CI only verifies that the code under source control is maintained in a compilable state between revisions and that the single-step build works properly. While this is useful, it isn't as useful as the automatic verification that the correctness of the code has been maintained between revisions.
With that said, I'd rather have some verification of code between check-ins than none. I'd rather have partial code coverage or an incomplete set of functional tests than nothing. Or worse.