Forem: Richard Igbiriki

Building Consistent RESTful APIs

Richard Igbiriki — Tue, 14 Apr 2020 00:29:38 +0000

When it comes to building RESTful APIs, the applications are limitless while the standards and/or best practices remain the same across different stacks. This is an attempt to portray some of those standards and best practices (highly opinionated).

Authorization

Representational State Transfer (REST) effectively invalidates sessions and as such, our applications require another way of authorizing users trying to access it. One of the most commonly used tools for authorization is JSON Web Tokens-JWT. Once a user logs in or signs up to our application, a token is assigned to that user for a period of time (the length depends largely on the security concerns of your application). A good practice is to add a unique identifier to the token so each request to our application can serve the particular user making that request without asking for extra parameters from the user.

For example, if I am logged in using JWT, and I attempt to retrieve all transactions I have made on the application, the application should be able to provide ONLY my transactions based on my JWT authorization token.

Without going into implementation details, one can achieve this by having a service intercept incoming requests, process the JWT token and set a current_user object or variable accessible throughout the application.

Resources, Actions, and HTTP Methods

In REST we have resources, which can represent database tables, e.g companies, users, posts, messages, etc. Every resource has a list of actions that can be performed on it. These actions are determined by the HTTP method on each request to that resource. HTTP Methods are also referred to as HTTP VERBS because they perform/determine actions. Given a resource, transactions, below are some of the most common corresponding HTTP Methods and actions.

GET - /transactions (get all transactions)
GET - /transactions/:id (get a single transaction)
POST - /transactions (create a new transaction)
PATCH - /transactions/:id (update parts of a transaction)
PUT - /transactions/:id (update a transaction)
DELETE - /transactions/:id (delete a transaction)

Depending on the scale of your application, you may need to extend the actions available on your resource by custom endpoints. Custom endpoints can either affect the entire resource (collection) or a member of the resource. For actions affecting the collection, it is as follows:

GET - /transactions/users (get all users that have made transactions)
GET - /transactions/failed (get all failed transactions)

For a member, assuming we have a separate but related resource for a transaction details:

GET - /transactions/:id/details (get the details of a transaction)
POST -/transactions/:id/details (create details for a transaction)
PUT -/transactions/:id/details (update the details of a transaction).

HTTP Response Status

The response and status returned from every request depending on the action being performed and the status of the action. A POST request should never return a 204 (No Content) and a DELETE request should never return 201 (Created). Below are the most common responses based on their request and status.

200 - OK

The request was completed. You can't go wrong with a 200 status if the action requested for was completed successfully however, there might be more appropriate status messages depending on the action.

201 - Created

Ideally, this should be returned whenever a new object is created (mostly with a POST request) alongside the object that was created. Returning the object that was created is a personal preference as it grants access to the newly created object immediately.

204 - No Content

This can and should be returned after a DELETE has been completed on an object.

401 - Unauthorized

This is appropriate when a user tries an action that requires authorization but the request doesn't possess that authorization.

404 - Not Found

Highly unlikely but if a user requests for a resource that doesn't exist, 404 is the appropriate status to respond with. Albeit based on your use case, returning 200 - ok and an empty result may be more appropriate.

Refactoring React Components for Testability with Jest and Enzyme

Richard Igbiriki — Sun, 22 Sep 2019 10:55:15 +0000

Disclaimer

I cannot affirm or deny that this post is a continuation of my previous post: Testing Your First React Component with Jest and Enzyme, but if this is your first read on testing react components, I do politely suggest you see that one first.

Introduction

Testing your react components is a thrilling exercise (in my experience), however, it can take a swift turn if your components are large and rippled with state. Consequently, it is considered a good (perhaps best?) practice to split components into smaller independent components...preferably pure components. Using pure components prevents unnecessary side effects that can occur in the component lifecycle methods. In this post, we will walk through splitting a component into smaller pure components and writing tests for those components.

Let's get started.

Our Component

Observations

In this component, we can see that we have a box for each program. This is a testable unit and should be its own component. We also have a 'Programs' text and a 'Create New' button in the subheader, this can also be moved into its own component. Keeping in mind this possible splits, let's see what the initial implementation can look like. We will ONLY view the render method.

