DEV Community: Iheanacho Ebere

Mocking Axios GET Requests: A Practical Guide for Reliable React Testing using Jest

Iheanacho Ebere — Tue, 23 Jan 2024 08:53:43 +0000

For projects involving API data fetching, testing can be challenging, requiring actual API calls to validate results. However, this approach introduces issues like expense and speed variations due to network conditions. Mocking emerges as a solution, enabling developers to isolate their testing environment from external dependencies.

What Is Mocking?

Mocking is a technique that substitutes real objects or functions with simulated versions during testing. This practice allows developers to isolate components, control responses, and improve test speed and reliability.

During my exploration, I stumbled upon a fantastic article by Volodymyr Hudyma, titled 3 Ways To Mock Axios In Jest. The article outlines three approaches to mocking Axios, with two involving additional packages.

In this guide, we'll create a component utilizing Axios to make a GET request for fetching a list of users and rendering it in the DOM. Through this example, we'll dive into one approach to mocking in Jest.

The objective of this comprehensive guide is to provide you with a clear understanding of how to efficiently mock external API response when utilizing Axios, ensuring a consistent and reliable testing environment.

Prerequisites:

JavaScript Fluency: Understanding JavaScript is essential for working with React and testing frameworks.
React Basics: Familiarity with React components and their lifecycle is required to follow the tutorial effectively.

Project Setup

Component Creation: We'll build a React component that uses Axios to retrieve a user list and render it on the screen.

import { useEffect, useState } from "react"
import axios from "axios"                                                                       



function UserList() {
    const [userList, setUserList] = useState([])

    useEffect(()=>{
        const fetchUserList = async() =>{
            try{
                await axios.get("https://jsonplaceholder.typicode.com/users").then((res) => setUserList(res.data))
            } catch(err) {
                console.log(err)
            }
        }

        fetchUserList()
    },[])

    return (
        <div>
            <h2>Users</h2>
            {
                userList.map((user)=>{
                    return(
                        <div key={user.id}>
                            <p>{user.name}</p>
                            <p>{user.email}</p>
                        </div>
                    )
                })
            }
        </div>
    )
}

export default UserList

This component serves as a fundamental illustration of making an API call using the useEffect and useState hooks to manage state changes before the DOM reloads.

To effectively test this component, it's essential to isolate it from the external API and external modules by mocking Axios and controlling its response when called. This approach grants us complete control over the component, allowing precise interaction during testing. Below is an example of how our "userList.test.js" file should be structured:

import { render, screen, waitFor } from "@testing-library/react";
import UserList from "./userList";
import axios from "axios";
//mock the axios module
jest.mock("axios");

const dummyUserList = [
  {
    userId: 1,
    id: 1,
    name: "Nacho",
    email: "nacho@gmail.com"
  },
  {
    userId: 1,
    id: 2,
    name: "Nochi",
    email: "nochi@gmail.com"
  },
  {
    userId: 1,
    id: 3,
    name: "Davidszn",
    email: "david@gmail.com"
  },
];

describe("User component", () => {
  it("should render user header", async () => {
    render(<UserList />);

    // Wait for the asynchronous data fetching to complete
    await waitFor(() => {
      expect(screen.getByText(/users/i)).toBeInTheDocument();
    });
  });
  it("should render user list after fetching list", async ()=>{
    //resolving the get request with the dummyUserList
    axios.get.mockResolvedValue({ data: dummyUserList });

    // or you could use the following depending on your use case:
    // axios.get.mockImplementation(() => Promise.resolve(dummyUserList))

    render(<UserList/>)
    //another alternative to wait for block is findby queries
    expect(await screen.findByText(/nacho@gmail.com/i)).toBeInTheDocument()

    // Optionally, you can check for the number of calls to axios.get
    expect(axios.get).toHaveBeenCalledTimes(1);
  })
});

The Jest mock method allows us to mocks a module and returns an auto-mocked version when required during the test. Test 1 ensures the component renders the header text "users" after asynchronous data fetching. Utilize waitFor method to wait for the asynchronous operation to complete. Test 2 simulates the GET request using axios.get.mockResolvedValue method to resolve the response with the dummyUserList array then checks if the user list renders after fetching, using screen.findByText method. We can also optionally verify the number of calls to axios.get. There are also various Jest mock methods such as jest.fn, jest.spyOn, depending on the specific need or task.

