I wish to display you one thing. What I will display is a common checking out
theory, implemented to a React part check. So despite the fact that the instance is a
React one, expectantly it is helping keep up a correspondence the concept that correctly.

Be aware: my level is not that nesting is dangerous on its own, however fairly that it
naturally encourages the usage of check hooks (reminiscent of beforeEach) as a mechanism
for code reuse which does result in unmaintainable exams. Please learn on…

Here is a React part that I wish to check:

// login.js
import * as React from 'react'

serve as Login({onSubmit}) {
  const [error, setError] = React.useState('')

  serve as handleSubmit(occasion) {
    occasion.preventDefault()
    const {
      usernameInput: {price: username},
      passwordInput: {price: password},
    } = occasion.goal.parts

    if (!username) {
      setError('username is needed')
    } else if (!password) {
      setError('password is needed')
    } else {
      setError('')
      onSubmit({username, password})
    }
  }

  go back (
    <div>
      <shape onSubmit={handleSubmit}>
        <div>
          <label htmlFor="usernameInput">Username</label>
          <enter identity="usernameInput" />
        </div>
        <div>
          <label htmlFor="passwordInput">Password</label>
          <enter identity="passwordInput" kind="password" />
        </div>
        <button kind="publish">Post</button>
      </shape>
      {error ? <div function="alert">{error}</div> : null}
    </div>
  )
}

export default Login

And here is what that renders (it in fact works, take a look at it):

Here is a check suite that resembles the type of checking out I have observed through the years.

// __tests__/login.js
import {render} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import * as React from 'react'

import Login from '../login'

describe('Login', () => {
  let utils,
    handleSubmit,
    consumer,
    changeUsernameInput,
    changePasswordInput,
    clickSubmit

  beforeEach(() => {
    handleSubmit = jest.fn()
    consumer = {username: 'michelle', password: 'smith'}
    utils = render(<Login onSubmit={handleSubmit} />)
    changeUsernameInput = price =>
      userEvent.kind(utils.getByLabelText(/username/i), price)
    changePasswordInput = price =>
      userEvent.kind(utils.getByLabelText(/password/i), price)
    clickSubmit = () => userEvent.click on(utils.getByText(/publish/i))
  })

  describe('when username and password is supplied', () => {
    beforeEach(() => {
      changeUsernameInput(consumer.username)
      changePasswordInput(consumer.password)
    })

    describe('when the publish button is clicked', () => {
      beforeEach(() => {
        clickSubmit()
      })

      it('must name onSubmit with the username and password', () => {
        be expecting(handleSubmit).toHaveBeenCalledTimes(1)
        be expecting(handleSubmit).toHaveBeenCalledWith(consumer)
      })
    })
  })

  describe('when the password isn't equipped', () => {
    beforeEach(() => {
      changeUsernameInput(consumer.username)
    })

    describe('when the publish button is clicked', () => {
      let errorMessage
      beforeEach(() => {
        clickSubmit()
        errorMessage = utils.getByRole('alert')
      })

      it('must display an error message', () => {
        be expecting(errorMessage).toHaveTextContent(/password is needed/i)
      })
    })
  })

  describe('when the username isn't equipped', () => {
    beforeEach(() => {
      changePasswordInput(consumer.password)
    })

    describe('when the publish button is clicked', () => {
      let errorMessage
      beforeEach(() => {
        clickSubmit()
        errorMessage = utils.getByRole('alert')
      })

      it('must display an error message', () => {
        be expecting(errorMessage).toHaveTextContent(/username is needed/i)
      })
    })
  })
})

That are meant to give us 100% self assurance that this part works and can proceed
to paintings as designed. And it does. However listed below are the issues I do not like about
that check:

I think just like the utilities like changeUsernameInput and clickSubmit can also be
great, however the exams are easy sufficient that duplicating that code as a substitute may
simplify our check code a bit of. It is simply that the abstraction of the serve as
does not truly give us loads of receive advantages for this small set of exams, and
we incur the fee for maintainers to have to go searching the document for the place
the ones purposes are outlined.