return (
const { loading, message, programs } = this.state;

<div loading={loading} message={message} programs={programs}  className="container jumbo-header">
        <div className="jumbo-box">
            <div className="jumbo">
            <p id="title" className="ml-3 text">Programs</p>
            </div>
         </div>

        {/* show message if there is a status mesage */}
        {message && <div className='text-center'>
            <h5 id="message" className='text-info'> {message} </h5>
        </div>}

        {/* If fetching programs, show loading spinner */}
        {loading && <Spinner animation="grow" variant="info" />}

        <Container className="mt-3">
            <div className="admin-button" style={{height:'3rem'}}>
                <Link id="new-link" to='/programs/new'>
                    <Button id='new-button' className="create float-right">Create New</Button>
                </Link>
            </div>

            {/* return all programs as Card items if they exist */}
            { programs && programs.map((data, i) =>
                <Card data={data} key={data.id} className="pro-box ml-5 shadow p-2 mt-4 rounded float-left" border="light" style={{width: '30rem'}}>
                   <h4 id="title" className="text-center mt-2">{data.title}</h4>
                   <div className="pro-text d-flex pt-5 text-center">
                      <p id="length" className="ml-5 text-center">Duration: {data.length}</p>
                      <p id="instructor" className="ml-5">Instructor: {data.instructor}</p>
                  </div>
                      <p className="pro-anchor text-center pt-4">VIEW</p>
                </Card>
            )}
        </Container>
    </div>

)

Here, we have a CORRECT but large single implementation of the UI we were given. However, this implementation makes testing the programs Card, for instance, a tidbit more difficult. If you can somehow circumvent that difficulty, testing the component as it is will result in unnecessary side effects, as I earlier mentioned.

Following our initial observation, let us split this render method into simpler pure components.

Main Component

Our main component above will be refactored to return a secondary component as shown:

render() {
        //Programs component is more easily testable as a pure function
        const { programs, message, loading } = this.state;
        return(
            <ProgramsComponent programs={programs} message={message} loading={loading} />
        )
    }

Moving on...

Programs Component

Our programs component will render the subheader, the spinner, and a message if any. It will also attempt to render a separate Item component that represents a program for every available program.

const ProgramsComponent = ({ programs, message, loading }) => (

    <div loading={loading} message={message} programs={programs}  className="container jumbo-header">
        <div className="jumbo-box">
            <div className="jumbo">
            <p id="title" className="ml-3 text">Programs</p>
            </div>
         </div>

        {message && <div className='text-center'><h5 id="message" className='text-info'> {message} </h5></div>}

        {loading && <Spinner animation="grow" variant="info" />}

        <Container className="mt-3">
            <div className="admin-button" style={{height:'3rem'}}>
                <Link id="new-link" to='/programs/new'>
                    <Button id='new-button' className="create float-right">Create New</Button>
                </Link>
            </div>

             {/* Move program details to another component */}
            { programs && programs.map((data, i) =>
                <Item key={data._id} data={data} />
            )}

        </Container>
    </div>
);

Moving on to our final component...

Item Component

Our item component will only be responsible for rendering a program. This enables us to test this component as a unit (re: unit testing). Did I just explain unit testing as a side effect of this post? Interesting!

Here is our Item component.

const Item = ({ data }) => (
    <Card data={data} key={data.id} className="pro-box ml-5 shadow p-2 mt-4 rounded float-left" border="light" style={{width: '30rem'}}>
        <h4 id="title" className="text-center mt-2">{data.title}</h4>
        <div className="pro-text d-flex pt-5 text-center">
        <p id="length" className="ml-5 text-center">Duration: {data.length}</p>
        <p id="instructor" className="ml-5">Instructor: {data.instructor}</p>
        </div>
        <p className="pro-anchor text-center pt-4">VIEW</p>
    </Card>
);

We have successfully divided out large component into two smaller pure components that can be tested individually. For the sake of brevity (this is already getting too long), we will be drastically limiting our test coverage in this post.

Testing Our Components

Our unit tests can be divided into at least three stages.

When the component is fetching programs. Loading stage.
When the component has finished loading but has no content. Empty stage.
When the component has finished loading, has no message, but has content. This can be further split to testing scenarios of one item or multiple items.
Tests for our Item component.

Yeah, I know, this may already sound like so much work. Doh. However, we did agree to keep it short and simple so below are the tests for the different stages.

Stage 1 and 2: Loadin and Empty Content

   describe('tests general requirements and an loading component', () => {

             //Start with an empty loading component
             const wrapper = shallow(<ProgramsComponent loading={true} message={null} programs={[]} />);

            describe('tests general component requirements', () => {

                it('should have page title', ()=> {
                    expect(wrapper.find('#title')).toHaveLength(1);
                    expect(wrapper.find('#title').text()).toEqual('Programs');
                });

                //...More tests for button and Link

            });

            describe('tests empty program', () => {
                it('should be loading', () => {
                    expect(wrapper.props().loading).toEqual(true);
                });

                it('should have a spinner', () => {
                    expect(wrapper.find('Spinner')).toHaveLength(1);
                });

                it('should not have Item', () => {
                    expect(wrapper.props().programs.length).toEqual(0);
                    expect(wrapper.find('Item')).toHaveLength(0);
                });

               //...Test for no message

            });

        });