If you run the test using npm test, you may encounter the following result:.

    SyntaxError: Cannot use import statement outside a module

      1 | import { useEffect, useState } from "react"
    > 2 | import axios from "axios"

How to fix the "Cannot use import statement outside a module" for axios libary?

This issue arises from a clash between the testing environment and the module, often related to the use of different JavaScript module systems (CommonJS vs. ES6 modules). It's a relatively rare but known issue, especially with Axios.

A potential fix for this problem involves adding a few specific lines to your "package.json" file:

"type": "module"

This informs Node.js that your project is using ES6 modules.

  "jest": {
    "transformIgnorePatterns": ["node_modules/(?!axios)/"]
}

The "transformIgnorePatterns" option is a solution that tells Jest to ignore transformation for files inside node_modules except for those in the axios module. Your "package.json" file should be configured as follows:

{
  "type": "module",
  "scripts": {
    "test": "npm test",
     // other scripts
  },
  "dependencies": {
    // your dependencies
  },
  "jest": {
    "transformIgnorePatterns": ["node_modules/(?!axios)/"]
}
  // other configurations
}

After restarting the test, you should obtain the following results

 PASS  src/user/userCard.test.js
  User component
    √ should render user header (327 ms)
    √ should render user list after fetching list (26 ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        4.893 s
Ran all test suites matching /userCard.test.js/.

The test passed because we were able to intercept the axios 'GET' request and changed the response to our dummyList so the Dom renders data from the dummyList, which use to test the component.

I hope this article has simplified the concept of mocking in React testing, especially in the context of handling bugs related to module systems. By intentionally choosing axios libary, I aimed to share a practical solution to a common issue I faced earlier on. Our exploration into the lost art of testing in React is far from over, and I'm excited to announce that the journey continues with the upcoming article on testing a react app using Redux.

Stay jiggy, and happy testing!

References

Exploring the Basics of React Testing: A Journey into Rendering and Interaction

Iheanacho Ebere — Wed, 10 Jan 2024 22:18:47 +0000

When building a website and integrating diverse features, manual testing may appear viable at the outset. However, for larger projects, relying solely on manual testing becomes impractical prompting the need for the implementation of unit tests. Not only do unit tests enhance the integrity of your application, but they also provide a more scalable and efficient approach to ensuring the functionality of your codebase.

What is unit test?
Unit testing is a testing methodology that assesses individual software units in isolation. It involves scrutinizing the output of a function for any given input. This process ensures the verification of component rendering for specific inputs to React components.

In essence, writing unit tests is simply writing code to ascertain the code works as expected.

In this article we are going to be looking at the fundamentals of react unit testing ,exploring essential concepts and structures.

Both Jest and React Testing Library come pre-packaged with Create React App and adhere to the guiding principle that testing apps should resemble how the software will be used.

Prerequisties

Npm and knowlegde on node and javascript
Familiarity on react

In testing, the focus is on ensuring that your code performs as intended in comparing expected and actual outputs. The major aspects to test in your code include:

Rendering with or without props: Check if a component renders correctly with or without specific props.
Rendering with state changes: Test how a component renders when there are changes in its state.
Reacting to user interactions: Assess how a component responds to user interactions.

However, certain elements do not require testing:

Actual Implementation: We don't need to test the exact implementation, we just need to ensure component produces the expected output.
Third-Party Libraries: If utilizing third-party libraries like Material UI, there's no need to test them, as they are presumed to be well-tested.

In react unit testing , there's a conventional test block structure that is followed, which is :

Create a test block using either describe-it/test.
Inside the test block, the first thing we do is to render the component that we want to test.
Select the elements that we want to interact with queries.
Interact with those elements.
Assert that the results are as expected.

How To Setup Our Project

First create the react app with the create-react-app command. Since we'll be using Jest , its already pre-installed in your app.

npx create-react-app react-test-project

Ensure the following line is in the setupTests.js file:

import '@testing-library/jest-dom'

How To Write Our First Test ?

Step 1: Create a component

Let’s create a component called Counter, that renders "Counting App".

import React, { useState } from "react";

const Counter = () => {

    return (
        <div>
            <p>Counting App</p>
        </div>
    );
};

export default Counter;

Here, we just need to test if the Counter renders "Counting App". Now, where should we write the tests? We can write them inside files with .js suffix in “__ tests __” folders or files with “.test.js” suffix or files with “.spec.js” suffix anywhere inside our src folder and jest will pick it up.

Create a “counter.test.js” file inside the src folder and add the following code:

import Counter from "./counter";
import { render, screen } from "@testing-library/react";


describe("Counter Component", ()=> {
    it("should render counter component", ()=>{
        render(<Counter />)
        expect(screen.getByText(/counting app/i)).toBeInTheDocument()
    })
})

Note: In order to let jest know about this test file, it’s important to use the extension .test.js.

The above test can be described as follows:

The “describe” block is employed to group together a set of tests under the overarching category of "Counter Component."
The “it” block is used to define individual tests within the describe block. Alternatively, the “test” block can also be used for the same purpose. Both methods take two parameters:
The first parameter names the test, such as "Render Counter Component."
The second parameter is a callback function, outlining the specifics of the actual test.
The render() method from the React Testing Library is utilized in the test to render the Counter component within a virtual DOM.
The screen property, offered by the React Testing Library, facilitates the selection of elements for testing based on the previously assigned test IDs.
The expect property is used to make assertions, comparing the actual results with the expected results.

With these foundational concepts in place, the testing process covers the basic rendering aspects. The subsequent step involves implementing counting functionality in the Counter component.

import React, { useState } from "react";

const Counter = () => {
    const [countValue, setCountValue] = useState(0);

    const increaseCount = () => {
        setCountValue((prevCount) => prevCount + 1);
    };

    const decreaseCount = () => {
        setCountValue((prevCount) => prevCount - 1);
    };

    return (
        <div>
            <h2>Counting App</h2>
            <button 
                data-testid="increase" 
                aria-label="Increase Count"
                onClick={increaseCount}
            >
                +
            </button>
            <p data-testid="count">{countValue}</p>
            <button  
                data-testid="decrease" 
                aria-label="Decrease Count"
                onClick={decreaseCount}
            >
                -
            </button>
        </div>
    );
};

export default Counter;

This component that simply increases and decreases a numeric value at the click of respective buttons. Now our updated test file should look like this:

import Counter from "./counter";
import { fireEvent, render, screen } from "@testing-library/react";

describe("Counter Component", () => {
    it("should render counter component", () => {
        render(<Counter />)
        expect(screen.getByText(/counting app/i)).toBeInTheDocument()
    })

    it("should increment counter when increment btn is clicked", () => {
        // render the component on virtual dom
        render(<Counter />);

        //select the elements you want to interact with
        const counter = screen.getByTestId("count");
        //expect counter to initialize at 0.
        expect(counter).toHaveTextContent("0");
        //select increment btn
        const incrementBtn = screen.getByTestId("increase");

        //interact with those elements
        fireEvent.click(incrementBtn);

        //assert the expected result
        expect(counter).toHaveTextContent("1");
    })
})

In the second test block, we are evaluating the rendering and increment functionality of the counter component. Here's a breakdown of the test:

Render the counter on the virtual DOM.
Utilize the screen property to select elements.
Set an expectation assertion to check if the counter initializes at 0.
Use the fireEvent function to simulate a click on the increment button.
The test asserts that the counter's text content changes and updates as expected.

Now after running the test, the result obtained can be seen below:

 PASS  src/counter/counter.test.js
  Counter Component
    √ should render counter component (39 ms)
    √ should increment counter when increment btn is clicked (22 ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        4.188 s
Ran all test suites matching /counter/i.

The assertions confirm that the Counter component not only renders as anticipated but also functions correctly when incrementing. I trust these tests have provided a foundational understanding of exploring basic rendering and interactive features within a React component using the React Testing Library. However, this marks just the initial phase of our testing journey ,as you continue your journey into the world of testing, the next step involves exploring more advanced techniques. My upcoming article Mocking Axios GET Requests, will dive deeper into the critical aspects of mocking and asynchronous testing. Make sure to follow along for a comprehensive understanding of these advanced testing concepts.

Stay focused, and happy testing!

References

A Go Drawback Lesson: Exploring OOP in GoLang in greater depth.

Iheanacho Ebere — Mon, 09 Jan 2023 23:15:53 +0000

My quest to study Golang began in an alt-school Africa. They provided an exam to gauge how well we understood the essential OOP concept of Golang through a number of lectures and instructions. We were asked to offer a solution to the inventory systems using the OOP paradigm; the significance of an inventory cannot be overstated. This is as a result of its many advantages and social significance.

In this article, I'd be discussing OOP in Goland and how I was able to provide some solutions to the inventory system.

Prerequisites
In order to follow through this article:

You need to have a basic understanding of programming.
You need to have a basic understanding of Go programming concepts such as variables, data types, structures, maps, interfaces and packages.

The Assessment question:

John has just opened up his car selling shop, to sell different cars. He gets the cars he needs to sell from different people and they all bring it to him.
He needs to manage the list of cars he has, attach a price to them, and put them on display to be sold, basically John needs an inventory to manage cars & to manage sales. For instance,

He needs to see the number of cars that are left to be sold
He needs to see the sum of the prices of the cars left
He needs to see the number of cars he has sold
He needs to see the sum total of the prices of cars he has sold
He needs to see a list of orders for the sales he made
Using the knowledge of OOP in Go, Build simple classes for the following “objects”:

Car
Product
Store
The Car class can have any car attributes you can think of.

The Product class should have attributes of a product i.e (the product, quantity of the product in stock, price of the product). A car is a product of the store, but there can be other products so the attribute of the car can be promoted to the Product. The Product class should have methods to display a product, and a method to display the status of a product if it is still in stock or not.

The Store class should have attributes like

Number of products in the store that are still up for sale
Adding an Item to the store
Listing all product items in the store
Sell an item
Show a list of sold items and the total price

This assessment made me realize how unprepared I was for the most fundamental and crucial core notion of GoLang as well as programming in general,known as OOP(Object-Oriented Programming).

What is OOP?
I think of OOP as a programming architecture that is heavily based on the ideas of classes and objects. This grants us flexibilty of creating reusable pieces of code blueprints (usually called classes), which are used to create individual instances of objects. We can easily recognize some classes using this insight and the data from the assessment, such as:

Car: Represents a specific car in the store which is also product, this means that it has all the attributes and methods of the Product struct.

Product: Represents a product in the store including cars called Embedding, this means the cars class also its inherits attributes from Product Class.

Initial Implementation

type Car struct {
    name   string
    engine string
    model  string
}

type Product struct {
    Car
    Name     string
    quantity int
    price    float32
}

Store: Represents a store that sells product, including cars. Has a list of products in stock and a list of sold products.

package store

import (
    "Auto-shop/products"
    "fmt"
)

type Store struct {
    name         string
    productStore []products.Product
    soldProducts []products.Product
}

It is undeniable that Go is not an object-oriented programming language. Can we, however, use go language features to adhere to the principles of object-oriented methodologies? Yes.

However, the key idea behind object-orientation is to separate the code into several manageable parts or objects. Each object has its own identity that is determined by the data (attributes) and the methods (behavior) that operate on the data. The attributes are typically hidden and can only be accessed through the methods defined within the object. This is called encapsulation.

This led us to construct a receiver function(methods) for our classes.

Product class methods:


func (p *Product) Display() string {
    return p.Name
}

func (p *Product) Quantity() int {
    return p.quantity
}

func (p *Product) Status() bool {
    if p.quantity <= 0 {
        fmt.Println("Product Out of Stock")
        return false
    }
    fmt.Printf("Quantity of Prduct in Stock: %v", p.quantity)
    return true
}

func (p *Product) Sell(quantity int) error {
    if p.quantity < quantity {
        return errors.New("not enough products to sell")
    }

    p.quantity = p.quantity - quantity

    return nil
}

func (p *Product) Price() int {
    return p.price
}

Store class methods:

func (s *Store) AddProduct(p products.Product) {
    s.productStore = append(s.productStore, p)
}

func (s *Store) ListItemsCount() int {
    fmt.Printf("list items count: %+v \n\n", s.productStore)
    var count int
    for _, v := range s.productStore {
        count += v.Quantity()
    }
    return count
}

func (s *Store) ListItems() {
    if len(s.productStore) > 0 {
        for _, v := range s.productStore {
            fmt.Printf("list items: %+v \n\n", v.Display())
        }
    } else {
        fmt.Println("No products in the store atm.")
    }
}

func (s *Store) ItemsTotalPrice() int {
    fmt.Printf("items total price:%+v \n\n", s.productStore)
    var price int
    for _, v := range s.productStore {
        price += v.Quantity() * v.Price()
    }
    return price
}

func (s *Store) SellItems(productName string, quantity int) {
    var product products.Product

    for _, v := range s.productStore {
        if v.Name == productName {
            product = v
            if quantity <= v.Quantity() {
                product.Sell(quantity)
                s.soldProducts = append(s.soldProducts, product)
                fmt.Printf("You just sold %d amount of %s. /n The remaining %s in the store is %d", quantity, productName, productName, v.Quantity())
            } else {
                fmt.Printf("Insufficient Product in stock")
            }

        } else {
            fmt.Printf("%s is not in store", productName)
        }
    }
}

func (s *Store) ShowSoldItemsCount() {
    var sumNumberSold int
    for _, v := range s.soldProducts {
        sumNumberSold += v.Quantity()
    }
    fmt.Printf("total number of items sold: %v /n", sumNumberSold)
}

func (s *Store) ShowSoldItems() {
    fmt.Printf("sold items: %+v \n\n", s.soldProducts)
}

func (s *Store) ShowSoldItemsPrice() {
    var sumAmountSold int
    for _, v := range s.soldProducts {
        sumAmountSold += v.Price() * v.Quantity()
    }
    fmt.Printf("total sold items price: %v \n\n", sumAmountSold)
}

Final Implementation

Thus, after delving deeper into the vast world of GoLang and attempting to comprehend more advanced concepts. I discovered that I had already broken the encapsulation rule in previous projects, which prompted me to completely refactor my code.

Unlike Java or C++, where we have private or public to restrict the accessibility of attributes, Go has no such features. Instead, what it provides is a means for package-level accessibility i.e attributes starting with uppercase can be accessed directly outside the package when the object is created. Note how all my previous attributes started with Uppercase which is wrong and a rookie mistake!.

This helped me understand one of the true applications of interfaces. Interfaces also introduces a new concept in Go known as polymorphism. It provides the ability to write code through the implementation of types that can take on different behavior at runtime. In Go, polymorphism is achieved through interfaces and interfaces only.

var _ Product = &product{}

type Product interface {
    Quantity() int
    Price() float32
    Name() string

    Sell(quantity int) error
    Display()
    Status() bool
}

type car struct {
    name  string
    color string
}

type product struct {
    car
    productName string
    quantity    int
    price       float32
}

The code above provides us with some sense of encapsulation, granting limited access to the attributes through interface. I also implemented this same concept on the store class while using product interface from the product package.

package store

import (
    "backendexam-project/product"
    "errors"
    "fmt"
)


type Store interface {
    AddItem(item product.Product)
}

type store struct {
    name      string
    Products  []product.Product //list of products
    SoldItems []product.Product
}

Overall, the implementation of the Car, Product, and Store classes in Go using object-oriented programming principles allows us to manage the inventory and sales of a car and other product store efficiently. The initial implementation had some encapsulation and abstraction concerns with all of the data/attributes that were exposed. These issues were resolved by implementing interfaces efficiently.

GitHub Url: https://github.com/manlikeNacho/Auto-shop.git

In conclusion, the process of modifying the code to enhance its design after completing the second-semester exam question at AltSchool Africa has allowed us to better grasp OOP in Go and put best practices for creating scalable and maintainable systems into practice. Through this technical essay, we want to share what we've learned while also serving as a helpful resource for anyone else working through a similar issue.

Resources
The resources below might be helpful

The Omega

Iheanacho Ebere — Mon, 09 Jan 2023 18:48:54 +0000

My first post on Dev.to