The exams above are written with Jest APIs, however you’ll be able to
in finding identical APIs in all main JavaScript frameworks. I am speaking in particular
about describe which is used for grouping exams, beforeEach for commonplace
setup/movements, and it for the real assertions.

I’ve a powerful dislike for nesting like this. I have written and maintained
hundreds of exams that have been written like this and I will be able to inform you that as
painful as it’s for those 3 easy exams, it is means worse in case you have
hundreds of strains of exams and finally end up nesting even additional.

What makes it so complicated? Take this bit as an example:

it('must name onSubmit with the username and password', () => {
  be expecting(handleSubmit).toHaveBeenCalledTimes(1)
  be expecting(handleSubmit).toHaveBeenCalledWith(consumer)
})

The place is handleSubmit coming from and what is its price? The place is consumer coming
from? What is its price? Oh certain, you’ll move in finding the place it is outlined:

describe('Login', () => {
  let utils,
    handleSubmit,
    consumer,
    changeUsernameInput,
    changePasswordInput,
    clickSubmit
  // ...
})

However you then additionally have to determine the place it is assigned:

beforeEach(() => {
  handleSubmit = jest.fn()
  consumer = {username: 'michelle', password: 'smith'}
  // ...
})

After which, you need to ensure that it is not in fact being assigned to
one thing else in an additional nested beforeEach. Tracing throughout the code to
stay monitor of the variables and their values over the years is the number 1 explanation why
I strongly counsel towards nested exams. The extra you need to dangle to your
head for menial such things as that, the fewer room there may be for undertaking the
vital job handy.

You’ll argue that variable reassignment is an “anti-pattern” and must be
have shyed away from, and I might believe you, however including extra linting laws in your suite
of perhaps already overbearing linting laws isn’t a terrific resolution. What
if there have been a approach to percentage this commonplace setup with no need to fret about
variable reassignment in any respect?

For this straightforward part, I believe the most productive resolution is to only take away as a lot
abstraction as conceivable. Test this out:

// __tests__/login.js
import {render} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import * as React from 'react'

import Login from '../login'

check('calls onSubmit with the username and password when publish is clicked', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText, getByText} = render(<Login onSubmit={handleSubmit} />)
  const consumer = {username: 'michelle', password: 'smith'}

  userEvent.kind(getByLabelText(/username/i), consumer.username)
  userEvent.kind(getByLabelText(/password/i), consumer.password)
  userEvent.click on(getByText(/publish/i))

  be expecting(handleSubmit).toHaveBeenCalledTimes(1)
  be expecting(handleSubmit).toHaveBeenCalledWith(consumer)
})

check('displays an error message when publish is clicked and no username is supplied', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText, getByText, getByRole} = render(
    <Login onSubmit={handleSubmit} />,
  )

  userEvent.kind(getByLabelText(/password/i), 'anything else')
  userEvent.click on(getByText(/publish/i))

  const errorMessage = getByRole('alert')
  be expecting(errorMessage).toHaveTextContent(/username is needed/i)
  be expecting(handleSubmit).no longer.toHaveBeenCalled()
})

check('displays an error message when publish is clicked and no password is supplied', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText, getByText, getByRole} = render(
    <Login onSubmit={handleSubmit} />,
  )

  userEvent.kind(getByLabelText(/username/i), 'anything else')
  userEvent.click on(getByText(/publish/i))

  const errorMessage = getByRole('alert')
  be expecting(errorMessage).toHaveTextContent(/password is needed/i)
  be expecting(handleSubmit).no longer.toHaveBeenCalled()
})

Be aware: check is an alias for it and I simply want the usage of check when I am not
nested in a describe.

You’ll be able to realize that there’s a little bit of duplication there (we’re going to get to that), however
have a look at how transparent those exams are. Except some check utilities and
the Login part itself, all of the check is self-contained. This
considerably improves the power for us to know what is going on in every
check with no need to do any scrolling round. If this part had a couple of
dozen extra exams, the advantages could be much more potent.

Realize additionally that we are not nesting the entirety in a describe block, as a result of
it really is not essential. The whole thing within the document is obviously checking out the login
part, and together with even a unmarried degree of nesting is needless.

