单元测试能否成功添加到现有的生产项目中?如果是这样，如何以及是否值得? [英] Can unit testing be successfully added into an existing production project? If so, how and is it worth it?

问题描述

我强烈考虑将单元测试添加到生产中的现有项目中.它是在 18 个月前开始的，我还没有真正看到 TDD (面部手掌) 的任何好处，所以现在它是一个相当大的解决方案，有许多项目，我还没有最模糊的想法是从哪里开始添加单元测试.让我想到这一点的是，有时一个旧的错误似乎重新出现，或者一个错误被检查为已修复而真的被修复.单元测试将减少或防止这些问题的发生.

I'm strongly considering adding unit testing to an existing project that is in production. It was started 18 months ago before I could really see any benefit of TDD (face palm), so now it's a rather large solution with a number of projects and I haven't the foggiest idea where to start in adding unit tests. What's making me consider this is that occasionally an old bug seems to resurface, or a bug is checked in as fixed without really being fixed. Unit testing would reduce or prevents these issues occuring.

通过阅读类似 关于 SO 的问题，我已经看到了一些建议，例如从错误跟踪器开始并为每个错误编写测试用例以防止回归.但是，我担心我最终会错过大局，并最终错过如果我从一开始就使用 TDD 就会包含的基本测试.

By reading similar questions on SO, I've seen recommendations such as starting at the bug tracker and writing a test case for each bug to prevent regression. However, I'm concerned that I'll end up missing the big picture and end up missing fundamental tests that would have been included if I'd used TDD from the get go.

为了确保现有解决方案经过正确单元测试，而不仅仅是陷入困境，是否应该遵守任何流程/步骤?我怎样才能确保测试的质量很好，而不只是一个案例任何测试都比没有测试好.

Are there any process/steps that should be adhered to in order to ensure that an existing solutions is properly unit tested and not just bodged in? How can I ensure that the tests are of a good quality and aren't just a case of any test is better than no tests.

所以我想我还要问的是；

So I guess what I'm also asking is;

• 是否值得为此付出努力?正在生产的现有解决方案?
• 忽略测试会更好吗对于这个项目并将其添加到未来可能重写?
• 什么会更有益；开支几周添加测试或几个几周添加功能?

(显然第三点的答案完全取决于您是在与管理层交谈还是与开发人员交谈)

