DEV Community


Discussion on: The religion of test-driven development

frontendphil profile image
Philipp Giese Author

Glad I could help. Maybe look at it like this. If it's hard for you to write a test then it will also be hard for people with a screen reader to navigate your app. This motivated me a lot to get more comfortable with accessibility.

What you're describing looks like this to me:

const { getByLabelText, getByRole } = render(<Form />)

fireEvent.change(getByLabelText('Text input'), { 
  target: { 
    value: 'input value' 

fireEvent.focus(getByLabelText('Dropdown'))'option', { 
  name: 'The option you want to select' 
Enter fullscreen mode Exit fullscreen mode

Accessing the request is a tricky thing. However, we can make this more accessible in our tests as well. For instance, we've created a custom render method that fits our codebase. So when we use our custom render we can do more things:

const { getFetchRequest, getByRole } = customRender(<Form />)'button', {
  name: 'Submit'

const request = getFetchRequest(SUBMIT_REGISTRATION)

expect(request.body).toHaveProperty('emailAddress', '')
Enter fullscreen mode Exit fullscreen mode

We've taken what is complicated (getting the request) and turned it into a feature of our custom render wrapper so that developers can write tests more easily.

This can be true for a lot of things. redux, session handling, theming, etc... If something is very common in your app there is no rule that should keep you from extending your testing utilities.