The AHA theory states that you simply must:

want duplication over the fallacious abstraction and optimize for trade first.

For our easy Login part right here, I might most likely go away the check as-is, however
let’s consider that it is a bit extra sophisticated and we are beginning to see some
issues of code duplication and we might like to cut back it. Will have to we achieve for
beforeEach for that? I imply, that is what it is there for proper?

Smartly, lets, however then we need to get started being concerned about mutable variable
assignments once more and we might love to steer clear of that. How else may we percentage code
between our exams? AHA! Lets use purposes!

import {render} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import * as React from 'react'

import Login from '../login'

// right here we've got a number of setup purposes that compose in combination for our check instances
// I simplest counsel doing this in case you have numerous exams that do the similar factor.
// I am together with it right here simplest for instance. Those exams do not necessitate this
// a lot abstraction. Learn extra: https://kcd.im/aha-testing
serve as setup() {
  const handleSubmit = jest.fn()
  const utils = render(<Login onSubmit={handleSubmit} />)
  const consumer = {username: 'michelle', password: 'smith'}
  const changeUsernameInput = price =>
    userEvent.kind(utils.getByLabelText(/username/i), price)
  const changePasswordInput = price =>
    userEvent.kind(utils.getByLabelText(/password/i), price)
  const clickSubmit = () => userEvent.click on(utils.getByText(/publish/i))
  go back {
    ...utils,
    handleSubmit,
    consumer,
    changeUsernameInput,
    changePasswordInput,
    clickSubmit,
  }
}

serve as setupSuccessCase() {
  const utils = setup()
  utils.changeUsernameInput(utils.consumer.username)
  utils.changePasswordInput(utils.consumer.password)
  utils.clickSubmit()
  go back utils
}

serve as setupWithNoPassword() {
  const utils = setup()
  utils.changeUsernameInput(utils.consumer.username)
  utils.clickSubmit()
  const errorMessage = utils.getByRole('alert')
  go back {...utils, errorMessage}
}

serve as setupWithNoUsername() {
  const utils = setup()
  utils.changePasswordInput(utils.consumer.password)
  utils.clickSubmit()
  const errorMessage = utils.getByRole('alert')
  go back {...utils, errorMessage}
}

check('calls onSubmit with the username and password', () => {
  const {handleSubmit, consumer} = setupSuccessCase()
  be expecting(handleSubmit).toHaveBeenCalledTimes(1)
  be expecting(handleSubmit).toHaveBeenCalledWith(consumer)
})

check('displays an error message when publish is clicked and no username is supplied', () => {
  const {handleSubmit, errorMessage} = setupWithNoUsername()
  be expecting(errorMessage).toHaveTextContent(/username is needed/i)
  be expecting(handleSubmit).no longer.toHaveBeenCalled()
})

check('displays an error message when password isn't equipped', () => {
  const {handleSubmit, errorMessage} = setupWithNoPassword()
  be expecting(errorMessage).toHaveTextContent(/password is needed/i)
  be expecting(handleSubmit).no longer.toHaveBeenCalled()
})

Now we can have dozens of exams that use those easy setup purposes, and
realize additionally that they may be able to be composed in combination to offer us a identical conduct as
the nested beforeEach that we had sooner than if that is sensible. However we steer clear of
having mutable variables that we need to fear about maintaining a tally of in our
thoughts.

You’ll be informed extra about the advantages of AHA with checking out from
AHA Checking out.

The describe serve as is meant to team similar exams in combination and will
supply for a pleasing approach to visually separate other exams, particularly when the
check document will get giant. However I do not love it when the check document will get giant. So as a substitute
of grouping exams by way of describe blocks, I team them by way of document. So if there is a
logical grouping of various exams for a similar “unit” of code, I will separate
them by way of striking them in utterly other recordsdata. And if there may be some code
that truly must be shared between them, then I will create a
__tests__/helpers/login.js document which has the shared code.

This comes with the advantage of logically grouping exams, utterly setting apart
any setup that is distinctive for them, decreasing the cognitive load of operating on a
explicit a part of the unit of code I am operating on, and in case your checking out
framework can run exams in parallel, then my exams will most likely run sooner as
smartly.