(Obviously the answer to the third point is entirely dependant on whether you're speaking to management or a developer)

增加悬赏以尝试吸引更广泛的答案，这不仅证实了我现有的怀疑，即这是一件好事，而且还有一些很好的理由反对.

Adding a bounty to try and attract a broader range of answers that not only confirm my existing suspicion that it is a good thing to do, but also some good reasons against.

我的目标是稍后写出这个问题的利弊，以尝试向管理层表明，花时间将产品的未来开发转移到 TDD 上是值得的.我想在不带偏见的情况下应对这一挑战并发展我的推理.

I'm aiming to write this question up later with pros and cons to try and show management that it's worth spending the man hours on moving the future development of the product to TDD. I want to approach this challenge and develop my reasoning without my own biased point of view.

推荐答案

我已经将单元测试引入了以前没有单元测试的代码库.我参与的最后一个大项目，当我到达团队时，产品已经投入生产，零单元测试.当我离开时 - 2 年后 - 我们有 4500 多个测试，在具有 230 000 + 生产 LOC(实时财务 Win-Forms 应用程序)的代码库中产生了大约 33% 的代码覆盖率.这听起来可能很低，但结果是代码质量和缺陷率的显着提高 - 以及士气和盈利能力的提高.

I've introduced unit tests to code bases that did not have it previously. The last big project I was involved with where I did this the product was already in production with zero unit tests when I arrived to the team. When I left - 2 years later - we had 4500+ or so tests yielding about 33 % code coverage in a code base with 230 000 + production LOC (real time financial Win-Forms application). That may sound low, but the result was a significant improvement in code quality and defect rate - plus improved morale and profitability.

当您得到相关各方的准确理解和承诺时，就可以做到这一点.

It can be done when you have both an accurate understanding and commitment from the parties involved.

首先，重要的是要了解单元测试本身就是一项技能.按照传统"标准，您可以成为一名非常高效的程序员，但仍然难以以可扩展到更大项目的方式编写单元测试.

First of all, it is important to understand that unit testing is a skill in itself. You can be a very productive programmer by "conventional" standards and still struggle to write unit tests in a way that scales in a larger project.

此外，特别是针对您的情况，将单元测试添加到没有测试的现有代码库本身也是一项专业技能.除非您或您团队中的某个人在将单元测试引入现有代码库方面有成功的经验，否则我会说阅读 Feather 的书 是必需的(非可选或强烈推荐).

Also, and specifically for your situation, adding unit tests to an existing code base that has no tests is also a specialized skill in itself. Unless you or somebody in your team has successful experience with introducing unit tests to an existing code base, I would say reading Feather's book is a requirement (not optional or strongly recommended).

向代码单元测试过渡是对人员和技能的投资，就像对代码库质量的投资一样.理解这一点对于心态和管理期望非常重要.

Making the transition to unit testing your code is an investment in people and skills just as much as in the quality of the code base. Understanding this is very important in terms of mindset and managing expectations.

现在，对于您的意见和问题:

Now, for your comments and questions:

但是，我担心我最终会错过大局，并最终错过如果我从一开始就使用 TDD 就会包含的基本测试.

However, I'm concerned that I'll end up missing the big picture and end up missing fundamental tests that would have been included if I'd used TDD from the get go.

简短回答:是的，您会错过测试，是的，它们最初看起来可能不像在绿地情况下那样.

Short answer: Yes, you will miss tests and yes they might not initially look like what they would have in a green field situation.

更深层次的答案是:没关系.你从没有测试开始.开始添加测试，并随时进行重构.随着技能水平的提高，开始提高添加到项目中的所有新编写代码的标准.不断改进等等...

Deeper level answer is this: It does not matter. You start with no tests. Start adding tests, and refactor as you go. As skill levels get better, start raising the bar for all newly written code added to your project. Keep improving etc...

现在，读到这里的字里行间，我的印象是，这来自完美是不采取行动的借口"的心态.更好的心态是专注于自信心.因此，由于您可能还不知道如何去做，您将在进行时弄清楚如何填写并填写空白.因此，无需担心.

Now, reading in between the lines here I get the impression that this is coming from the mindset of "perfection as an excuse for not taking action". A better mindset is to focus on self trust. So as you may not know how to do it yet, you will figure out how to as you go and fill in the blanks. Therefore, there is no reason to worry.

再说一次，它是一项技能.您不能以线性方式在一个过程"或逐步"食谱方法中从零测试到 TDD 完美.这将是一个过程.您的期望必须是逐步和渐进的进步和改进.没有灵丹妙药.

Again, its a skill. You can not go from zero tests to TDD-perfection in one "process" or "step by step" cook book approach in a linear fashion. It will be a process. Your expectations must be to make gradual and incremental progress and improvement. There is no magic pill.

好消息是，随着数月(甚至数年)的过去，您的代码将逐渐开始成为正确"的、经过充分分解和经过充分测试的代码.

The good news is that as the months (and even years) pass, your code will gradually start to become "proper" well factored and well tested code.

作为旁注.您会发现在旧代码库中引入单元测试的主要障碍是缺乏凝聚力和过度依赖.因此，您可能会发现，最重要的技能将成为如何打破现有的依赖关系和解耦代码，而不是自己编写实际的单元测试.

As a side note. You will find that the primary obstacle to introducing unit tests in an old code base is lack of cohesion and excessive dependencies. You will therefore probably find that the most important skill will become how to break existing dependencies and decoupling code, rather than writing the actual unit tests themselves.

是否有任何应该遵守的流程/步骤，以确保现有的解决方案经过适当的单元测试，而不是一头雾水?

Are there any process/steps that should be adhered to in order to ensure that an existing solutions is properly unit tested and not just bodged in?

除非您已经拥有它，否则请设置构建服务器并设置在每次签入时运行的持续集成构建，包括具有代码覆盖率的所有单元测试.

Unless you already have it, set up a build server and set up a continuous integration build that runs on every checkin including all unit tests with code coverage.

培训您的员工.

在从客户的角度取得进展的同时开始添加测试(见下文).

Start somewhere and start adding tests while you make progress from the customer's perspective (see below).

使用代码覆盖率作为您的生产代码库中有多少正在测试的指导参考.

Use code coverage as a guiding reference of how much of your production code base is under test.

构建时间应该总是很快.如果您的构建时间很慢，那么您的单元测试技能就落后了.找到缓慢的测试并改进它们(分离生产代码和测试).写得好，您应该能够轻松进行数千个单元测试，并且仍然可以在 10 分钟内完成构建(~1-几毫秒/测试是一个很好但非常粗略的指南，一些例外情况可能适用，例如使用反射等的代码).

Build time should always be FAST. If your build time is slow, your unit testing skills are lagging. Find the slow tests and improve them (decouple production code and test in isolation). Well written, you should easilly be able to have several thousands of unit tests and still complete a build in under 10 minutes (~1-few ms / test is a good but very rough guideline, some few exceptions may apply like code using reflection etc).

检查和适应.

我怎样才能确保测试的质量很好，而不是任何测试都比没有测试好.

How can I ensure that the tests are of a good quality and aren't just a case of any test is better than no tests.

你自己的判断必须是你现实的主要来源.没有任何指标可以取代技能.

Your own judgement must be your primary source of reality. There is no metric that can replace skill.

如果您没有这种经验或判断力，请考虑与有经验的人签约.

If you don't have that experience or judgement, consider contracting someone who does.

两个粗略的次要指标是总代码覆盖率和构建速度.

Two rough secondary indicators are total code coverage and build speed.

为生产中的现有解决方案付出努力是否值得?

Is it worth the effort for an existing solution that's in production?

是的.在定制系统或解决方案上花费的大部分资金都是在投入生产后花费的.对质量、人员和技能的投资永远不应该过时.

Yes. The vast majority of the money spent on a custom built system or solution is spent after it is put in production. And investing in quality, people and skills should never be out of style.

忽略此项目的测试并在将来可能的重写中添加它会更好吗?

Would it better to ignore the testing for this project and add it in a possible future re-write?

您不仅要考虑对人员和技能的投资，而且最重要的是总拥有成本和系统的预期使用寿命.

You would have to take into consideration, not only the investment in people and skills, but most importantly the total cost of ownership and the expected life time of the system.

在大多数情况下，我个人的回答是当然可以"，因为我知道它要好得多，但我承认可能有例外.

My personal answer would be "yes of course" in the majority of cases because I know its just so much better, but I recognize that there might be exceptions.

什么会更有益；花几周时间添加测试还是花几周时间添加功能?

What will be more benefical; spending a few weeks adding tests or a few weeks adding functionality?

都没有.您的方法应该是在您在功能方面取得进展的同时将测试添加到您的代码库中.

Neither. Your approach should be to add tests to your code base WHILE you are making progress in terms of functionality.

同样，这是对人员、技能和代码库质量的投资，因此需要时间.团队成员需要学习如何打破依赖关系、编写单元测试、学习新习惯、提高纪律和质量意识、如何更好地设计软件等.重要的是要了解，当您开始添加测试时，您的团队成员可能不会这些技能还没有达到使该方法取得成功所需的水平，因此停止进度以花所有时间添加大量测试是行不通的.

Again, it is an investment in people, skills AND the quality of the code base and as such it will require time. Team members need to learn how to break dependencies, write unit tests, learn new habbits, improve discipline and quality awareness, how to better design software, etc. It is important to understand that when you start adding tests your team members likely don't have these skills yet at the level they need to be for that approach to be successful, so stopping progress to spend all time to add a lot of tests simply won't work.

此外，将单元测试添加到任何规模可观的项目的现有代码库中都是一项艰巨的任务，需要承诺和坚持.你不能改变一些基本的东西，期望在途中学到很多东西，并要求你的赞助商不要通过停止商业价值的流动来期望任何投资回报率.那不会飞，坦率地说它不应该飞.

Also, adding unit tests to an existing code base of any sizeable project size is a LARGE undertaking which requires commitment and persistance. You can't change something fundamental, expect a lot of learning on the way and ask your sponsor to not expect any ROI by halting the flow of business value. That won't fly, and frankly it shouldn't.

第三，您希望在您的团队中灌输合理的业务重点价值观.质量永远不会以牺牲客户为代价，没有质量就无法快速前进.此外，客户生活在一个不断变化的世界中，你的工作是让他更容易适应.客户调整需要质量和业务价值流.

Thirdly, you want to instill sound business focus values in your team. Quality never comes at the expense of the customer and you can't go fast without quality. Also, the customer is living in a changing world, and your job is to make it easier for him to adapt. Customer alignment requires both quality and the flow of business value.

您正在做的是偿还技术债务.您在这样做的同时仍然为客户不断变化的需求提供服务.随着债务逐渐偿还，情况有所改善，更容易更好地为客户服务并提供更多价值.等等.这种积极的势头是您应该追求的目标，因为它强调了可持续发展的原则，并将保持和提高道德水平 - 无论是对您的开发团队、您的客户还是您的利益相关者.

What you are doing is paying off technical debt. And you are doing so while still serving your customers ever changing needs. Gradually as debt is paid off, the situation improves, and it is easier to serve the customer better and deliver more value. Etc. This positive momentum is what you should aim for because it underlines the principles of sustainable pace and will maintain and improve moral - both for your development team, your customer and your stakeholders.

希望有帮助

这篇关于单元测试能否成功添加到现有的生产项目中?如果是这样，如何以及是否值得?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！