eos测试规格_希望您的测试更有效？ 这样写您的规格。

eos测试规格

by Edd Yerburgh

埃德·耶堡(Edd Yerburgh)

希望您的测试更有效？ 这样写您的规格。 (Want your tests to be more effective? Write your specifications like this.)

Writing test specifications is tricky. If you get it right, your tests are easy to understand and debug. But get it wrong, and your tests will be confuse people more than they’ll help them.

编写测试规范非常棘手。 如果您做对了，您的测试很容易理解和调试。 但是弄错了，您的测试会使人们更加困惑，而不是帮助他们。

In this article, I’ll show you how to write expressive test specifications.

在本文中，我将向您展示如何编写表达性测试规范。

什么是测试规格？ (What are test specifications?)

Test specifications (specs) are the string used to identify tests when they’re run by a test runner.

测试规范(specs)是由测试运行程序运行时用于标识测试的字符串。

Below you can see an example of the output from a failed test. You can see where the specification and assertion error is used to describe how a test failed.

在下面，您可以看到测试失败的输出示例。 您可以看到规范和断言错误用于描述测试失败的位置。

为什么测试规格很重要？ (Why are test specifications important?)

When a test fails, the way you identify it is with the test specification.

如果测试失败，则可以通过测试规范来识别它。

If the specification is well-written, you’ll know straight away why the test failed by using the test specification and the test assertion.

如果规范写得好，您将通过使用测试规范和测试断言直接了解为什么测试失败。

calls showModal when button is clickedError: Expected spy to have been called but it was not.

We can guess that the test failed because showModal wasn’t called when the button was clicked. This debugability is what you should aim for in tests.

我们可以猜测测试失败，因为单击按钮时未调用showModal。 这种可调试性是您在测试中应该追求的目标。

Lets look at some rules to help write spectacular test specifications.

让我们看一些规则，以帮助编写出色的测试规范。

金发姑娘规则 (The Goldilocks rule)

You should follow the Goldilocks rule for test specifications—not too general and not too specific.

您应该遵循Goldilocks规则来确定测试规范，不要太笼统，也不要太具体。

For example, does what I expect is too general. You won’t know why the test failed or what the test was checking.

例如， does what I expect是否太笼统了。 您将不知道为什么测试失败或测试正在检查什么。

At the same time, you need to avoid being too specific. Instead of usingadds cache-control none header and vary Lang header, use a less narrow specification, like adds correct headers .

同时，您需要避免过于具体。 与其使用adds cache-control none header and vary Lang header ，不如使用狭窄的规范，例如adds correct headers 。

A failing test has two parts. The test specification, and the error message.

测试失败包括两个部分。 测试规范和错误消息。

adds correct headers Error: Expected something to equal none

Your test name should tell us what is happening. But it doesn't need to give us every detail. The assertion error should include a value that compliments the test specification.

您的测试名称应告诉我们正在发生的事情。 但这并不需要给我们每一个细节。 断言错误应包含一个符合测试规范的值。

保持简短 (Keep them short)

Specifications should be short.

规格应简短。

My rule of thumb is that they shouldn’t be longer than 150 characters.

我的经验法则是，它们的长度不能超过150个字符。

If your tests are more than 150 characters, there’s a chance that your units are too complex. Either rewrite the spec to be shorter, or break out the functionality of your units into smaller chunks.

如果您的测试超过150个字符，则可能是您的单元太复杂了。 重写规范以使其更短，或者将单元的功能分解为较小的块。

用现在时写 (Write in the present tense)

Your test specs should be in the present tense.

您的测试规格应采用现在时。

For example, calls toggleModal when button is clicked , not will call toggleModal when button is clicked .

例如， calls toggleModal when button is clicked不will call toggleModal when button is clicked 。

Specifications are statements of how your unit behaves: returns sum of input .

规格说明您的设备如何运行： returns sum of input 。

Writing in the present tense makes your specifications shorter and easier to read.

以现在时书写使您的规范更短，更容易阅读。

专注于输出和输入 (Focus on output and input)

Tests should trigger an input and expect an output.

测试应触发输入并期望输出。

Your specifications should follow this pattern—output when input. For example calls toggleModal when button is clicked , or returns true when called with string .

您的规范应遵循此模式- 输入时输出 。 例如， calls toggleModal when button is clicked ，或者returns true when called with string calls toggleModal when button is clicked returns true when called with string 。

