关于测试工程师_关于测试

关于测试工程师

Despite of lots of benefits, tests have two fundamental problems: there is no architecture at all (quality), nobody knows what is the meaning of the quantity.

尽管有很多好处，但是测试仍然存在两个基本问题：根本没有架构(质量)，没有人知道数量的含义。

Tests have a cost. Lets imagine dialog between manager and developer:

测试是有成本的。 让我们想象一下经理和开发人员之间的对话：

— John, how many hours does it take to implement?

约翰，实施需要几个小时？

— Approximately one week: 1,5 day for task and 3,5 days to write tests

—大约一周：任务1.5天，编写测试3.5天

So why people write tests? Let's try to build a mental model: we delivered a component, our beta testers found a bug, we wrote tests scenario. So, next time we try to deliver the same component, we already know about bad scenario and have automation to check it. So far so good. Next, we are trying to predict future bugs by writing lot's of tests and cover bad scenarios. Next, we deliver better components, users are happy. Profit. (Despite of all pros, the solution is not scalable — with every new component we will face a reality).

那么为什么人们编写测试呢？ 让我们尝试建立一个思维模型：我们交付了一个组件，我们的beta测试人员发现了一个错误，我们编写了测试场景。 因此，下一次我们尝试交付相同的组件时，我们已经知道了糟糕的情况，并可以进行自动化检查。 到目前为止，一切都很好。 接下来，我们试图通过编写大量测试并涵盖不良场景来预测未来的错误。 接下来，我们提供更好的组件，用户感到满意。 利润。 (尽管有所有专家，但该解决方案无法扩展-我们将面对每个新组件)。

So tests are useful: it's sort of agreement between a flexible codebase and loyal users (one guys called tests «Double-entry bookkeeping» which who knows accounting can be very true). So every programmer writes tests with good intentions thinking about blackbox component on one side and tests with YES/NO expection on other side. In the same time, every lazy programmer bravely keeps his or her codebase untouchable (design or just function signature) because otherwise all tests needs to be rewritten. Good developer can start from tests and then continue with a function implementation (hello TTD). But sometimes we can find interesting artifacts in our codebase: properties with names like this._threadsCount /* used in tests; do not delete */ or Table.testEnvironment /* sets to true in the tests */ For now what we have it's all ours: business brings money, developers write tests. Let's talk about quantity.

因此，测试非常有用：它是一种灵活的代码库与忠实用户之间的一种协议(一个称为测试“重复入账”的人，他们知道会计很真实)。 因此，每个程序员在编写测试时都会怀着良好的意愿，一方面考虑黑盒组件，另一方面考虑具有“是/否”期望。 同时，每个懒惰的程序员都勇敢地保持他或她的代码库不可触摸(设计或仅仅是函数签名)，因为否则所有测试都需要重写。 好的开发人员可以从测试开始，然后继续执行功能(您好TTD)。 但是有时我们可以在代码库中找到有趣的工件：名称类似于this._threadsCount / *的属性，用于测试； 不要删除* /或在测试中将Table.testEnvironment / *设置为true * /现在，我们拥有的一切就是：业务带来金钱，开发人员编写测试。 让我们谈谈数量。

Lets write one-line function square(x) { return x; } Lets test it for keep covering 100%: expect(square(1)).to.be.eq(1). Responsible programmer can go futher and write basic tests, just because he or she wants to cover common cases and feels safer to make changes in the codebase. Make sense. But let's think a bit, how many tests do you want to write for the function groupBy(list, fn)? i hope at least 16, approximately 4x more then the length of groupBy implementation. OK, thats true for unittest, what about integration tests? With integration tests we have at least two components. Where we have components we have relations. Not to mention the problems with all Fakes in many components system, relations exponentially increase amount of states need to be tested. I hope you knew it before. Despite all that problems integration tests are very useful tool (but very expensive, and shaky, and slow, and i hope you knew it before too). There are much more problems, my dear readers, but you can easily reveal them just start thinking about different approaches how to test systems, and i left it as exercises (really, just try to think about it) For now that's all, see you in the next topic.

让我们编写单行函数square(x){return x; 让我们对其进行测试以确保其覆盖率达到100％：Expect(square(1))。to.be.eq(1)。 负责任的程序员可以继续编写基本测试，只是因为他或她想涵盖一些常见情况，并且对代码库进行更改感到更安全。 合理。 但是让我们考虑一下，您要为函数groupBy(list，fn)编写多少个测试？ 我希望至少16倍于groupBy实现的长度。 好的，对于单元测试是正确的，那么集成测试呢？ 通过集成测试，我们至少有两个组成部分。 我们有组件的地方就有关系。 更不用说在许多组件系统中所有Fakes的问题，关系成倍增加的状态数量需要测试。 我希望你以前知道。 尽管存在所有这些问题，集成测试还是非常有用的工具(但是非常昂贵，不稳定，速度慢，我希望您也早知道这一点)。 亲爱的读者，还有更多的问题，但是您可以轻松地揭示给他们，他们只是开始思考如何测试系统的不同方法，而我把它留给了练习(真的，只是想想看)。在下一个主题中。

翻译自: https://habr.com/en/post/496834/

关于测试工程师