import React from 'react'
import { render, cleanup, fireEvent} from 'react-testing-library'; //Added FireEvent from React Testing Library
import BookForm from './BookForm';

afterEach(cleanup)

test('<BookForm>', () => {
  const {debug, getByText} = render(<BookForm/>)
  expect(getByText('Submit').tagName).toBe('BUTTON') //Looks for an element with the text Submit, just for the sake of being different.
  fireEvent.click(getByText('Submit'))
  debug()
});

import React, { Component } from 'react'

export default class BookForm extends Component {
    render() {
        return (
            <div>
               <form data-testid='book-form' onSubmit={ ()=> console.log("clicked the button!")}>
                   <button type="submit">Submit</button>
               </form>
            </div>
        )
    }
}
```



The reason I added that click function is to show that when we run the test, we can see that `clicked the button!` appears in the log:

That might be useful in testing things work in a quick and dirty way. But if that form submission actually did something, then our tests would start getting dangerous so we need a safe way to submit the form when testing. To do this we need to consider the pattern we use for the component so we can safely mock it. This involves providing the function that runs on submit via props. The component we will end up with looks like this:



````js
export default class BookForm extends Component {

    state = {
        text: ''
    }
    render() {
        const {submitForm} = this.props
        const {text} = this.state
        return (
            <div>
               <form data-testid='book-form' onSubmit={ ()=> submitForm({text})}>

                   <button type="submit">Submit</button>
               </form>
            </div>
        )
    }
}

import React from 'react'
import { render, cleanup, fireEvent} from 'react-testing-library'; 
import BookForm from './BookForm';

afterEach(cleanup)
const onSubmit = jest.fn(); //Our new Spy function

test('<BookForm>', () => {
  const {debug, getByText, queryByTestId} = render(<BookForm submitForm={onSubmit} />) // The spy function is used to for the submit form

  //Unit Tests to check elements exist
  expect(queryByTestId('book-form')).toBeTruthy()
  expect(queryByTestId('book-form').tagName).toBe("FORM")
  expect(getByText('Submit').tagName).toBe('BUTTON')

  //Check Form Submits
  fireEvent.click(getByText('Submit'))
  expect(onSubmit).toHaveBeenCalledTimes(1); //This tests makes sure we van submit the spy function
  debug()
});
```



So to repeat what the comments say, we...:

1. Create a spy function that does nothing
2. This function is passed via props when we render the component.
3. We test to see if it runs with a `expect(onSubmit).toHaveBeenCalledTimes(1)`. Which hopefully it does.

This is all very clever but we have not done much but tested the form submits ok. Which is important but let's take things a step further looking at the inputs that are submitted.


### Bonus: Spying on Console Errors

We can spy on pretty much anything we like. Even errors when a component is not called properly. Let's say, for example, we had a component that needs a bunch of props with specific proptypes defined, we may want to test what happens when we don't provide them. So we can use the mocking function to handle the console errors like so:



````js
console.error = jest.fn()
test('<ExampleComponent'>, () => {
  render(<ExampleComponent />)
    expect(console.error).toBeCalled()
});
```
{% endraw %}


Of course, while this gets rid of the console error, this will still show any errors that may occur due to the lack of props passed in.

Right, back to our scheduled blogging.

## Specifying Input Values for testing

To make our testing more aligned to real-life we may want to write a test that checks that a form can be submitted with certain specified inputs. In our example, we want our Book Form to have a text input for a title. The way you might approach this is as follows:

1. Find a way to target the relevant part to be tested (i.e. the input field)
2. Change the value of the input.
3. Check that the form was submitted with the value we wanted.

That is pretty good but there is a gotcha you need to be aware of. Changing the value of the input does not cause React's state to update in our test, we need to use a **change* event to update the value for the change to occur. Here are the additional parts we need to add to do this:
{% raw %}



````js
test('<BookForm>', () => {
  const {getByLabelText} = render(<BookForm submitForm={onSubmit} />) //Adding the getByLabelText

  //1. Unit Test to check our input element exists
  expect(getByLabelText('Title').tagName).toBe('INPUT') //test to make sure the input is there

  //2. change the Input Value using the change event.
  fireEvent.change(getByLabelText('Title'), {target: {value: "Girl, Woman, Other"}}) //This event sets the value of the input and lets the change affect the state. 

  //3. Check Form Submits as expected
  fireEvent.click(getByText('Submit'))
  expect(onSubmit).toHaveBeenCalledWith({title: 'Girl, Woman, Other'}) //This checks that the submission has the title we asked it to have earlier.

```



  Note that I am using a new query, *getByLabelText* which, unsurprisingly looks at the text of the label to find the element we are after. Step 2, is where we use our fireEvent. since our target is the input element, we need to drill down to find our value and change it. Finally, we can check what our Spy function used with the *toHaveNeenCalledWith* method which is hopefully an easy one to understand. 

