In this blog post I would like to discuss about **React Testing Library** (RTL) using **Test Driven Development** (TDD) with some working examples.

Before we jump into details of the RTL, let’s have a quick overview about TDD. TDD as an approach evolved from Agile manifesto and Extreme programming.

In TDD, the feature development starts off with *writing the failing test first*. The developer should write less or required amount of code to pass the test. The code should be revised until the test passes. If the test passes then refactor the code to align with the team's development best practices / clean code and make it production ready. The above process has to be repeated throughout the development of the feature, by writing the failing tests first. In the end, we'll have a suite of automated tests which will give more **confidence** about the feature.

<figure style="text-align:center;margin:2px">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646063388/Blogs/tdd-rtl/tdd_ay8fkm.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646063388/Blogs/tdd-rtl/tdd_ay8fkm.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646063388/Blogs/tdd-rtl/tdd_ay8fkm.png" style="width:auto;" alt="TDD approach">
</picture>
  <figcaption align = "center"><b>Fig.1 - TDD cycle</b></figcaption>
</figure>


RTL is a light-weight opinionated library used to test react components and it is an alternate solution to [Enzyme](https://enzymejs.github.io/enzyme/)

The key principle that I like about this library is, it encourages to test the behaviour of the component rather than its internal implementation.
As its guiding principle states 

> The more your tests resemble the way your software is used, the more confidence they can give you.

I couldn’t agree more.

If you’re starting off with *create-react-app* it ships with React Testing Library out of the box. If you’re are working on stand-alone react projects you can add it to the project using

<pre style="width:100%"><code class="language-js">npm install --save-dev @testing-library/react</code></pre>

<div class="note">
<i>Fictional use case:</i> Let's say we're building a blogging website and we want to create comments widget to display comments associated with blog posts. Each comment will render the details based on the below wireframe diagram. If the logged in user is the owner of the comment then they can perform edit and delete operations.
</div>

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646062887/Blogs/tdd-rtl/comment-wirefrane_tgu5c8.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646062887/Blogs/tdd-rtl/comment-wirefrane_tgu5c8.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646062887/Blogs/tdd-rtl/comment-wirefrane_tgu5c8.png" style="width:auto;" alt="comment component wireframe">
</picture>
  <figcaption align = "center"><b>Fig.2 - Comment component wireframe</b></figcaption>
</figure>

I prefer developing features using **bottom-up** approach. It helps to compose components one by one and gradually form the complete feature. It also helps to test components in isolation and ensures modularity.

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646062887/Blogs/tdd-rtl/comment-breakdown_pg2mw3.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646062887/Blogs/tdd-rtl/comment-breakdown_pg2mw3.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646062887/Blogs/tdd-rtl/comment-breakdown_pg2mw3png" style="width:auto;" alt="comment component composition">
</picture>
  <figcaption align = "center"><b>Fig.2 - Comment component composition</b></figcaption>
</figure>

Let's start with our first test that renders `Comment` component.

<script type="text/plain" class="language-jsx line-numbers" data-line="1,4">import { render } from '@testing-library/react';
  describe('Comment component', () => {
	it('should render component without errors', () => {
		render(<Comment />);
	});
});
</script>

In this simple test we're trying to render the `Comment` component using `render()` method. As name suggests, it helps to `render` the component into a container which will be appended to `document.body`. Let's run our first test and see what happens.


<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646314413/Blogs/tdd-rtl/first-failing-test_g4nyxh.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/first-failing-test_g4nyxh.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/first-failing-test_g4nyxh.png" style="width:auto;" alt="first failing test">
</picture>
  <figcaption align = "center"><b>Fig.3 - Our first failing test</b></figcaption>
</figure>

It failed, as we didn't import the <Comment/> component yet. Let's quickly add a simple `Comment` component.

<script type="text/plain" class="language-jsx line-numbers">const Comment = () => {
	return <div></div>;
  };
  export default Comment;
</script>

Now with this `not-yet-there` Comment component in place let's import it and run our test again.

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646314413/Blogs/tdd-rtl/first-passing-test_o0bxax.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/first-passing-test_o0bxax.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/first-passing-test_o0bxax" style="width:auto;" alt="first passing test">
</picture>
  <figcaption align = "center"><b>Fig.4 - Our first passing test</b></figcaption>
</figure>

Yaaay, our first test passed, that's a WIN 🙌  . Let us continue with our next test to display all necessary properties of the comment component. Also, we can assume Comment component will get the `data` props with all details of a comment from API. After setting up mock props, our test will look like this.

<script type="text/plain" class="language-jsx line-numbers" data-line="12">it('should display `user name, avatar, body` of the comment', () => {
		const data = {
			id: 1,
			name: 'Alice Bob',
			avatar: 'https://api.multiavatar.com/alice',
			publishedAt: '2022-02-19T16:27:22.112Z',
			authorId: 123,
			blogId: 34,
		};
		render(<Comment data={data} />);

		const username = screen.getByText(data.name);
		expect(username).toBeInTheDocument();
	});
</script>

To identity a particular element from the page, RTL provides a set of `Queries`.  More details and types of queries can be [found here](https://testing-library.com/docs/queries/about). In our case we're using `getByText()` method to match the given string in the document. 

Our test failed, since our Comment component doesn't render the comment author name yet. It also points out the exact line where it failed along with detailed explanation.

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646314413/Blogs/tdd-rtl/comment-data-fail_lk3mtf.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/comment-data-fail_lk3mtf.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/comment-data-fail_lk3mtf.png" style="width:auto;" alt="second failing test">
</picture>
  <figcaption align = "center"><b>Fig.5 - Our second failing test</b></figcaption>
</figure>

Let's wire up our `Comment` component to accept the props from parent component and render the details based on the mock up. In the below code we have setup some containers to apply required styling to match the wireframe and render the *user name* from the props.

<script type="text/plain" class="language-jsx line-numbers" data-line="7">const Comment = (props) => {
	const { data } = props;

	return (
		<div className="comment-container" data-testid={data.id}>
			<div className="comment">
				<h3 className="user-name">{data.name}</h3>
			</div>
		</div>
	);
};</script>

Now let's run our failing test and see what happens.

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646314413/Blogs/tdd-rtl/second-passing-test_yga3ck.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/second-passing-test_yga3ck.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/second-passing-test_yga3ck.png" style="width:auto;" alt="second passing test">
</picture>
  <figcaption align = "center"><b>Fig.6 - Our second passing test</b></figcaption>
</figure>

As the query selector `getByText()` method found the matching text in the page our second test also passed 🥳  . As per the test descriptor we need to test other properties `avatar` and `body`. Let's add assertions for those properties and repeat the `fail`  ➡️  `pass` ➡️   `refactor` approach. After adding the necessary elements to the component the final code will look something like this to match the wireframe.

<script type="text/plain" class="language-jsx line-numbers" data-line="12-23">import ReactTimeAgo from 'react-time-ago';
import TimeAgo from 'javascript-time-ago';

import en from 'javascript-time-ago/locale/en.json';
TimeAgo.addLocale(en);

const Comment = (props) => {
	const { data } = props;

	return (
		<div className="comment-container" data-testid={data.id}>
			<img src={data.avatar} className="avatar" alt={data.name} />
			<div className="comment">
				<h3 className="user-name">{data.name}</h3>
				<p className="publishedTime">
					<ReactTimeAgo
						date={Date.parse(data.publishedAt)}
						locale="en-US"
						timeStyle="round-minute"
					/>
				</p>
				<p>{data.body}</p>
			</div>
		</div>
	);
};

export default Comment;</script>

I have used `react-time-ago` npm package to render the comment published time in a user-friendly way. The final test to assert all comment properties will look something like this.

<script type="text/plain" class="language-jsx line-numbers" data-line="12-25">it('should display `user name, avatar, body, published time` of the comment', () => {
		const data = {
			id: 1,
			name: 'Alice Bob',
			avatar: 'https://api.multiavatar.com/alice',
			publishedAt: '2022-02-19T16:27:22.112Z',
			authorId: 123,
			blogId: 34,
			body: 'Curabitur arcu erat, accumsan id imperdiet et, porttitor at sem.',
		};

		//arrange
		render(<Comment data={data} />);

		//act
		const username = screen.getByText(data.name);
		const avatar = screen.getByRole('img');
		const comment = screen.getByText(data.body);
		const timeAgo = screen.getByText(/ago/);

		//assert
		expect(username).toBeInTheDocument();
		expect(avatar).toBeInTheDocument();
		expect(comment).toBeInTheDocument();
		expect(timeAgo).toBeInTheDocument();
	});</script>

As you can see we can organise our component testing with [Arrange Act Assert pattern](https://automationpanda.com/2020/07/07/arrange-act-assert-a-pattern-for-writing-good-tests/). The same technique should be applied for `CommentActions` component too to test the edit and delete actions. Here is the final code for the `CommentActions` component.

<script type="text/plain" class="language-jsx line-numbers" data-line="20">import { useSession } from './utils';
const Actions = (props) => {
	const { handleDelete, commentId } = props;
	const handleEdit = () => console.log('Edit comment');
	const handleCommentDelete = () => {
		handleDelete(commentId);
	};
	return (
		<>
			<button onClick={handleEdit}>EDIT</button>
			<button onClick={handleCommentDelete} className="danger">
				DELETE
			</button>
		</>
	);
};

const CommentActions = (props) => {
	const { authorId, handleDelete, commentId } = props;
	const { user } = useSession();

	return (
		<div className="actions">
			{user.id === authorId && (
				<Actions handleDelete={handleDelete} commentId={commentId} />
			)}
		</div>
	);
};

export default CommentActions;</script>

### jest.spyOn
The `useSession` method provides the logged-in user details which is used to check against the comment author for enabling `edit` and `delete` buttons. As user session involves user login and dependency with multiple modules, we can intercept the `useSession` method in our test using [Jest spy](https://jestjs.io/docs/jest-object#jestspyonobject-methodname) method. Here is the complete test code for `CommentActions` component with 
jest spy to test our component in isolation.

<script type="text/plain" class="language-jsx line-numbers" data-line="8-10">import { render, screen } from '@testing-library/react';
import CommentActions from './CommentActions';
import '@testing-library/jest-dom';
import * as utils from './utils';

describe('Comment Actions component', () => {
	beforeEach(() => {
		jest.spyOn(utils, 'useSession').mockReturnValue({
			user: { id: '123', email: 'a@b.com' },
		});
	});

	it('should render `edit, delete` options when comment author logged in', () => {
		render(<CommentActions authorId={'123'} />);

		const editButton = screen.getByRole('button', { name: 'EDIT' });
		expect(editButton).toBeInTheDocument();

		const deleteButton = screen.getByRole('button', { name: 'DELETE' });
		expect(deleteButton).toBeInTheDocument();
		expect(deleteButton).toHaveClass('danger');

		const buttons = screen.getAllByRole('button');
		expect(buttons).toHaveLength(2);
	});

	it('should not render `edit, delete` options when comment author is different from logged in user', () => {
		render(<CommentActions authorId={'456'} />);

		const buttons = screen.queryAllByRole('button');
		expect(buttons).not.toHaveLength(2);
	});
});</script>

Given our `Comment` and `CommentActions` component working, here is the final output.

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646314413/Blogs/tdd-rtl/comment_l8zdun.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/comment_l8zdun.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/comment_l8zdun.png" style="width:auto;" alt="comment component">
</picture>
  <figcaption align = "center"><b>Fig.7 - Final comment component</b></figcaption>
</figure>

The next step is to build the parent component `Comments` that renders all available comments from the API. Here is the final version of the `Comments` component that uses Promise function to fetch the comments from remote API using `blogId`.


<script type="text/plain" class="language-jsx line-numbers" data-line="9-11">import { useState, useEffect } from 'react';
import Comment from './Comment';

const Comments = (blogId) => {
	const [comments, setComments] = useState([]);

	useEffect(() => {
		async function fetchData() {
			await fetch(
				`${process.env.REACT_APP_API_URL}/comments?blogID=${blogId}`
			)
				.then((response) => response.json())
				.then((data) => {
					setComments(data);
				});
		}
		fetchData();
	}, [blogId]);

	const handleDelete = (id) => {
		const afterDelete = comments.filter((comment) => comment.id !== id);
		setComments(afterDelete);
	};

	const commentComp = comments.map((comment) => (
		<div key={comment.id}>
			<Comment data={comment} handleDelete={handleDelete} />
		</div>
	));

	return (
		<div>
			<h2>Comments</h2>
			{commentComp}
		</div>
	);
};

export default Comments;</script>

As the `Comments` component is the parent which embeds other children components (`Comment, CommentActions`),  we can perform integration testing. This helps to test some of the functional requirements like

- Ensuring `EDIT` and `DELETE` options available only to own comments
- Simulate click events and check the behaviour
- Application state after deleting a comment
- Testing components with `async` operations

The final test code for our `Comments` component:

<script type="text/plain" class="language-jsx line-numbers" data-line="10-15,31">import { render, screen, waitFor, within } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

import Comments from './Comments';

describe('Comments component', () => {
	it('should render all available comments for given blog id', async () => {
		render(<Comments blogId={1} />);

		await waitFor(() => {
			const img = screen.queryAllByRole('img', {
				name: 'Alice Bob',
			});
			expect(img).toHaveLength(2);
		});
	});

	it('should not display deleted comments', async () => {
		render(<Comments blogId={1} />);

		await waitFor(() => {
			screen.getByTestId(1);
		});

		const comment = screen.getByTestId(1);
		const button = within(comment).getByRole('button', {
			name: 'DELETE',
		});
		expect(button).toBeInTheDocument();

		userEvent.click(button);
		expect(button).not.toBeInTheDocument();
	});
});</script>

### waitFor
It is used to test async scenarios, and it will wait until the expectation is passed. On line number 11, we're querying user name inside `waitFor` method and it will await until the query resolves before continuing the execution. More details on waitFor can be [found here](https://testing-library.com/docs/dom-testing-library/api-async#waitfor).

### userEvent
Last but not the least. The [userEvent](https://testing-library.com/docs/user-event/intro) method is used to simulate the user interactions with the document. In our user case we simulate the delete operation and ensure the element is removed from the DOM.

Now we have a test suite that covers individual component tests and integration tests as well. The final test summary shows all of our tests PASS and everything is in GREEN 💚 

<figure style="text-align:center;margin:8px;">
<picture>
  <source media="(max-width:415px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/c_scale,w_320/v1646314413/Blogs/tdd-rtl/final-test-report_rill8z.png">
  <source media="(min-width:500px)" srcset="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/final-test-report_rill8z.png">
  <img src="https://res.cloudinary.com/dar0q4nt3/image/upload/v1646314413/Blogs/tdd-rtl/final-test-report_rill8z.png" style="width:auto;" alt="final test result">
</picture>
  <figcaption align = "center"><b>Fig.8 - Final test result</b></figcaption>
</figure>

If you have made this far, then congratulations 🎉  . We have come to an end to the intro blog of React Testing Library with TDD. I hope it was useful, feel free to share your thoughts about this blog in the comment section 😀.

Github link to the completed project - [https://github.com/m0hanraj/social-comments](https://github.com/m0hanraj/social-comments)

<mark>References:</mark>
- [React Testing Library](https://testing-library.com/docs/react-testing-library/intro)
- [Create React App](https://create-react-app.dev/)


TDD with React Testing Library - component testing