Keeping to this standard ensures your tests focus on output and input.

遵守此标准可确保您的测试集中在输出和输入上。

简明扼要 (Be concise)

You don’t have much space in test specs, so stay away from unnecessary words.

您在测试规范中没有太多空间，因此请远离不必要的文字。

For example, don’t add filler words like should, or will.

例如，请勿添加应有或将会的填充词。

should call showmodal when clicked ❌

should call showmodal when clicked showmodal

will call show modal when clicked ❌

will call show modal when clicked call will call show modal when clicked

calls show modal when clicked ✅

calls show modal when clicked

不要使用嵌套的描述块 (Don’t use nested describe blocks)

A lot of Javascript testing libraries include a feature called describe blocks.

许多Javascript测试库都包含一个称为describe块的功能。

describe blocks define sections in your tests.

describe块定义测试中的部分。

A describe block like the one below:

描述块，如下所示：

describe('sum', () => {  test('returns sum of input', () => {    expect(sum(1,2)).toBe(3)  })})

It creates the following console output:

它创建以下控制台输出：

You should use describe blocks to define a test suite in a file.

您应该使用describe块在文件中定义测试套件。

Some developers nest describe blocks inside each other to organize their tests. Never do this.

一些开发人员在彼此内部嵌套描述块以组织测试。 永远不要这样做。

Instead of writing tests like this:

而不是像这样编写测试：

describe('API', () => {  describe('/books', () => {    describe('/id', () => {      describe('not found', () => {        test('returns 404', () => {          expect(4).toBe(4)        })      })    })  })})

Write tests like this:

编写这样的测试：

describe('API', () => {  test('returns 404 when /books/id is not found', () => {    expect(4).toBe(4)  })})

Never nest describe blocks. Maintaining twenty or thirty tests in files with nested describe blocks is really confusing. You waste time deciding what block a new test should go in, and it’s easy to accidentally delete a closing curly brace.

切勿嵌套描述块 。 在带有嵌套描述块的文件中维护二十或三十个测试确实令人困惑。 您浪费时间来决定应加入新测试的块，并且很容易意外删除右花括号。

Nested describe blocks add unnecessary cognitive load.

嵌套的描述块会增加不必要的认知负担。

针对不同类型的测试编写不同的规范 (Write different specs for different types of tests)

There are two types of test specifications you’ll write — high-level specs, and developer-level specs.

您将编写两种类型的测试规范- 高级别规范和开发人员级别规范 。

End to end tests need high-level specs. The actions that end to end tests perform are high-level, and the specification should match that.

端到端测试需要高级规范。 端到端测试执行的操作是高级别的，规范应与此相匹配。

High-level specifications are the kind of specs your manager might give you — the modal opens when the user clicks a button. You could show your manager the specs, and he’d understand what the test is for.

高级规范是您的经理可能会给您的规范- the modal opens when the user clicks a button会the modal opens when the user clicks a button 。 您可以向您的经理展示规格，他会了解测试的目的。

On the other hand, unit tests need developer-level specifications.

另一方面，单元测试需要开发人员级别的规范。

Unit tests check how functions in our code work. They’re low level, so the specifications should reflect that.

单元测试检查代码中的功能如何工作。 它们是低级别的，因此规格应该反映出来。

Developer-level specs only make sense to other developers, such asbutton should trigger action with displayModal true when clicked. They can mention concepts that don’t make sense to non-devs. They can use terms like Boolean, and throws error.

开发人员级别的规范仅对其他开发人员有意义，例如， button should trigger action with displayModal true when clicked ， button should trigger action with displayModal true when clicked 。 他们可能会提到对非开发人员没有意义的概念。 他们可以使用Boolean术语，并throws error 。

Think of unit tests as documentation for future developers, think of end to end tests as documentation for future project managers. And make sure your specifications reflect that.

将单元测试视为未来开发人员的文档，将端到端测试视为未来项目经理的文档。 并确保您的规格反映了这一点。

呼吁采取行动 (Call to action)

Now that you know how to write high quality test specifications, go out and write some tests! If you don’t know how to write tests, the getting started guide from Jest is a great place to start.

现在您知道如何编写高质量的测试规范，请出去编写一些测试！ 如果您不知道如何编写测试，那么Jest入门指南就是一个不错的起点。

翻译自: https://www.freecodecamp.org/news/want-your-tests-to-be-more-effective-write-your-specifications-like-this-5d701a961e35/

eos测试规格