So we better see what the React code looks like that passes these tests:



  ```js
import React, { Component } from 'react'
export default class BookForm extends Component {

    state = {
        title: '' //what gets sent on submit
    }

    render() {
        const {submitForm} = this.props
        const {title} = this.state
        return (
            <div>
               <form data-testid='book-form' onSubmit={ ()=> submitForm({title})}>
                   <label htmlFor="title">Title</label> //Remember that it is the text of the element our test is looking for not the HTMLFor
                   <input id="title" type="text" onChange={(e) => this.setState({title: e.target.value})}></input> //Quick and Dirty input controlling
                   <button type="submit">Submit</button>
               </form>
            </div>
        )
    }
}
```



Cool, now it isn't the most complex form in the world but hopefully, you can see how the techniques can be scaled up accordingly and also are getting a grasp of how simply we test dynamic content. If you set up the snapshot test earlier you will now see they can be a little annoying when you are writing out the code!

### Bonus: Negative Assertions

In our test we had the following line: 

> expect(onSubmit).toHaveBeenCalledWith({title: 'Girl, Woman, Other'})  

Which is checking if that assertion is true if it **did** happen. There might be occasions where passing means checking if something **did not** happen. In Jest that's as easy as adding a `not` as part of the method like so:

> expect(onSubmit).not.toHaveBeenCalledWith({title: 'Girl, Woman, Other'}) 

This can be useful when, for example, you are testing what happens when data is not provided by props to a component that needs them. Which is handy as our next topic is...


## Mocking Props

So we are able to emulate form data, but another thing we commonly deal with in React is props. If our component needs props, we need a way of providing some. On a basic level, this is quite straightforward if all the above-made sense. In our test we need to: 

1. Mock out what the props should be 
2. Include those props when we render:



````js
console.error = jest.fn()

const book = {
  title: "The Stand"
}

test('<Book> without Book props', () => { //No props so 
  render(<Book />)
  expect(console.error).toHaveBeenCalled();
})

test('<Book> with Book Props', () => {
  render(<Book book={book}/>)
  expect(console.error).not.toHaveBeenCalled();
})
```



Pretty cool right? Well yes but now we are into multiple tests, we have a little gotcha to be aware of. In the example above we have two places where we check if the console.error has been called. Once without props and a second time without props where we expect that it will not run. However, if you run this it will fail as it will say that console.error was run the second time.... what gives?!

Put simply, console.error was called when it ran the first test so it thinks it was called when doing the second. The fix for this is fairly simple and requires a tweak to our clean up function.



````js
afterEach( () => {
  cleanup
  console.error.mockClear()
})
```



Now the memory of the console error is cleared between tests and things are more normal.

There are unfortunately lots of little gotchas you will hit as you start testing real-world components. A common one is around React Router expecting things that are not found in the test by default, it's beyond the scope of this blog post to cover all use cases but its the kind of thing that is going to [need some research](https://stackoverflow.com/questions/43771517/using-jest-to-test-a-link-from-react-router-v4) when you encounter them. 

Taking a step by step approach when writing tests and code does help narrow down and help search for solutions to such issues.

## Wrapping things up

This is one of those annoying blog posts where I touch on some things and ignore others. hopefully testing props, forms and inputs are useful to most users of React. My goal is to give a grounding in 60% of what you would typically test and give you a little context to search for the other 40%

Next time we can look at testing APIs and the async fun that brings!