This weblog publish is not an assault on utilities like beforeEach/afterEach/and so forth.
It is extra of a warning towards mutable variables in exams, and being aware of
your abstractions.

For cleanup, on occasion you are caught with a state of affairs the place the article you are
checking out makes some adjustments to the worldwide surroundings and you wish to have to cleanup
after it. Should you attempt to put that code inline inside of your check, then a check
failure would outcome to your cleanup no longer working which might then result in different
exams failing, in the end leading to numerous error output this is more difficult to
debug.

NOTE: This case used to be written sooner than @testing-library/react@9 which made
cleanup automated. However the concept that nonetheless applies and I did not wish to rewrite
the instance 😅

As an example, React Checking out Library will insert your part into the file,
and if you do not cleanup after every check, then your exams can run over
themselves:

import {render} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import * as React from 'react'

import Login from '../login'

check('instance 1', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  userEvent.kind(getByLabelText(/password/i), 'ilovetwix')
  // extra check right here
})

check('instance 2', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  // 💣 this will likely blow up for the reason that `getByLabelText` is in fact querying the
  // whole file, and since we did not cleanup after the former check
  // we're going to get an error indicating that RTL discovered multiple box with the
  // label "username"
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  // extra check right here
})

Solving that is lovely easy, you wish to have to execute the cleanup approach from
@testing-library/react after every check.

import {cleanup, render} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import * as React from 'react'

import Login from '../login'

check('instance 1', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  userEvent.kind(getByLabelText(/password/i), 'ilovetwix')
  // extra check right here
  cleanup()
})

check('instance 2', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  // extra check right here
  cleanup()
})

Alternatively, in case you do not use afterEach to try this then if a check fails your
cleanup wont run, like this:

check('instance 1', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  // 💣 the next typo will lead to a error thrown:
  //   "no box with the label matching passssword"
  userEvent.kind(getByLabelText(/passssword/i), 'ilovetwix')
  // extra check right here
  cleanup()
})

As a result of this, the cleanup serve as in “instance 1” is not going to run after which
“instance 2” wont run correctly, so as a substitute of simplest seeing 1 check failure, you’ll be able to
see that all of the exams failed and it’s going to make it a lot more difficult to debug.

So as a substitute, you should utilize afterEach and that may make certain that despite the fact that your
check fails, you’ll cleanup:

import {cleanup, render} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import * as React from 'react'

import Login from '../login'

afterEach(() => cleanup())

check('instance 1', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  userEvent.kind(getByLabelText(/password/i), 'ilovetwix')
  // extra check right here
})

check('instance 2', () => {
  const handleSubmit = jest.fn()
  const {getByLabelText} = render(<Login onSubmit={handleSubmit} />)
  userEvent.kind(getByLabelText(/username/i), 'kentcdodds')
  // extra check right here
})

Even higher, with React Checking out Library,
cleanup
is known as after every check routinely by way of default. Be informed extra within the
medical doctors

As well as, on occasion there are certainly just right use instances for sooner than*, however
they are most often matched with a cleanup that is essential in an after*. Like
beginning and preventing a server:

let server
beforeAll(async () => {
  server = look ahead to startServer()
})
afterAll(() => server.shut())

There is no longer truly every other dependable means to try this. Any other use case I will be able to
bring to mind that I have used those hooks is for checking out console.error calls:

beforeAll(() => {
  jest.spyOn(console, 'error').mockImplementation(() => {})
})

afterEach(() => {
  console.error.mockClear()
})

afterAll(() => {
  console.error.mockRestore()
})

So there are certainly use instances for the ones types of hooks. I simply do not
counsel them as a mechanism for code reuse. We’ve purposes for that.

I am hoping this is helping explain what I supposed on this tweet:

I have written tens of hundreds of exams with other frameworks and types and
in my enjoy, decreasing the volume of variable mutation has ended in
hugely more effective check repairs. Excellent good fortune!

P.S. If you would like to play with the examples,
here is a codesandbox