Stage 3: Available Content

       describe('tests component with multiple programs', () => {
            const programs=[
                {
                    _id:1,
                    title: 'Web Development',
                    length: '3 Months',
                    instructor: 'Richard Igbiriki'
                },
                {
                    _id:2,
                    title: 'Mobile Development',
                    length: '3 Months',
                    instructor: 'Richard Igbiriki'
                },
                {
                    _id:3,
                    title: 'Software Development',
                    length: '3 Months',
                    instructor: 'Richard Igbiriki'
                }
            ];
            const wrapper = shallow(<ProgramsComponent loading={false} message={null} programs={programs} />);

            it('should have three Items', () => {
                expect(wrapper.find('Item')).toHaveLength(3);
            });

            it('should update items on props update', () => {
                //remove one item
                const i = programs.pop();
                wrapper.setProps({ programs });
                expect(wrapper.find('Item')).toHaveLength(2);
                //add item
                programs.push(i);
                wrapper.setProps({ programs });
                expect(wrapper.find('Item')).toHaveLength(3);
            });
            //...More tests
        });

Stage 4: Item Component

    describe('Tests Item component', () => {
        const data = {
            _id:1,
            title: 'Web Development',
            length: '3 Months',
            instructor: 'Richard Igbiriki'
        }
        const wrapper = shallow(<Item data={data} />);

        it('should have data props', () => {
            expect(wrapper.props().data).toBeDefined();
        });

        it('should have a title', () => {
            expect(wrapper.find('#title')).toHaveLength(1);
            expect(wrapper.find('#title').text()).toEqual(data.title);
        });

        it('should have a length', () => {
            expect(wrapper.find('#length')).toHaveLength(1);
            expect(wrapper.find('#length').text()).toEqual('Duration: '+data.length);
        });

        it('should have an instructor', () => {
            expect(wrapper.find('#instructor')).toHaveLength(1);
            expect(wrapper.find('#instructor').text()).toEqual('Instructor: '+data.instructor);
        });
    });

Explanation: Testing Matchers

In all our tests, we used between 3 to 5 Matchers and 2 to 3 methods on expect for comparison.

Matchers

.find: takes a selector and finds matching nodes.
.props gets the props set on the node.
.setProps updates the props on the node.
.text returns the text on the current node.

Explanation: `expect` methods

.toHaveLength(n) expects the returned value to have an element of length or size n.
.toEqual(variable) expects the returned value to be equal to variable.

Conclusion

Yay!!! We are done.

This was longer than I anticipated but once again, I hope it was as fun for you reading and trying as it was for me writing it.

For those that do not follow me on Twitter, these posts contain active projects that I and my team are currently working on that is why I do not have links to any github repo. I will continue to write as the need arises.

Thank you.

Testing your first React Component with Jest and Enzyme

Richard Igbiriki — Sat, 21 Sep 2019 13:08:53 +0000

Introduction

If you've spent three months writing code in recent times then you must have come across the concept of 'testing' or 'test-driven development' (TDD). It is considered a best practice to test your code to ensure that it works as you expect it to work under any circumstance. In my experience, testing, for a lack of a better word, 'forces' us to code better (think readability, scalability).

Writing testable code is a skill in itself. Unit testing, for instance, requires splitting React components into smaller (preferably, pure components) components.

Testing Environment Setup

create-react-app sets up React with jest as the default testing library. To enable us to test react components, we need to add enzyme to our project's development dependencies.

yarn add enzyme enzyme-adapter-react-16 --dev OR npm install enzyme enzyme-adapter-react-16 --save-dev

Add setupTests.js to your src directory. Add the setup code below to it.

// /src/setupTests.js

import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

Jest automatically finds test files that have the suffix *.test.js or *.spec.js. Another option is to place all test code into a _tests_ folder. Jest will find and run all test files regardless of relative directory position to src.

Syntax

As I like to put it, tests are just conditionals. True OR False. A binary comparison between an actual and expected value. For instance, we expect 1 to equal 1. Or we expect 1 + 1 to equal 2. This is precisely how we test our components. By comparing an expected outcome to the actual outcome.

Using jest we:

expect(actual).toEqual(expected);

expect(actual).not.toEqual(expected);

Enzyme provides a list of Matchers and Jest provides methods of comparisons for expect

Testing Our Component

Below is the component we will be testing

We will keep our tests for this component simple...for brevity (or so I claim).

For this component, I want to test:

Presence of input with email id
Presence of input with password id
Presence of an avatar icon using the avatar class.
Presence of a button with 'Login' text.
The validation function that ensures email and password is not empty.

Let's get started!

Tests

Here is our Login.test.js

import React from 'react';
import { shallow } from 'enzyme';
import Login from './Pages/LogIn';
import { validateEmailAndPasswordPresence } from '../extra/validations';
    describe('Login component tests', ()=> {
        const wrapper = shallow(<Login />);

        it('should have a btn component', ()=> {

            //There should be only one button
            expect(wrapper.find('Button')).toHaveLength(1);

            //Button should be of type button
            expect(wrapper.find('Button')
            .type().defaultProps.type)
            .toEqual('button');

            //Button should have matching text
            expect(wrapper.find('Button').text()).toEqual('LOGIN');
        });

        it('should have input for email and password', ()=> {
            //Email and password input field should be present
            expect(wrapper.find('input#email')).toHaveLength(1);
            expect(wrapper.find('input#password')).toHaveLength(1);
        });


        it('should an avatar', ()=> {
            //Avatar should be present
            expect(wrapper.find('.avatar')).toHaveLength(1);
        });

        it('should have an empty email and password state var', ()=> {
            //Optionally test to check if password and email are empty strings on 
               setup
            expect(wrapper.state('email')).toEqual('');
            expect(wrapper.state('password')).toEqual('');
        });

        it('should test email and password presence', () => {

             //should return true 
             expect(validateEmailAndPasswordPresence('email@email.com', 
             'password').toEqual(true);

             //should return false
              expect(validateEmailAndPasswordPresence('', 
             '').toEqual(false);
        });

    });

Note: The button tested here is the button component from react-bootstrap. Replace with your own button component.

Explanation

describe is used to describe what we are about to test. It is a wrapper function for tests concerning a particular component.
it describes a particular test. I use it as a should (comparison). So it should have an avatar. Or it should be true if email and password present.

To run your test, use

npm test or yarn test

in your project directory. All tests should fail. Yes!!! The joy of TDD.

Login Component


import React, {Component} from 'react'
import {FaUserCircle} from 'react-icons/fa'
import {Form, Button} from 'react-bootstrap'
import { Redirect } from 'react-router-dom'

export default class Login extends Component {
    constructor() {
        super();
        this.state = {
            email: '',
            password: ''
        }
    }

    handleChange = (event) => {
        this.setState({[event.target.name]:event.target.value});
    }

    login = async () => {
        //login here
    }
    render () {
        return(
            <div className="container-fluid box mt-5">
                <div className="loginbox shadow p-5">
                    <FaUserCircle className="avatar" />
                     <Form className="p-2 mt-5">
                        <Form.Group className="mb-3">
                            <Form.Control id="email" type="text" name="email" onChange={this.handleChange} placeholder="Email/Username" className="text-center" />
                        </Form.Group>
                        <Form.Group className="mb-3 mt-4">
                            <Form.Control id="password" type="password" name="password" onChange={this.handleChange} placeholder="Password" className="text-center" />
                        </Form.Group>
                        <Form.Group className="Log-button">
                            <Button onClick={this.login} className="btn" style={{width: '10rem'}}>LOGIN</Button>
                        </Form.Group>

                    </Form>
                </div>
                </div>
        )
    }
}

After installing all the dependencies using yarn' ornpm`, rerun your tests and they should all PASS.

Disclaimer: There are more tests in the image above than covered here.

Conclusion

Test-Driven Development (TDD), Behaviour-Driven Development (BDD), Poverty-Driven Development (PDD), CLI-Drive Development (CDD), and whatever else exists all lead to one thing, a product. What matters is that we follow patterns and use best practices that suit our current development circle.

I have been coding for a couple of years and just started writing tests, although I do wish I started earlier. If you do not think TDD is worth it, give it a few more days or months or years, see you when you finally decide.

Forem: Richard Igbiriki

Building Consistent RESTful APIs

Authorization

Resources, Actions, and HTTP Methods

HTTP Response Status

200 - OK

201 - Created

204 - No Content

401 - Unauthorized

404 - Not Found

Refactoring React Components for Testability with Jest and Enzyme

Disclaimer

Introduction

Our Component

Observations

Main Component

Programs Component

Item Component

Testing Our Components

Stage 1 and 2: Loadin and Empty Content

Stage 3: Available Content

Stage 4: Item Component

Explanation: Testing Matchers

Matchers

Explanation: expect methods

Conclusion

Testing your first React Component with Jest and Enzyme

Introduction

Testing Environment Setup

Syntax

Testing Our Component

Tests

Explanation

Login Component

Conclusion

Explanation: `expect` methods