I think it cuts both ways. On one hand, yes, unit tests are extra code which requires extra maintenance, and will slow you down a bit. On the other hand, if requirements start evolving, having unit tests in place will be a life saver in making sure what you are changing still works.
Unless you have unit tests with high coverage, the cost of change will grow exponentially as the projects moves forward. So basically, the more change you anticipate the MORE you will actually need your unit tests.
Secondly, good unit tests depend on very few and small feature pieces in your production code. When this is true, only a few tests will be impacted when a feature changes. Basically, each test tests just one thing and small piece of production code. The key to writing unit tests that follow this principle is to decouple your code and test in isolation.
Thirdly, you need to get a better understanding of the concept of DONE and why its definition is so important in terms of sustainable development. Basically, you can't go fast over time in a sustainable fashion if your team compromizes the concept of DONE in the short term.
Considering 10+ weeks worth of code with no test coverage makes me cringe. When will you have time to manually test all that code? And under evolving requirements, you will use a lot more time tracking down impacts the changes will have throughout your code base.
I cannot advice strongly enough to use unit testing. Even when doing DDD, let unit tests drive implementation. Coupled with good patterns like DI/IoC and SRP, you should find both your code base and tests to be more resilient to change, and thus save you a lot of time throughout those sprints.
发布评论
评论（3）
我认为这是双向的。一方面，是的，单元测试是额外的代码，需要额外的维护，并且会降低你的速度。另一方面，如果需求开始发展，进行单元测试将成为确保您正在更改的内容仍然有效的救星。
I think it cuts both ways. On one hand, yes, unit tests are extra code which requires extra maintenance, and will slow you down a bit. On the other hand, if requirements start evolving, having unit tests in place will be a life saver in making sure what you are changing still works.
除非您有高覆盖率的单元测试，否则随着项目的推进，变更成本将呈指数级增长。所以基本上，您预期的变化越多，您实际需要的单元测试就越多。
其次，良好的单元测试取决于生产代码中很少且很小的功能部分。如果这是真的，当功能发生变化时，只有少数测试会受到影响。基本上，每个测试只测试一件事情和一小段生产代码。编写遵循此原则的单元测试的关键是将代码解耦并隔离测试。
第三，您需要更好地理解“完成”的概念以及为什么它的定义对于可持续发展如此重要。基本上，如果您的团队在短期内妥协了“完成”的概念，那么您就无法以可持续的方式快速前进。
Unless you have unit tests with high coverage, the cost of change will grow exponentially as the projects moves forward. So basically, the more change you anticipate the MORE you will actually need your unit tests.
Secondly, good unit tests depend on very few and small feature pieces in your production code. When this is true, only a few tests will be impacted when a feature changes. Basically, each test tests just one thing and small piece of production code. The key to writing unit tests that follow this principle is to decouple your code and test in isolation.
Thirdly, you need to get a better understanding of the concept of DONE and why its definition is so important in terms of sustainable development. Basically, you can't go fast over time in a sustainable fashion if your team compromizes the concept of DONE in the short term.
考虑到 10 周以上的代码却没有测试覆盖率，让我感到畏缩。您什么时候有时间手动测试所有这些代码？在不断变化的需求下，您将花费更多的时间来跟踪更改对整个代码库产生的影响。
我无法强烈建议使用单元测试。即使在进行 DDD 时，也要让单元测试驱动实现。再加上 DI/IoC 和 SRP 等良好模式，您应该会发现您的代码库和测试对更改更具弹性，从而在整个冲刺中节省大量时间。
Considering 10+ weeks worth of code with no test coverage makes me cringe. When will you have time to manually test all that code? And under evolving requirements, you will use a lot more time tracking down impacts the changes will have throughout your code base.
I cannot advice strongly enough to use unit testing. Even when doing DDD, let unit tests drive implementation. Coupled with good patterns like DI/IoC and SRP, you should find both your code base and tests to be more resilient to change, and thus save you a lot of time throughout those sprints.