java一年工作经验编写_如何编写仍将在一年内使用的测试

java一年工作经验编写

Have you ever worked on a project that had unit or integration tests, only to be told “yeah, don’t stress about the tests — we know that a bunch of them are failing.” At some point along the way, keeping the tests up to date with changes that were made to the codebase just became all too hard, and that investment that was made in writing tests is now well and truly in the ‘written off’ column.

您是否曾经在一个进行过单元测试或集成测试的项目中工作过，却被告知“是的，不要强调测试-我们知道很多测试都失败了。” 在此过程中的某个时刻，要使测试与对代码库所做的更改保持最新是非常困难的，并且在“注销”列中确实可以准确地进行编写测试的投资。

What are the key predictors of this scenario, and how can you stop this happening on your projects?

这种情况的主要预测因素是什么？如何在项目中阻止这种情况发生？

测试不可见 (The tests were invisible)

Don’t rely on developers to run the tests. Sometimes we’re in a rush to ship a bugfix or feature, or just distracted by other priorities. Of course, developers who are used to working in a test driven manner will first ask ‘how do I run the tests?’ before they write their code, because they crave early feedback on their implementation’s correctness. But still — you need to make the tests run automatically. This is why you need to routinely use a continuous integration tool such as Travis, Jenkins or CircleCI. Make CI as pain-free and automatic a part of your workflow as possible — you should get it ‘for free’ on new modules and projects. Consider including it in your template or scaffolder for your new modules/projects and try to automate any initial set up to get CI running the tests and any build steps or linting.

不要依赖开发人员来运行测试。 有时我们急于发布错误修正或功能，或者只是因为其他优先事项而分心。 当然，习惯以测试驱动方式工作的开发人员首先会问：“我如何运行测试？” 在他们编写代码之前，是因为他们渴望对实现的正确性进行早期反馈。 但是，仍然需要-使测试自动运行。 这就是为什么您需要定期使用Travis ， Jenkins或CircleCI之类的持续集成工具的原因。 使CI尽可能轻松自如，并使其成为工作流程的一部分，并且应该在新模块和项目上“免费”获得它。 考虑将其包含在新模块/项目的模板或脚手架中，并尝试自动进行任何初始设置，以使CI运行测试以及任何构建步骤或操作。

测试实际上是太好 (The tests were actually too good)

You might be wondering how this could be a problem. But it’s actually vital that adding a new test for a new use case or an edge case that has come to light is cheap enough. So too, maintaining an existing test to keep the test consistent with changed requirements needs to be a reasonably straightforward task. To combat this, go for breadth before you go for depth. In my experience, the developer who has a set of nice simple tests that covers the code base well (but where the tests are actually maintainable and used) is in a much better position than the developer who has to fight too hard to keep the tests maintained because the tests are so detailed and so high fidelity that there are many many moving parts and issues to reason about. I’m not saying don’t go for high fidelity and realism, and even comprehensiveness… I’m just saying go for breadth first, and consider the ongoing cost of any testing code you write. What we want to avoid is the scenario where the cost of keeping the tests maintained starts to outstrip our perceived value in having them stay up to date.

您可能想知道这怎么可能是个问题。 但是，至关重要的是，为新的用例或已发现的边缘用例添加新的测试足够便宜。 因此，维护现有测试以使测试与更改后的需求保持一致也需要是一个相当简单的任务。 为了解决这个问题，在深入之前要先广度。 以我的经验，开发人员拥有一组很好的简单测试，可以很好地覆盖代码库(但是实际上可以维护和使用测试)，而开发人员的状况要好得多，因为开发人员不得不为保持测试而拼搏之所以要维护，是因为测试是如此详尽，如此高保真，以至于有很多运动部件和问题需要考虑。 我并不是说不要追求高保真度和逼真度，甚至不要追求全面性……我只是说要广度使用，并考虑您编写的任何测试代码的持续成本。 我们要避免的情况是，保持测试保持最新状态的成本开始超过我们认为的价值。

测试太差了 (The tests were too bad)

Care about the quality of your code in your tests as much as you do your ‘real’ code. Don’t exclude them from linting. When you’re doing a code review, spend the same care and time on making sure the tests are maintainable and readable as you do on the rest of the codebase. Use a code coverage tool to make sure you’re not leaving too many gaping holes (this improves the value of the test suite, by ensuring you can refactor you code safely).

像对待“真实”代码一样，在乎测试中代码的质量。 不要将它们排除在绒毛之外。 在进行代码审查时，与在其余代码库上所做的一样，要花费相同的精力和时间来确保测试可维护和可读。 使用代码覆盖率工具来确保您不会留下太多空白(通过确保可以安全地重构代码来提高测试套件的价值)。

测试花了这么长的时间才能运行！ (The tests just took so darn long to run!)

I don’t know about you, bu I start to get antsy if a test suite it taking more than say 60 seconds to run. I tend to set the test suit to run on every code change using some kind of --watch flag or a filesytem watcher. Test suites that take tens of minutes to run will definitely not be used by a developer as they work — they’ll probably leave them for CI. And the later you defer feedback, the less valuable it is. If tests take really really long to run, some developers will be tempted to not even wait for CI to finish before they deploy. Tests that take tens of minutes to run had better fulfil the following conditions:

我不了解您，但是如果测试套件的运行时间超过60秒，我就会开始感到恼火。 我倾向于使用某种--watch标志或--watch watcher将测试服设置为在每次代码更改时运行。 运行数十分钟的测试套件肯定不会被开发人员使用，因为它们可能会留给CI使用。 而且，延迟反馈的时间越晚，其价值就越低。 如果测试真的需要很长时间才能运行，那么一些开发人员会被诱惑甚至在部署CI前不等待CI完成。 运行数十分钟的测试最好满足以下条件：

1. they necessarily test a laborious or high fidelity process or procedure (for example, UI tests)
   他们必须测试费力或高保真度的过程或程序(例如，UI测试)
2. they provide the commensurate level of risk mitigation that justifies their cost (both in terms of maintenance and impost on workflow to wait for them).
   他们提供了相称水平的降低风险的方法，可以证明其成本合理(在维护方面以及等待他们的工作量方面)。

Tip: sometimes you can speed tests up a lot just with some judicious stubbing. That’s a tradeoff in itself, but it’s worth considering.

提示：有时，您可以通过一些明智的操作来加快测试速度。 这本身就是一个权衡，但值得考虑。

I hope you’re found this article helpful and thought provoking. Do let me know your experiences, reactions and thoughts in the comments!

希望本文对您有所帮助，并能激发您的思考。 请在评论中让我知道您的经历，React和想法！

翻译自: https://medium.com/@timlesallen/how-to-write-tests-that-will-still-be-used-in-one-year-f208842d6d50

java一年工作经验编写