Unit testing patterns

[guilhermebruzzi]

What is to be discussed?

We should create a pattern to be easier to read unit testing on PRs (specially if you don't have all the context on the project), and it is difficult to solve this with linter, so it must be a guide with good practices also.

Describe the solution you'd like

Me and @klzns and most of inStore team like this pattern of arrange, act and assert to do unit testing:

https://xp123.com/articles/3a-arrange-act-assert/
https://martinfowler.com/articles/practical-test-pyramid.html#TestStructure

So instead of:

it('test', () => {
  expect(myFunction({ param1: 'string', param2: 10, param3: true})).toEqual({
    a
    long
    object...
  })
})

You reorganize to do like that:

it('test', () => {
  const params = {
    param1: 'string',
    param2: 10,
    param3: true
  }
  const expectedResult = {
    a
    long
    object...
  }

  const result = myFunction(params)

  expect(result).toEqual(expectedResult)
})

Which is easier to read.

But we can create more nice patterns about this subject in this issue, not only the way you arrange it.

[gtkatakura]

Aligning describes based on a scenario (usually a predicate) and possible input values ​​makes it easier to see new scenarios and read test output, for example:

Code source of the example.

Some other interesting patterns from the ruby ​​community: http://betterspecs.org/

[klzns]

Some other interesting patterns from the ruby ​​community: http://betterspecs.org/

Interesting read! Thanks

[guilhermebruzzi]

The ruby ​​community is great at tooling and testing, very interesting stuff! :D

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is a discussion thread, the most voted option will be final. Thank you for your contributions.