给这篇文章一些背景, we've recently inherited a number of projects built by other developers. 在每种情况下, we've been asked to finish off work that was incomplete, or to take over because of a relationship breakdown. 在这些项目的每一个案例中，都有一个常量:缺乏自动化测试套件.
在商业, 关系破裂通常是因为期望与现实不匹配, often compounded by a lack of communication. 测试, communication and expectation are inextricably linked to one another, 接下来的几分钟, 我会解释为什么.
软件项目中的测试是什么?
传统的测试方式是让一个人(或几个人)带着一系列文档化的测试来到你的产品前. 手动测试套件. 你会一边走一边打勾, 或者用出错的地方标记失败，然后交给开发团队来解决问题.
When the changes were made, you'd do it all over again. 您不能只测试一个失败的测试，因为更改可能会破坏其他地方的某些东西.
All this testing adds time to a project, and time is money. So if you have one company bidding for some work and they don't do formal testing, they appear to come in a lot cheaper than the one that does.
为什么要为软件编写测试?
软件项目中测试的好处是显而易见的:它们减少了中断的风险. Breakage happens both in the moment - whilst developing - and later, when adding or changing functionality in the future. 后者被称为回归，而软件世界充斥着回归. 想想你有多少次参与到一个涉及软件(包括你的网站)的项目中，当你要求改变时，它破坏了一些看似无关的东西. 这就是回归.
它还使升级更容易. 世界上没有一款软件不使用第三方库或框架，至少其中的一部分, and updating those can have an impact on the stability of the system. 拥有一个定义良好的测试套件可以做到这一点 更容易 to upgrade that over time, without risking those breakages hitting your users.
拥有良好的测试覆盖率的价值不一定在项目开始时就变得明显, 至少对非开发者来说不是这样. 如果是你的话, you'll realise the value down the road; weeks, perhaps months after the system has been built and been running. You'll ask for a change, and it will just happen, and won't break something else. 或者如果你发现了一个bug并报告了它, 可以编写一个测试来证明它(bug需要由开发人员复制才能修复)。, 一旦固定, 这种事不能再发生了. Without tests, that bug can rear its head many times into the future.
So the value proposition for having tests is stability, and that means a robust part of your business operating arsenal. 一个不可靠的系统, people lose faith in the system and find workarounds, and those then take additional time and cost more money. 如果他们信任这个系统, 相反，他们的要求为他们自己和整个企业创造了进一步的利益.
Why your software development project should have automated tests
You can probably see why automating your tests is useful; it saves a huge amount of time manually testing each and e非常 line in your test suite. A test suite of several hundred tests can take a matter of a few minutes to run, 你可以在开发过程中运行全部或部分测试以确保这些测试不会触及真正的用户.
So taking the above statement that testing costs time and money, 我们可以看到自动化这些测试现在实际上意味着花费更少的时间 做 测试. 但是仍然需要有人编写测试. 这是开发者时间, 因此，1小时的开发时间可能会增加另外半小时编写测试的时间.
编写自动化测试允许开发人员测试系统的真正深层部分——数据处理的部分——以确保它们坚如磐石. 它还为新的团队成员提供文档，但愿不会这样，为全新的团队提供文档. 与测试的交接很干净, 这意味着新入职的开发者可以在知道自己有工作基础的情况下接手项目. 这意味着几乎没有中断. 另一方面, as we've found with all the projects we've taken on without a test suite, those systems come with their own hidden mysteries. Things that come out of the closet as you start to work on them, and those cost more time and money than writing the tests in the first place.
Writing automated tests also makes for cleaner code. 它们允许重构(重做)代码，使其更干净，更易于维护, and also give clarity of purpose up front, 这意味着开发人员通常会编写更少的代码, 更好的编码. 同样，这是长期可维护性的胜利，所有这些都意味着节省更多的时间和金钱.
What happens if your software project doesn't have an automated test suite?
老实说，你有麻烦了. Without wishing to put too fine a point on the stick I'm prodding you with, 缺乏测试套件会暴露未来的问题，即使它没有显示当前的问题. 我们刚刚接手了一个项目，在几个月的时间里花费了数万英镑, 我们被告知，有一长串似乎无法解决的问题.
So a direct outcome of a lack of tests is a lack of trust, 这意味着业务和开发团队之间的关系出现了灾难性的失败. That could as well have been an in-house team - the outcome is the same.
不仅如此, 任何承担项目的新开发团队都会质疑他们是否愿意承受项目的风险, and whether the risk should be weathered by the client too. It's a commercial decision at the end of the day, 但这是两党都需要做出的决定, 而且不能掉以轻心.
One alternative is a complete rewrite of the application from the ground up. That's not something I would usually recommend, and there are 很多 of 文章 around the web pointing to it being absolutely the wrong decision. 然而, if you're dealing with a brand new service, 从一开始就是一团糟, sometimes you can make some big changes by rewriting. 然而, 在这种情况下, 这不是对现状的重建, but a build of something completely new - it's still not a rewrite really, 但这是一个全新的产品.
The other is to spend time and money investing in the project properly, 构建测试, documentation and cleaning up bad code or architecture. 如果所有的代码都是坏的? 或许可以参考第一种选择. 在没有测试的情况下构建一个东西仍然是对时间和金钱的巨大浪费.
Earlier in the article, I touched on upgrades. 使用自动化测试套件，您可以通过执行升级并让服务器在您继续工作的同时运行测试来测试系统依赖项的一部分或全部的升级. 当它完成时, 你会知道什么东西坏了, 需要解决的问题, 并且可以形成一个计划，如何做到这一点，并保持应用程序运行它所依赖的所有最新版本.
What VALUE do tests bring to your project, and to your business?
测试您的系统是至关重要的. You can't run a successful long term software project without them. If you have already started without them, make sure you add them in.
如果你还没有开始你的项目, 确保这是你问潜在开发者的首要问题, along with what their average code coverage is. Code coverage is the amount of the code that is covered by tests, which gives a good indication of how well tested it is.
在Initforthe，我们的目标是95% 非常 行业领先. We achieve 85%+ on all our projects and regularly hit 90%+. 我们为用户遇到的每一个bug编写测试，并防止将来出现任何倒退. 其余的测试涵盖了我们编写的绝大部分代码，以确保它始终正常工作, 可以轻松升级, and you'll have minimal complaints or support requests from your users.
我们也要说清楚, 并将其与这篇文章顶部的图片直接联系起来:两架波音737 Max飞机坠毁，346人死于缺乏软件测试的直接结果. 进一步, 这架飞机自2019年3月以来一直停飞，给波音公司及其客户造成了数十亿美元的损失.
所以总结一下, it's less about whether there is value in testing, and more about what can happen if you don't have tests in your software project. 购者自慎.
