BDD styled TDD with Jest, React, and React Hooks

4 min readNov 23, 2021

Both BDD and TDD refer to the methods of software development. Behavior-driven development (BDD) uses natural language statements to build a common understanding of the application. Here we show how we can use a sprinkle of BDD to help us with TDD

Whenever we start TDD on any application feature we need to answer a few questions:

What are we testing?
Where to store the tests?
Suite names?
Test case names?
What are we asserting?

Decide what you’re building / testing with simple requirements:

Let’s begin with the sample feature requirement. As part of a bigger application, a client wants us to build a product management feature:

List Products
Add Product
Update an existing Product
Delete an existing Product

What are we testing

To take us nearer to a starting point, we have to turn these requirements into features using a BDD approach.

We are going to use the BDD template for each scenario:

GIVEN (some starting condition)
WHEN (some action occurs)
THEN (expect some result)

Product List

GIVEN that a user is on the Product List Screen, WHEN the page loads, THEN product list data must be retrieved and displayed showing the name and price of each product in the list.
GIVEN that a user is on the Product List Screen WHEN the user clicks on an Add Product button THEN the user must be taken to the New Product Screen.

New Product

GIVEN that a user is on the New Product Screen WHEN the captures the name and price of a new product and clicks on a Save button THEN the new product data must be saved.

Product Detail

GIVEN that a user is on the Product Detail Screen WHEN the screen loads THEN the existing product data must be retrieved.
GIVEN that a user is on the Product Detail Screen WHEN the edits the name and price of an existing product and clicks on a Save button THEN the updated product data must be saved.
GIVEN that a user is on the Product Detail Screen WHEN the Delete button is clicked THEN the product data must be deleted.

Let’s get started

Let’s get started with the Product List View Model. This is where all logic (the brain) for the Product List View will be kept. Note: We’ll be building this using React and React Hooks. If you want to learn about custom hooks, read more here

What do we name our test suites?

A test suite is a collection of one or multiple test cases. In this case, the test suite is “Product List View Model”

What do we name our test cases?

Test cases contain the details and steps that one would need to perform to verify a certain behavior. So typically will begin with “should….”

Where do we store our Tests?

When writing tests I prefer to store my tests in a folder structure which mirrors the application. The view model is under test, so we create a test suite for this view model in the test folder.

Test Suite: Product List View Model

├─ src
    ├─ Domain
    │   └─ UseCase
    │       └─ Product
    │           └─ GetProducts.js
    └─ Presentation
        └─ View
            └─ Product
                ├─ List
                │   ├─ Components
                │   │   ├─ ProductList.js
                │   │   └─ AddButton.js
                │   ├─ View.js
                │   └─ ViewModel.js
                └─ index.js└─ tests
    Presentation
        └─ View
            └─ Product
                └─ List
                    └─ ViewModel.test.js

This test fails because we haven’t created the view model. Let’s create the bare minimum to make the test pass.

Let’s create another test to check for products once getProducts is called

Let’s modify our view model to make the test pass.

Let’s also mock the getProductsUseCase in our test. Note we don’t need a concrete implementation of this use case to test our view model. This can be an empty file for now.