Forem: miguel-penaloza

The What, Why and How of React (Testing with Hooks)

miguel-penaloza — Sun, 07 Jul 2019 16:52:12 +0000

This is the second part of a series of posts focused on testing a React app. If you want to check out the first one, where we discuss basic concepts, you can find it here.

Today, we're going to delve deeper into testing. I will explain how to test a React application, the best patterns for making tests, useful utilities, and some tips to make the TDD/BDD technique easier while you code your application to ensure your tests are more SOLID.

NOTES: In this post, I will replace Enzyme with 'React Testing Library,' which, in my humble opinion, is more restrictive than Enzyme but at the same time forces you to write better tests.

What else should I learn about testing?

In the previous post, we talked about what testing is, introduced basic concepts, and discussed some of the libraries we can use. However, that is just the tip of the iceberg. The culture of testing is not merely about learning acronyms and then applying them to your code; it is an integral part of development.

One thing that happened since my last post was the release of React v16.8. When they introduced the hooks concept into our lives, I saw many posts from people trying to explain why you should migrate to this new feature. They provided examples of how you can replace each internal lifecycle method (such as componentDidMount, etc.) with a hook (useEffect, useState, etc.). However, when I tried to find information on testing hooks, there wasn't much available.

In my projects, I try to migrate to the latest version of React so that I can use hooks, attracted by the promise of a more functional world where our React components simply receive data and actions. Their only responsibility is to trigger these actions and display the data, a concept I find very appealing.

When I first tried using a hook, I relied on my code and tests, trusting that my tests would identify failures when something broke. I expected my tests to fail if something was amiss during the migration from a Class component to a Component with hooks, yet my tests should not break. The UI should remain the same, the data received should be unchanged, and the same actions should be called; I'm merely shifting implementation details within my component.

In my team, we adhere to the rule of 'only create a Class React Component if you need it,' and this guideline works well for us. We only create Class Components when we need to handle state or manage lifecycle events (mount, update, or unmount). Otherwise, we use a function that returns the component, a common rule that I understand many people follow.

When I tried to migrate my first Class Component, it was easy because it only used state. I simply needed to replace the state of the Class Component with useState. My component looks like this: it's just a simple input that animates the title when you focus on the input. There's no business logic involved and nothing too complicated to handle.

export class Input extends Component {
    constructor(props){
        super(props);
        this.state = {
            focus: false
        };
    }
    render(){
        const { title, value, isFilter } = this.props;
        return(
            <div>
                {title && <LabelTitle value={value} isFocus={this.state.focus}>{title}</LabelTitle>}
                <InputForm 
                    onFocus={()=> this.setState({ focus: true })}
                    onBlur={()=> this.setState({ focus: false })}
                    {...this.props}
                />
                {isFilter && <IconInput><img src={iconEye} alt="icon-eye" /></IconInput> }
            </div>);

    }
}

Now that I've migrated my component, it looks like this:

export const Input = ({ title, value, isFilter, type, width, onChange }) => {
    const [focus, changeFocus] = useState(false);
    return (
        <div>
            {title && <LabelTitle value={value} isFocus={focus}>{title}</LabelTitle>}
            <InputForm
                onFocus={() => changeFocus(true)}
                onBlur={() => changeFocus(false)}
                type={type}
                width={width}
                onChange={onChange}
            />
            {isFilter && <IconInput><img src={iconEye} alt="icon-eye" /></IconInput>}
        </div>);
};

It's essentially the same component, with the same behavior but less code. However, my tests started to fail; all the unit tests related to the input behavior failed. When I tried to understand why, I realized that one of their assertions was verifying this:

expect(input.state('focus')).toBeFalsy();

I realized that I no longer have a .state method because it's no longer a class; it's just a component. Then, I also noticed that I had overused .update() and setProps() in my previous tests. My tests were fine when I wrote them, but now they are too closely tied to my implementation. If I try to migrate to the latest version of React, my tests will fail. This means that I need to refactor all my tests and my code to use hooks.

I was at a crossroads: I could leave the code as it is—it’s working, and no one is asking me to migrate to hooks. I don’t need to refactor everything just to use something new. However, I realized something more significant than just the need of the new hooks in my code; my tests were preventing me from writing good code. That’s why I chose to refactor everything to make the code great again.

Before thinking about refactoring, I needed to understand why my tests were so tightly coupled to the implementation details. I reviewed my tests repeatedly and found instances where I used mount and shallow from Enzyme to render components and then check their state and props. I also used setProps to simulate received data, which was acceptable at the time. However, now that React has evolved (while maintaining backward compatibility), I can't upgrade because my code is too intertwined with its tests.

After extensive research, I discovered a new library called React Testing Library. I found that this library offers fewer features than Enzyme; you cannot check states, props, or manipulate lifecycles. Instead, you can only render components once, pass props, find elements by testid, and wait for elements to be displayed. Check this out:

test('Fetch makes an API call and displays the greeting when load-greeting is clicked', async () => {
  // Arrange
  axiosMock.get.mockResolvedValueOnce({data: {greeting: 'hello there'}})
  const url = '/greeting'
  const {getByText, getByTestId, container, asFragment} = render(
    <Fetch url={url} />,
  )

  // Act
  fireEvent.click(getByText(/load greeting/i))

  // Let's wait until our mocked `get` request promise resolves and
  // the component calls setState and re-renders.
  // getByTestId throws an error if it cannot find an element with the given ID
  // and waitForElement will wait until the callback doesn't throw an error
  const greetingTextNode = await waitForElement(() =>
    getByTestId('greeting-text'),
  )

  // Assert
  expect(axiosMock.get).toHaveBeenCalledTimes(1)
  expect(axiosMock.get).toHaveBeenCalledWith(url)
  expect(getByTestId('greeting-text')).toHaveTextContent('hello there')
  expect(getByTestId('ok-button')).toHaveAttribute('disabled')
  // snapshots work great with regular DOM nodes!
  expect(container.firstChild).toMatchSnapshot()
  // you can also get a `DocumentFragment`, which is useful if you want to compare nodes across renders
  expect(asFragment()).toMatchSnapshot()
})

In the example you have three clear separations, prepare your component, make the action and wait to assert(Given, When, Then), and that it is. The test don't use anything that a normal user can't see, and the utility only return you this:

const {getByText, getByTestId, container, asFragment} = render(
    <Fetch url={url} />,
  )

Within the rendered component, you can use functions like getByText and getByTestId to locate elements. The HTML DOM rendered is accessible via the container, and the asFragment function helps you create snapshots. You can find the full api here

NOTE: Today, I don't trust snapshots because they are hard to read, and most people, including myself, just use --update to fix problems. We're not machines capable of deciphering auto-generated code easily, so I don't see much value in what these snapshots produce. However, if you feel comfortable using them, feel free to do so.

As you can see, this library doesn't allow access to the implementation, unlike Enzyme, which does. I decided to migrate to this new library not because of the hooks; the main reason is that Enzyme allowed me to write incorrect tests. It's not Enzyme's fault; it was my mistake. I always say that libraries are just tools. The quality of the code depends entirely on the person who writes it, not on the language, framework, or library used.

Now, let's discuss another aspect of TDD: refactoring. Refactoring is a vital part of your job. You should refactor the code once you complete your development. Writing tests at the beginning helps you understand the requirements and ensures the code works as expected. Moreover, with reliable tests, you can be confident that your changes won't compromise the value your code provides. If your tests consistently pass (indicating 'green'), you're free to make improvements as needed. This is the beauty of good testing: it's not just about testing, but a safety net that protects my code from myself.

Why refactor is related to TDD?

Refactoring is a vital phase in development. It’s during the refactoring stage that you make your code do more than just meet the requirements. Here, you can enhance the architecture, make it easier to extend, clarify the responsibilities within the code, and upgrade to new libraries or functionalities that improve your code, as we saw with hooks. However, you need to thoroughly understand some rules before you begin refactoring:

A refactor should not alter the interface of your software. If you need to change the behavior of your code, create tests, make them fail, then adjust your code to make the tests pass, and only then should you proceed to refactor.
Never refactor anything that you don't understand. Often, we find ourselves dealing with "black-box" code, which no one fully understands. You might want to improve this code, but how can you be sure that everything will continue to work after your changes if you don't fully understand what it’s supposed to do in the first place?
Only refactor on green. Ensure that your changes are correct by never attempting to improve code when your tests indicate an error. The key here is to code in baby steps; a small amount of code is easier to manage during refactoring. If you use Git, you can employ techniques like fixup and autosquash to easily manage your changes and then squash them when you’re satisfied.
If you don't trust your tests, don't refactor your code. This is crucial: if your tests don’t provide the confidence you need, create the necessary tests before you begin refactoring.

How to really make a good test?

Now we're going to try a real-world exercise. We will continue addressing our challenge of migrating to hooks and adapting tests initially made with Enzyme.

We have a rule of trusting our tests, but I don't trust my current ones. Therefore, we are going to create new tests focused on DOM interaction rather than React instances.

This post will describe creating tests for an old dummy project called Brastlewark. This app is a simple CRA application that fetches a list of gnomes and displays them on a dashboard. You can filter the gnomes, and when you click on one, you can view its details. The project uses Redux and Saga. Let's examine my first test, which validates that the dashboard displays no gnomes if no data is fetched.


describe("Dashboard", () => {
    let store;
    beforeEach(() => {
        const sagaMiddleware = createSagaMiddleware();
        store = createStore(rootReducer, applyMiddleware(sagaMiddleware));

        sagaMiddleware.run(function* fullSaga() {
            const rootWatcher = combineWatchers(rootSaga);
            const watchers = Object.keys(rootWatcher)
                .map(type => createActionWatcher(type, rootWatcher[type]));
            yield all(watchers);
        });
    });
    it("should render empty dashboard", () => {
        const { getByTestId } = render(
            <Provider store={store}>
                <Dashboard />
            </Provider>,
        );

        expect(getByTestId("empty-gnomes-container")).toBeDefined();
        expect(getByTestId("empty-gnomes-container").textContent).toEqual("No gnomes to display");
    });
});

NOTE: I added data attributes to my React components to simplify testing. To align with the new library I'm using, I'm employing data-testid to identify elements in the UI.

My test passed, but now you can see that my test depends on more implementation details than before. It now knows about Redux and Sagas, involves middleware and stores, and uses providers—it's not just rendering. However, this isn't entirely wrong because my tests depend on these elements, but they are external to the component I need to test. These are the minimal requirements needed to render; my components are connected with Redux and dispatch actions. With the React Testing Library, I just ensure to include the same basic elements that the real applications have.

My test now doesn't verify what's inside the component. I don’t test the current state or any internal props. Currently, I've inverted the order of dependencies in my tests.

Next, I should create a utility that provides these dependencies pre-loaded and ready for use in my tests to avoid duplication. I'm envisioning something like this:

const renderWithState = (Component, props = {}) => {
    const sagaMiddleware = createSagaMiddleware();
    const store = createStore(rootReducer, applyMiddleware(sagaMiddleware));
    sagaMiddleware.run(function* fullSaga() {
        const rootWatcher = combineWatchers(rootSaga);
        const watchers = Object.keys(rootWatcher)
            .map(type => createActionWatcher(type, rootWatcher[type]));
        yield all(watchers);
    });
    const renderedOptions = render(
        <Provider store={store}>
            <Component {...props} />
        </Provider>,
    );
    return renderedOptions;
}

describe("Dashboard", () => {
    afterEach(cleanup);

    it("should render empty dashboard", () => {
        const { getByTestId } = renderWithState(Dashboard);

        expect(getByTestId("empty-gnomes-container")).toBeDefined();
        expect(getByTestId("empty-gnomes-container").textContent).toEqual("No gnomes to display");
    });
});

Now, you can see that the responsibility of creating the store with Redux and its sagas lies with the renderWithState function, which I can extract to another file, such as a test-utility. My test now looks simpler: I provide the entire environment to the component I want to test and no longer need to worry about implementation details.

My app currently only implements Redux and Saga, but the renderWithState function can be expanded to start anything you need. You should include all your base startup logic there, such as Context Providers (i.e., i18n, Styled Components, custom HOCs, React Router), Portals, and everything else our application requires.

The real key here is defining the limitations or boundaries of your test. As you can see, my tests are not unit tests; they validate business requirements, aligning more closely with what BDD expects from our tests. However, you can use this approach with TDD. The important thing for us is that our tests become fast, easy to write, and easy to understand. Keeping that in mind is crucial because a test that is easy to understand is more valuable than hundreds of pages of documentation.

But well, we now need to test more aspects. How can we pass values to the component? The code dispatches a Redux action, listens for our saga, and then calls the endpoint to retrieve information. So, what we need to do now is establish the 'yellow line'—the point where our test stops.

For this test, the limit will be the endpoint call. We're going to get there and mock the fetch; the rest of the application should be tested under real conditions, calling actual actions and functioning like our real environment.

One thing we're going to do is create a new API that will retrieve important information for our test. This information will include the actions dispatched. I don't want my test to be using or implementing Redux directly. To avoid testing with implementation details, I will create a Store Utils API, just like this:

class StoreUtil {
    actions = [];

    clearActions = () => {
        this.actions = []
    }

    pushAction = (action) => {
        this.actions.push(action);
    }

    getActions = () => {
        return this.actions;
    };

    getAction = (action) => {
        return new Promise(resolve => {
            let actionFound;
            while (!actionFound) {
                actionFound = this.actions.find(({ type }) => type === action);
            }
            resolve(actionFound)
        })
    }
}

This class is very simple, we have these actions, an we can:

Get all actions called.
Get one specific action.
Push one action to the registry.
Delete all actions.

The getAction is a promise because the action dispatch process is asynchronous. When we render our app, all the Redux magic operates under the hood, and the components are only updated when the reducers alter their previous state. Without the promise and the while, we would miss the actions that take longer than the first render.

NOTE: The Promise will wait indefinitely for the element to be displayed. If the component is never rendered, the Jest timeout will stop the test and result in a failure. You can improve this code to make it work better, but it suits the purposes of this post perfectly, so I will leave it as is. Feel free to adapt it to meet your needs.

I have also created a new middleware that will listen to each action called and push each one to the StoreUtil. Now, our renderWithState includes that middleware and returns the StoreUtil along with the rest of the rendered options.

const loggerMiddleware = (storeUtil) => store => next => action => {
    storeUtil.pushAction(action);
    next(action);
};

export const renderWithState = (Component, props = {}) => {
    const storeUtil = new StoreUtil();
    storeUtil.clearActions();
    const sagaMiddleware = createSagaMiddleware();
    const store = createStore(rootReducer, applyMiddleware(loggerMiddleware(storeUtil), sagaMiddleware));
    sagaMiddleware.run(function* fullSaga() {
        const rootWatcher = combineWatchers(rootSaga);
        const watchers = Object.keys(rootWatcher)
            .map(type => createActionWatcher(type, rootWatcher[type]));
        yield all(watchers);
    });
    const renderedOptions = render(
        <Provider store={store}>
            <Component {...props} />
        </Provider>,
    );
    return { ...renderedOptions, storeUtil };
}

NOTE: If you feel lost with the middleware, redux and saga terms, check these post that explain it very good the basic and the complex.

And now in our test, we can verify that one action was called:

it("should dispatch the fetchGnomes Action", async () => {
        const { storeUtil } = renderWithState(Dashboard);

        const fetchGnomesAction = await storeUtil.getAction("FETCH_GNOMES");

        expect(fetchGnomesAction).toEqual({ "payload": { "params": {} }, "type": "FETCH_GNOMES" });
    });

The last assert of our test compare the action redux object, and this looks like an implementation detail for me, what we can do is replace this assert to check if the payload is called with the correct information, like this:

  it("should dispatch the fetchGnomes Action", async () => {
        const { storeUtil } = renderWithState(Dashboard);

        const fetchGnomesAction = await storeUtil.getAction("FETCH_GNOMES");

        expect(fetchGnomesAction.payload).toEqual({ "params": {} });
    });

Right now, our test knows less about internal actions and models and simply verifies the parameters used to call the endpoint. This means that our test is verifying the code interfaces, which adds value by making the test easier to extend and understand.

The next part of our test verifies the boundaries and our interfaces. What I need now is to retrieve information, so I need to mock the fetch API call to get what I want. I'm using the JavaScript Fetch native API, and obviously, I don't want my test to be concerned with that. I always want to obscure the specifics of what I'm using from my test because I could switch to Axios, Request, or any other library. My test should handle the mocks without knowing which dependency I use. To achieve this, I have created a wrapper called fetchApi that will make the call to the resource. This function is the only one that knows what I'm using to make my REST request:

export const fetchApi = (url, {
    method = 'GET',
    params,
    cache= 'no-cache',
    headers = {
        'content-type': 'application/json'
    },
    data
}) => {
    let paramText = queryString.stringify(params);
    paramText = paramText ? `?${paramText}` : '';

    return fetch(`${url}${paramText}`, {
        body: JSON.stringify(data),
        cache,
        headers,
        method, // *GET, POST, PUT, DELETE, etc.
    }).then(response => {
        return response.json();
    }).catch(error => { 
        return { error }; 
    });
};

I'm going to create a new fectApi test util to be able to mock this and to set mocked answers to my tests.

export class FetchUtilsMock {
    mockedFetch;
    constructor(fetchApi) {
        this.mockedFetch = fetchApi.mockReset();
    }

    setResponse = (payload) => {
        this.mockedFetch.mockReturnValue(payload)
    }
}

Is a simple function that will store the mock, and then we can mock the responses that we want, the constructor reset the mock to avoid problems among tests, and you can call the set response method every time you need, the mockReturnValue is a function that the jest mocks allows implementing.

import fetchApi from '../../utils/api-utils';

jest.mock('../../utils/api-utils');

const emptyResponse = {
    "Brastlewark": []
}

describe("Dashboard", () => {
    let fetchUtil;

    afterEach(cleanup);

    beforeEach(() => {
        fetchUtil = new FetchUtilsMock(fetchApi);
    })

    it("should render empty dashboard", () => {
        fetchUtil.setResponse(emptyResponse);
        const { getByTestId } = renderWithState(Dashboard);

        expect(getByTestId("empty-gnomes-container")).toBeDefined();
        expect(getByTestId("empty-gnomes-container").textContent).toEqual("No gnomes to display");
    });

This's how the test looks now, I'm mocking my api-utils with jest.mock('../../utils/api-utils');, on the beforeEach, I instance the mock utility and then each test will define the response. I'm mocking right now an empty response, but we can mock multiple scenarios and responses, our test now allows us to test different possible (and real-live) responses to test our application.

You can mock any other integration that you have on your application like this, from a REST request, Databases, Redis, a Queue or whatever you need. The important here is to always wrap your integrations boundaries, to make it easy to test and develop, with this strategy you can change your dependencies without to refactor your entire application.

The next logical step is to mock a happy-path scenario, I will set the response with valid data and then validate that the gnomes are displayed, I will use a utility from react-testing-library called waitForElement, you also have others async-await dom related tools to make your test here, this will wait for the element to be displayed and return the component who has the data-testid="gnome-box-container"

const correctAnswer = {Brastlewark: [...]} // mock data with valid information

it("should dispatch the gnomes", async () => {
        fetchUtil.setResponse(correctAnswer);
        const { getByTestId } = renderWithState(Dashboard);

        const boxContainer = await waitForElement(() => getByTestId("gnome-box-container"));

        expect(boxContainer.children.length).toEqual(correctAnswer.Brastlewark.length);
    });

I will move the correctAnswer and the emptyAnswer constants to a file where I can isolate my mocked data, in that way if the model changes, I just need to update one file and all tests of my application should don't have the responsibility to create the data.

Always tests before refactor

As you can see, I'm just creating tests for my existing code, I'm writing tests to verify that my code works as I expected, and then I will move to the hooks. To my new tests, the details of which library I 'm using is not relevant, they only care about, display or not display something on the DOM, next we're going to tests interactions, clicking and submitting data, but before I will check my coverage, I use the same reporter that CRA3.0 gives me for jest, lets check it:

NOTE: To be able to use CRA coverage report I create a script on my package.json like this: "test:ci": "npm test -- --coverage --watchAll=false",

As you can see, my coverage is very low, but I'm sure that my tests are good, and at least the things that I test are working as I expected. The coverage is an indicator of different values; the branches are telling us that we have a lot of switches, if statements, for loops, etc., and we are not testing all the possible scenarios. Getting 100% coverage in most cases is not worth it. A good exercise for us as developers is to read these reports and verify if you really need those conditions to be tested. In some cases, you will find that the code is protecting you from a condition that's impossible to happen. Don't try to reach 100% just because it's the rule; try to cover the most realistic scenarios as you can, understand the cases, and then refactor or test them if you feel that you must.

Let's go with interactions

A UI is more than just display; we have interactions, but how can we test it? One common approach for me in the past was to use Enzyme to shallow render components, which looks something like this:

const wrapper = mount(<Stateful />);
const instance = wrapper.instance();

instance.clickButton(); // Internal method

expect(...).toEqual(...);

This gives me the coverage, and also allow me to test the button click, what's wrong with this approach? well, I'm using the clickButton method and my test is never really clicking anything, I was wrong to marry my test with internal methods because now I want to migrate to a functional component and this test doesn't support that, my test is blocking me to improve my code.

Another thing very common on my tests with enzyme is this:

const wrapper = mount(<Foo />);

expect(wrapper.find(<Clicks />).children.length).to.equal(0);
wrapper.find('a').simulate('click');
expect(wrapper.find(<Clicks />).children.length).to.equal(1);

This is my approach, and it's closer to being a good thing. I'm looking for a component inside Foo and then verifying its children in the DOM. I simulate a real click on the wrapper, and I don't care about internal methods. It's a good step toward better testing, but one thing is wrong: I'm assuming that <Clicks /> will be inside Foo. If I change the component, I will have to update it in all the tests that use this. Also, I'm assuming that the a element exists; if in the future it becomes a button or any other html element, it will break my tests. I shouldn't be concerned about which HTML element I'm clicking on. Even in a better test, I'm depending on an internal implementation to make my tests pass.

To improve these tests you can do something like this:

const wrapper = mount(<Foo />);

expect(wrapper.find('[data-testid="clicks-container"]').children.length).to.equal(0);
wrapper.find('wrapper.find('[data-testid="clicks-action"]'').simulate('click');
expect(wrapper.find(wrapper.find('[data-testid="clicks-container"]').children.length).to.equal(1);

Now I've based my test on data-testid. On this abstracion the clicks-container represents where the information is located, and clicks-action is a representation of a clickable element, it's the thing that will handle how many clicks I've made. I don't care about the type; just the fact that something is containing, and that that something it's clickable, what it matters in my tests.

You can see how I improved my test using Enzyme, making it clear that you don't have to migrate to a new library to write better tests. The real importance here is how you write your tests: how clear they are, how isolated the runs are, not the library used.

With React Testing Library, you have fireEvent, which simulates events on the DOM—a very powerful utility. You can check its documentation here. My test is going to find the input, then change the input value to the first gnome name value, and finally verify that only the correct gnome is displayed

 it('should filter the gnomes', async () => {
    fetchUtil.setResponse(correctAnswer);
    const { storeUtil, getByTestId } = renderWithState(Dashboard);
    const gnomeName = correctAnswer.Brastlewark[0].name;
    const gnomeId = correctAnswer.Brastlewark[0].id;
    const filter = await waitForElement(() =>
      getByTestId('gnomes-filter-input')
    );

    fireEvent.change(filter, { target: { value: gnomeName } });

    await storeUtil.getAction('GNOMES_FILTERED');
    const boxContainer = await waitForElement(() =>
      getByTestId('gnome-box-container')
    );
    expect(boxContainer.children.length).toEqual(1);
    const gnomeDetails = await waitForElement(() =>
      getByTestId(`gnome-box-item-${gnomeId}`)
    );
    expect(gnomeDetails.textContent).toEqual(gnomeName);
  });

Given I receive the correct information, and I have the input to filter the gnomes.
When I search for my gnome
Then I see only that gnome

As you can see my test follow the pattern Given-When-Then and I verify that the business requirements are delivered on my code. Now I can start migrating my code to hooks and the tests should not break.

Mutants on the code and the corner cases

Let's assume we're in a normal workflow, and you need to code a requirement. The requirement comprises three acceptance criteria that you must fulfill. After testing and coding, the original three requirements are already developed. However, it's common to find that there are more aspects to consider beyond these three requirements. You encounter peculiar cases that must be validated to prevent future bugs.

As a developer, one crucial task is to ensure that your code supports these unusual corner cases. If you're uncertain about the expected behavior in these new scenarios, you should consult with the recipient of the development (such as the Product Owner, Proxy PO, Stakeholder, client, etc.). They, as the owner, should guide you on the path to follow. However, regardless of guidance, if you believe that the code requires a test to validate a corner case, you must create the test and integrate it into the code. Neglecting to do so will lead to more difficulties in the future when you or others struggle to understand the rationale behind these corner cases.

TDD (Test-Driven Development) helps you develop with control, while BDD (Behavior-Driven Development) aids in understanding the business. However, there are times when you simply need to create tests to ensure that the code functions even when things don't go as expected. Always remember Murphy's Law: 'Things will go wrong in any given situation if you give them a chance.

Mutants are a different topic altogether. Mutant generation is a testing strategy where you intentionally modify your code and check if the tests still pass. For instance, you might remove a line, change a > to a =>, or include a "!" before an assertion. If your tests still indicate that everything is fine, it means your code might be flawed.

Testing mutants in your code is a healthy process to assess how robust your test suite is. Several libraries can assist you with this, with Stryker JS being one of the most popular options. It's essential to consider all these factors when testing your application, as each type of test provides different insights and contributes to your development as a better developer.

Conclusions

Today, we tested a React application with React Testing Library, simulating a real-life environment. We emphasized the importance of good tests in creating maintainable, extensible, and comprehensible code. It's crucial to keep implementation details outside the tests and learn how to mock our boundaries to ensure our app behaves like a normal application. By continuously improving our tests, we establish a safety net that allows us to implement, experiment, and enjoy building amazing applications.

It's worth noting that terms like scenarios, responsibilities, no implementation details in tests, mocking, and utils for creating mocks are essential vocabulary that every member of the development team should know and understand. When a team grasps the significance of these concepts, it indicates a lack of a Culture of Testing, changing that is the first step into a better team, better product, and better code.

InTheTestsWeTrust

Check my previous posts

The What, Why and How of React (Testing)

miguel-penaloza — Sun, 16 Dec 2018 15:03:38 +0000

Hello, today we're going to talk about one of the most important parts(or should be one) in a development process, no matter the framework, the language or if you're a frontend or backend, the tests are vital to verify that your codes really do what was coded to do. In this post, We're going to check the ways to test a react application, understand what means real coverage, the principal's and popular libraries used and try to understand when is the best moment to test your code, so let's go.

What means Testing a React application

In most of the interviews that I been made, to work as a developer, they always ask about TDD(Test Driven Development), BDD(Business Driven Development), unit testing, automation testing and so, but at the same time in most companies for which I have worked they don't really make tests, or rather, they write some test as an obligation that doesn't give any value to the code, this's often caused because they don't have a culture of testing.

So, you have developers who maybe understand how to test, they maybe know why to test, but the test is always like this painful task that you have to do, without realizing that a good test is a bug-less(no bugless, that's a myth) in production, and this goes for any framework or library, no just React, so lets see the principal concepts about testing and try to understand what really means and verify if this can help you in your job.

Unit testing
This's a very simple but powerful concept, you need to create a test who check one unique part of your code, the goal if have a unit test who verifies a premise, that a function called will answer the same that you're expecting to receive.

Understanding that, you know that you need to have so many unit tests as you can, to verify that your entire code doesn't fail and be completely sure that any new code who change the current behavior or broke something not related with that specific development task will catch it for your battery of tests, let's see an example where these are my premises.

My calculator receive two numbers and returns the sum of both.
If I pass a no number as a parameter, that parameter is taken as a zero.

These 2 premises are our base, is what we need, we can say that's the acceptance criteria for the code that we need to write. The idea here is to create unit tests for each acceptance criteria, to verify that our function complies with both acceptance criteria always, no matter if your codes changes in the future, the 2 premises should be respected.

TDD (Test Driven Development)
This's a term that always appears in the interviews, but what's TDD? is a programming practice where you write the test before code, that means that you need to understand what you have to do before starting to code, means that you write your test to expect to receive a correct answer (Test Before Code), create an empty function that will fail, and then fix your code to return the expected answer, and then continue the process with the next task. let's go and try to implement our calculator with TDD:

We need to create a function to add two numbers, so let's write the test before the code, the test should expect the correct answer and create an empty function that will fail.

// Sum function 
var sum = (a, b) => return 0; // This function always return zero

// Your test 
var shouldAddCorrectly = () => {
    return sum(2,2) === 4; // False
};

In the code above the function, shouldAddCorrectly is our test and is expecting to receive 4, we are trying to add 2 and 2, but the add function is failing and returning 0, we have a correct unit test for a wrong code, what we need is fix the sum function.

// Sum function 
var sum = (a, b) => return a + b; // This function now is working well

// Your test 
var shouldAddCorrectly = () => {
    return sum(2,2) === 4; // true
};

As you can see the test and the code now works, right now we're not using any library or framework to test, is pure javascript. The second premise is indicating us that we need to check when one of the parameters is not a number if it is a number use it, otherwise, this params will be a zero, so we create the test to validate that.

// Sum function 
var sum = (a, b) => return a + b; // This function now adding but not filling all the requirements.

// Your tests
var shouldAddCorrectly = () => {
    return sum(2,2) === 4; //true
};

var shouldAddCorrectlyWhenFirstParamIsNotANumber = () => {
    return sum('Something',2) === 2; // false, because is returning "something2"
};

Here we have that our new test is failing, but also our test is correct, the answer should be 2, not 'something2', now we fix the code, and both tests are passed.

// Sum function 
var checkNumber = (number) => isNaN(number) ? 0 : number;

var sum = (a, b) => {
    var firstParam = checkNumber(a); 
    var secondParam = checkNumber(b); 
    return firstParam  + secondParam;
}

// Your tests
var shouldAddCorrectly = () => {
    return sum(2,2) === 4; // true;
};

var shouldAddCorrectlyWhenFirstParamIsNotANumber = () => {
    return sum('Something',2) === 2; // true
};

Benefits of TDD

We can use this to avoid the bad practice of try to testing everything at the end of the development, if you implement TDD, you will have all your test done before your code.
You're going to understand better your code before the start.
This will force you to reduce your functions to small parts of logic, and this's always good. Avoid overcomplex code should be our golden goal.
You can trust in your code, and make sure that you can detect errors in the dev process before the integration.

But, if TDD is so good why is so hard to implement in your process? well, the big problem with TDD is that write a test include an amount of time and effort that some projects don't have and most of the teams use this 2 classic excuses to don't even try TDD.

We don't have time.
We're very sure that our code works.

To really implement TDD or any other methodology, what we need to have, is just have a simple thing called culture of testing, and we're going to talk about that later.

BDD (Business Driven Development)

BDD is an evolution or the testing process, TDD verifies small part with unit tests, BDD writes a test that's not necessary a unit test, to verify that the business cases are taking in account in the development and not just the logic.

Because you can have a very good code who works perfectly, the test that verifies that the code works on multiple scenarios, but at the end, the code fails because doesn't fit the business requirements, so basically BDD is verify behavior instead of implementation, let's see an example.

We have the code writen before, but now my business requires that instead of taking the no numbers parameters as zero, now we need that the calculator answer "There's an error in your parameters, please verify, and thanks for use this calculator!" when you provide a no number parameter, this change is a business requirement and we need to validate that works.

// Sum function 

var sum = (a, b) => {
    if(isNaN(a) || isNaN(b)) {
        return "There's an error in your parameters, please verify, and thanks for use this calculator!";
    }
    return a + b;
}

// Your tests
var shouldAddCorrectly = () => {
    var answer = 4;
    return sum(2,2) === 4; // true
};

var shouldAddCorrectlyWhenFirstParamIsNotANumber = () => {
    var answer = 2;
    return sum('Something',2) === "There's an error in your parameters, please verify, and thanks for use this calculator!"; // true
};

We now have a test who verifies business instead of just implementation, we can have a more complex test using BDD, for example, in the How section we will see how to make that in React

Function Test, Automation Test, and Integration Test
The functional test is the test made by a QA, for a human (if we can call QA's humans), the QA now is the one who validates an entire application where they need to verify all the requirements and scenarios, the automation tests are the same functional test but this time executes by a tool, selenium is one of the most popular frameworks to run automated test now days.

The Integration tests are made to validate functionalities that are operatives and deployed, we need to understand that the unit tests are made to focus on the details of individual implementations and these others tests are to validate flows.

Testing Culture
So, we defined some of the most important concepts of testing, now we need to talk about the testing culture, as we say before the problem with the test is that the most of the developers don't feel write test as part of the development, instead is an extra task, is a boring assignation that block you to continue development cools stuff.

What we need is a Culture of Testing and this only can achievement when the developer feels that test are giving value instead of more job, what we need to do is follow this rules and very soon we're going to see the real value of the test.

Thinks before code, Testing is the best way to understand what're you going to code, try to identify the problem before the start, instead of think how implement something, try to understand what factors can make your code fails, is a changeset mind that will give you the power to understand what the heck are you doing and how do it better.
When my code Compile and Run I can finish a task, but without test we do not finish the story You can finish all your tasks, write all your code, but the job is not ready until everything is done, that means that everything should work ok, without test you don't know that, so you can't know if your code works ok.
A failing test is not a bad thing, we the humans have this psychological need to see everything ok, something failing means that we're wrong, but sometimes a failed test can be a good thing too, because this blocks you to merge something wrong, you should give thanks to the tests to avoid the shame of being that commit who block everything to everyone.
Make it simple, There's a lot of methodologies and patterns like YAGNI (You're not going to need it) or KISS (keep it simple stupid) that helps you to write better code, but using TDD is the best way to really get that.
The real goal is not the coverage, we often see teams where the rule is to have more than 80% of coverage or any other number where they feel comfortable, but what we need to understand is that coverage means nothing is we have bad tests, so instead of try to fill a number of coverage, try to write real test who validate business and logic where matter.
Our tests need to be bulletproof, If we can remove a line in our code, and the test pass it anyway, our tests are not ok.

These are simple rules that will help you to create a culture of testing on all the teams.

Why Test in React.

You need to test because you will have:

Quality Code: You are sure that the code does what we expect.
Design focus on the needs: You understand the requirements, you design based on that, and you build thinking on that.
Less debugging more coding: With more test, fewer errors you will have and you can focus on the more complicated and funny tasks.

How Test in React

Now we get to React, how testing our application? and not just testing to get a coverage, instead, we're going to see how to make real tests and be totally sure that our coverage means something. What we're going to use to test is the most popular framework to do that on React Jest, this library can be used not only for React, but works very good, also, we're going to use Enzyme that's a util to test React applications who allows creating mocks and shadows of our components, and (Istambul)[https://istanbul.js.org/] that helps us to collect the coverage.

First, we need to understand what part of our React environment can be tested, for that we can split our tests by scope or type of element.

How to test Components

React is a library who help us to create encapsulated Views, where we can handle his states and add so many logic as the component requires, so let's start by the beginning, and let's see the base concepts of a React component

Understanding the Lyfecycles
All the components start with a mounting process if the component is updated have an updating process, and an 'unmounting' process when the component is removed, understand this's is important because a good test should verify the behavior of your component in all his states or lifecycles. Each process will call different methods that in some moment we're going to need to mock or dispatch.

These methods are called when a component is created (Mounting)

contructor Will receive some props and should start the states
getDerivedStateFromProps almost never used is static, doesn't have access to the props or state of the component
render where the magic happens
componentDidMount This's the most common method used to make a request for data

These methods are called when a component detects a change in his props or state (Updating)

getDerivedStateFromProps Also static.
shouldComponentUpdate this function is used to avoid re-render after an update if you include that kind of logic in your component you should test it.
render the magic again.
componentDidUpdate Is the best place to make a request for any kind of data.

And by the end, when the component is removed, this function is called:

componentWillUnmount This's used to clean the DOM and cancel all the possible request of subscriptions made by the component.

NOTE: These're the methods currently used in September 2018 to React 16, this flow can change and some methods could be deprecated in the future or non-accessible in the previous versions of React.
NOTE 2: Is very important to understand the reason behind each method to use them correctly, understanding the reasons you can understand what test

Understading States and Props
The components also have states and props, the props are information provided by the parent component, the one who calls him, and the state is declared in the construction, and have the information of the component, is the component the only one who should manipulate his state, and the props are sacred, never should changed.

Shadow and Mounting

Manipulate changes on the state, if one of the ways to test a react component, the react components have functions bound to his elements like an 'onChange' on the inputs or 'onClick' on the buttons, so you can create a shadow or a mount of your component, then you should be able to click and change inputs or any other event imitating a real environment.

A Shadow is an isolation of your component, you will only render your component without his children, and a Mount will reproduce all the render flow, to use mount you will need to have DOM declared for the test, you can use JSDOM.

What we need to do is create a Shadow or a Mount of your component with Enzyme, that will allow you to have a component having his mounting and updating process, there you can change inputs and click buttons, and basically make all the possible interactions with your component, verify your state and call any of your methods, with that you can prove your uses cases with your tests.

Mock
With Jest you can mock some components to avoid complicating your test resolving external dependencies, to mock your component just write this after the import declarations:

jest.mock('the relative or absolute path of the js file that you want mock', () => `Mocked JS or whatever`);

As you can see, you can mock anything and return whatever you need it, you can also use the default mock of Jest only passing the path of the component to mock if you wanna see more about this functionality read this

Now you know some basics of React, Jest, and Enzyme, let's see how to write some tests.

The first thing is to install all your dependencies:

npm install --save-dev jest react-test-renderer enzyme enzyme-adapter-react-16 enzyme-to-json

NOTE: If you use Babel, async to get or typescript you will need to include the jest plugin for your compiler, like babel-jest, async to get or ts-jest.

Before starts, you need to create 2 things, a configuration file and a setup file on your project, let's start with the setup file, it will be called jestSetup.json our src folder, in this file, we're going to initialize the Enzyme Adapter. That will help us to use Enzyme with React 16, for older versions you need to check what Adapter use, this's the mine:

import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

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

Now we need to define where to put our test, you can have a test folder where we're going to create all the tests for your code or you can put your test in the same location where you have your file to test, Jest will run as a test file everything who finish in .test.js or .spec.js.

Note: You can change this on the textRegex that I will show you later.

So you can have so many tests as you want and order them as you wish, we're going to make it in the same folder but this's up to you.

Now is the turn to the configuration file, you can have had an external file and include the flag --config=jestconfig.json on your test command, or you can just include in your package.json in a jest key. Anyway, the configuration should look like this:

{
    "collectCoverageFrom": [
      "src/**/*.{js,jsx,ts,tsx}",
      "!src/**/*.d.ts"
    ],
    "resolver": "jest-pnp-resolver",
    "setupFiles": [
      "react-app-polyfill/jsdom"
    ],
    "testMatch": [
      "<rootDir>/src/**/__tests__/**/*.{js,jsx,ts,tsx}",
      "<rootDir>/src/**/?(*.)(spec|test).{js,jsx,ts,tsx}"
    ],
    "testEnvironment": "jsdom",
    "testURL": "http://localhost",
    "transform": {
      "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/babel-jest",
      "^.+\\.css$": "<rootDir>/config/jest/cssTransform.js",
      "^(?!.*\\.(js|jsx|ts|tsx|css|json)$)": "<rootDir>/config/jest/fileTransform.js"
    },
    "transformIgnorePatterns": [
      "[/\\\\]node_modules[/\\\\].+\\.(js|jsx|ts|tsx)$",
      "^.+\\.module\\.(css|sass|scss)$"
    ],
    "moduleNameMapper": {
      "^react-native$": "react-native-web",
      "^.+\\.module\\.(css|sass|scss)$": "identity-obj-proxy"
    },
    "moduleFileExtensions": [
      "web.js",
      "js",
      "web.ts",
      "ts",
      "web.tsx",
      "tsx",
      "json",
      "web.jsx",
      "jsx",
      "node"
    ],
    "setupTestFrameworkScriptFile": "<rootDir>/src/setupTests.js",
    "snapshotSerializers": [
      "enzyme-to-json/serializer"
    ]
  } "roots": ["test", "src"]
  }

As you can see I use the default configuration provided with react-scripts 2, the last 2 lines, setupTestFrameworkScriptFile will indicate what's our setup File, and the snapshotSerializers will help us to avoid problems with Leak of Memory on javascript.

You can check the Jest Config documentation to understand better what include on your setup file.

To include Coverage we need to add npm run test -- --coverage on our command line to allow jest and Istambul generate a coverage report.

Finally write a test

If you get to this part, you already have all your configuration done, and you can start writing your test.

Matching Snapshots

The base example of Jest with React is shallow a component, manipulate his events and match snapshots, this test is ok, you will write your component to change his attributes, like the class name, or some data-attribute with each event.

In the example of Jest, they create a Link component, his class name is bind to the state with this: className={this.state.class}. Then they mock a user entering over the component (Hover) and leaving (Blur), and for each event, they create a snapshot.

The first time when you run the test, jest will create the base snapshot, that will look like this one:

// __tests__/__snapshots__/Link.react.test.js.snap
exports[`Link changes the class when hovered 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function]}
  onMouseLeave={[Function]}>
  Facebook
</a>
`;

exports[`Link changes the class when hovered 2`] = `
<a
  className="hovered"
  href="http://www.facebook.com"
  onMouseEnter={[Function]}
  onMouseLeave={[Function]}>
  Facebook
</a>
`;

The next time when you run your test, jest will verify that the component in each test is creating the same snapshot if for some reason the component is creating a different one will mark as a failed test. You can just override the previous snapshot, but you need to verify why is failing before update.

Pros

You can verify that your component keeps with the same behavior, and is returning the same HTML every time is rendered.
This will verify that the execution is done without problems, no exceptions are thrown
You should be able to create snapshots passing multiple props and check what's rendered.

Cons

Is not a common scenario or practice change an attribute of a component to reflect a state, so more than one snapshot by tests is not common.
Render a component and create a snapshot will pass the test over a lot of lines, that will increase your coverage, but this doesn't mean that you are testing your component, in this scenario you just render a component no creating a testing that validates a business or functional case.

Testing a real case.

In the most of the cases, what you need to do to trust on your code is create a test that validates that works as you expected, but what we need to write a test validating a real case? we need a DOM or at least a mocked DOM, where I can manipulate my component and basically emulate real interactions, for example.

If I create a Form, I should test adding values to the inputs, submit or cancel the form, and verify the values provided to the inputs.
If I create a dashboard where I can click over an icon and be redirected to somewhere, I should test clicking the icon.

Sound silly and very simple, but write test is just that.

Let's go with a Test!

I will use a project as an example that I write some while ago, where a dashboard of multiple profiles of gnomes are displayed on the screen, and you should be able to filter by name.
You can get the source code here.

Write a Test for the Dashboard and the search input.

So, what we need? what's expected on this? let's start with our tests using BDD, and the first thing need it defines what we expect to happen in multiple scenarios

Without any text on the search all the gnomes in the dashboard should be visible as an Icon.
If I write something and match with some profiles, only the gnomes profiles that match with that name should be displayed.
If I write something that doesn't match with any profile, none profile should be displayed.

So, for this component, we have 3 functional and business cases to test. What we have here in this project 2 kind of files that will be tested.

components and containers All my react views, I will test only the Dashboard (that includes the list of gnomes), the Gnome Box, that have the white box where I can see the details of the gnome displayed and a Gnome Details.
saga Is where a made all the transactions of the application, I will show you how to test this too.

This will represent the most important part of our Application and are the one who should test it, to be sure that our code works as we expected.

Testing the Dashboard

I create a simple Component, who receives a list of gnomes and display each one in a GnomeDetails, have a filter that modifies the current list ad this it is. A very common component used in a lot of places.

export class DashboardPanel extends Component {
    constructor(props){
        super(props);
        this.state = {
            filterText: ''
        };
    }

    filter(){
        const { gnomes }= this.props;
        const { filterText } = this.state;
        const gnomesFiltered = gnomes.filter(gnome => {
            if(filterText){
                return gnome.name.toLowerCase().includes(filterText.toLowerCase());
            }
            return true;
        });
        return gnomesFiltered;
    }

    render(){
        const { filterText } = this.state;
        const gnomesFiltered = this.filter();
        return (
            <Dashboard>
                <Options>
                    <Title>Gnomes</Title>
                    <Filter>
                        <Input
                            type="text" 
                            width="150px"
                            isFilter
                            title="Filter"
                            value={filterText}
                            onChange={({target})=> this.setState({ filterText: target.value })}
                        />
                    </Filter>
                </Options>
                <GnomesList>
                    {gnomesFiltered.length !== 0 ? gnomesFiltered.map(gnome => 
                        <GnomeBox 
                            key={gnome.id} 
                            gnome={gnome}
                        />): 
                        <p>No gnomes to display</p>
                    }
                </GnomesList>
            </Dashboard>
        );
    }
}

The first recommended test to do on a component is a snapshot, we can use the jest toMatchSnapshot and generate one that will have a backup of what was rendered on the first test, if anything changes this snapshot will fail, this's a normal test, I use the beforeEach to load the props for each test, and a simple test to create and verify the snapshot, like this:

import React from 'react';
import { mount } from 'enzyme';
import DashboardPanel from 'components/DashboardPanel';
import GnomeBox from 'components/GnomeBox';
import Input from 'components/Input';

let props = {
};

describe('Dashboard Panel', ()=> {
    beforeEach(()=> {
        props = {
            gnomes: [
                {'id':0,'name':'Tobus Quickwhistle','thumbnail':'http://www.publicdomainpictures.net/pictures/10000/nahled/thinking-monkey-11282237747K8xB.jpg','age':306,'weight':39.065952,'height':107.75835,'hair_color':'Pink','professions':['Metalworker','Woodcarver','Stonecarver',' Tinker','Tailor','Potter'],'friends':['Cogwitz Chillwidget','Tinadette Chillbuster']},
                {'id':1,'name':'Fizkin Voidbuster','thumbnail':'http://www.publicdomainpictures.net/pictures/120000/nahled/white-hen.jpg','age':288,'weight':35.279167,'height':110.43628,'hair_color':'Green','professions':['Brewer','Medic','Prospector','Gemcutter','Mason','Tailor'],'friends':[]},
                {'id':2,'name':'Malbin Chromerocket','thumbnail':'http://www.publicdomainpictures.net/pictures/30000/nahled/maple-leaves-background.jpg','age':166,'weight':35.88665,'height':106.14395,'hair_color':'Red','professions':['Cook','Baker','Miner'],'friends':['Fizwood Voidtossle']},
                {'id':3,'name':'Midwig Gyroslicer','thumbnail':'http://www.publicdomainpictures.net/pictures/10000/nahled/1-1275919724d1Oh.jpg','age':240,'weight':40.97596,'height':127.88554,'hair_color':'Red','professions':['Carpenter','Farmer','Stonecarver','Brewer','Tax inspector','Prospector'],'friends':['Sarabink Tinkbuster','Tinadette Wrongslicer']},
                {'id':4,'name':'Malbin Magnaweaver','thumbnail':'http://www.publicdomainpictures.net/pictures/10000/nahled/zebra-head-11281366876AZ3M.jpg','age':89,'weight':43.506973,'height':101.6974,'hair_color':'Black','professions':['Smelter',' Tinker'],'friends':['Fizkin Fussslicer','Cogwitz Chillwidget']},
                {'id':5,'name':'Zedkin Quickbuster','thumbnail':'http://www.publicdomainpictures.net/pictures/10000/nahled/1-1193219094.jpg','age':273,'weight':38.742382,'height':91.54829,'hair_color':'Red','professions':['Cook'],'friends':['Libalia Quickbooster','Whitwright Mystwhistle']},{'id':6,'name':'Emmadette Gimbalpower','thumbnail':'http://www.publicdomainpictures.net/pictures/20000/nahled/stingray.jpg','age':212,'weight':40.681095,'height':98.701645,'hair_color':'Green','professions':['Mason'],'friends':['Ecki Gyrobuster','Zedkin Nozzlespackle','Milli Clankswhistle','Libalia Magnatink']},
                {'id':7,'name':'Twizzle Chrometossle','thumbnail':'http://www.publicdomainpictures.net/pictures/10000/nahled/1-1275919724d1Oh.jpg','age':85,'weight':38.953087,'height':96.0678,'hair_color':'Red','professions':['Baker','Brewer','Tax inspector'],'friends':['Libalia Mystbooster','Zedkin Gyrotorque']},
                {'id':8,'name':'Malbert Tinkbuster','thumbnail':'http://www.publicdomainpictures.net/pictures/10000/velka/1-1248161543llOC.jpg','age':186,'weight':41.159805,'height':118.27941,'hair_color':'Gray','professions':['Baker','Mason'],'friends':[]},
                {'id':9,'name':'Kinthony Nozzlebooster','thumbnail':'http://www.publicdomainpictures.net/pictures/20000/nahled/baby-lamb.jpg','age':233,'weight':41.024612,'height':113.56545,'hair_color':'Red','professions':['Smelter','Miner','Tax inspector','Carpenter'],'friends':['Zedkin Clankstorque','Midwig Magnarivet']}]
        };
    });
    it('should match snaptshot dashboard', () => {
        const dashboardPanel = mount(<DashboardPanel {...props}/>);
        expect(dashboardPanel).toMatchSnapshot();
    });
});

As you can see, here I have a test that sends props to a component, render it and everything looks ok, but can we say that we really test our component? We need to check our coverage report to really understand what's missing, if you run your test including npm test -- --coverage you will have a new folder coverage created and your root project, and you will find this file: /coverage/lcov-report/index.html, please open it on your favorite browser and you will see the coverage status of your project.

Let's search our DashboardPanel component and try to understand what's being reported.

Status Covarage

Wow! I have 90% of coverage on Lines and Statements, in functions we are over the 80%, they're big numbers, the branch is a little low, but in average we're ok right?, if we as a team decide to have a coverage of 80% I totally get it with this test, but my component is really tested? Let's see my code status:

As you can see, the code says something different than my previous numbers, I have some part of the code on red, this means that my test never gets there, and also some on yellow, this means that I have a conditional if that never was tested. so, we can see that my test is not really tested, I have the coverage but I don't trust that my code works.

Let's do a real test, where I start with an empty list of gnomes, then receive it, as a normal flow, then we take the input, mock the onChange function with different inputs and verify that the state changes correctly.

it('should render dashboard panel',()=> {
        // Mount Dashboard with none list of gnomes because the normal is that the first time never receive anything because the server was no called yet.
        const dashboardPanel = mount(<DashboardPanel gnomes={[]}/>);
        expect(dashboardPanel.find(GnomeBox).length).toEqual(0);

        // Mock the response of the server with 10 gnomes, the component will receive these props and validate that the 10 GnomeBox components are rendered.
        dashboardPanel.setProps(props);
        expect(dashboardPanel.find(GnomeBox).length).toEqual(10);

        //Find the filter component.
        const input = dashboardPanel.find(Input);

                // We mock the user iteration and send to the input an valid change event, and also we validate that the state change accordely, the filter text in the state  and is only one GnomeBox displayed.
        input.at(0).props().onChange({ target: { value: 'Tobus'}});
        expect(dashboardPanel.state('filterText')).toEqual('Tobus');
        dashboardPanel.update();
        expect(dashboardPanel.find(GnomeBox).length).toEqual(1);  

                // Then we validate the case where I just pass a letter and when we reset the filter to nothing again.
        input.at(0).props().onChange({ target: { value: 'a'}});
        expect(dashboardPanel.state('filterText')).toEqual('a');
        dashboardPanel.update();
        expect(dashboardPanel.find(GnomeBox).length).toEqual(4); 

        input.at(0).props().onChange({ target: { value: ''}});
        expect(dashboardPanel.state('filterText')).toEqual('');
        dashboardPanel.update();
        expect(dashboardPanel.find(GnomeBox).length).toEqual(10); 
    });

Now let's see the status again:

Everything is 100% of coverage but more importantly, I test all the possible behavior of my component, as a normal user will use it. Now I can trust that if everyone modifies the code, and the base behavior changes my test will catch it.

What we need to understand is that the coverage is just a number, the real coverage is what we need to get not just pass a random number. A component can have more complex behaviors, but in the end, what we need to do is understand the lifecycles and play with it.

Testing the middlewares

Today the react applications are becoming bigger and bigger and we now need to include extra logic on our App, sometimes we include middlewares to handle transactions that we don't wanna (and we shouldn't) include in our component, for this we can use redux-thunk, sagas or whatever. I'm going to explain to you how to test sagas, but this works with any Generator function

Let's check my saga file called gnomes, you can find it in the saga folder. I have 2 functions, but let's test it the first one, fetchGnomesSaga that is the one on charge to fetch the gnomes from the server, and looks like this:

export function* fetchGnomesSaga(option) {
    yield put(isLoading(true));
    const result = yield call(fetchGnomes, option);
    yield put(isLoading(false));
    if(!result.error) {
        yield put(gnomesFetched(result));
    }
}

We need to have a test that calls this function and mocks the behavior of the transaction, sends the answers and validates that's correct. Let's start with a list with the base concepts of a generator function.

A generator is a javascript function, that is identify with the asterisk after the name like this function* fetchGnomesSaga(option) who will execute the code but will stop in each yield until gets an answer.
The yield is our transactions steps.
We need to validate each possible transactions responses based on what can be received on each step.

import { fetchGnomesSaga } from './gnomes';

describe('Saga Gnome test', ()=> {
    it('should fetch the gnomes correctly',()=> {
                // Set the Generator function in a constant
        const generator = fetchGnomesSaga({}); // We send nothing because we don't care this right now
        const isLoading = generator.next(); // The first stop is when the saga change the state to Loading
        expect(isLoading.value).toEqual(
            {'@@redux-saga/IO': true, 'PUT': {'action': {'payload': true, 'type': 'IS_LOADING'}, 'channel': null}}
        ); // Now we validate that the state is the correct.
    });
});

In our test, the generator start and stop on the first yield, the one that will change the Loading status of the application, then, I call the generator.next() function to mock the response from redux indicating that the action was done, I can pass values on the next to indicate that the action sends some params, in this case, the redux just make the change on the state, doesn't return anything, that's why is empty.

To complete an Ok journey, we need to complete all the yields, like this:

it('should fetch the gnomes correctly',()=> {
        // Set the Generator function in a constant
        const generator = fetchGnomesSaga({}); // We send nothing because we don't care this right now
        let isLoading = generator.next(); // The first stop is when the saga change the state to Loading
        expect(isLoading.value).toEqual(
            {'@@redux-saga/IO': true, 'PUT': {'action': {'payload': true, 'type': 'IS_LOADING'}, 'channel': null}}
        ); // Now we validate that the state is the correct.

        // The next stop is the fetchGnomes API
        const callGnomes = generator.next();
        expect(callGnomes.value.CALL.fn).toEqual(fetchGnomes);

        // The next stop before receive the gnomes is disable the loading, in this step is where the data is received, so we send the data on the next
        isLoading = generator.next({ status: true, data: [1,2,3]});
        expect(isLoading.value).toEqual(
            {'@@redux-saga/IO': true, 'PUT': {'action': {'payload': false, 'type': 'IS_LOADING'}, 'channel': null}}
        );

        // We received the data already, but now we call the redux action who change the state with the payload received [1,2,3]
        const gnomesReceived = generator.next();
        expect(gnomesReceived.value).toEqual(
            {'@@redux-saga/IO': true, 'PUT': {'action': {'payload': {'data': [1,2,3], 'status': true}, 'type': 'GNOMES_FETCHED'}, 'channel': null}}
        );

        // The next step and the last one has just finished the generator, we need to validate it to avoid extra steps before the end.
        const endGenerator = generator.next();
        expect(endGenerator).toEqual({'done': true, 'value': undefined});
    });

In the test above, you can see that I simulate the transaction to be a happy path, if someone modifies the code, and include extra steps that modify the result, I should be able to catch it too.

Let's see now how to handle a no happy path when the API returns an error:

it('should fetch the gnomes but fails ', ()=> {
        // Set the Generator function in a constant
        const generator = fetchGnomesSaga({}); // We send nothing because we don't care this right now
        let isLoading = generator.next(); // The first stop is when the saga change the state to Loading
        expect(isLoading.value).toEqual(
            {'@@redux-saga/IO': true, 'PUT': {'action': {'payload': true, 'type': 'IS_LOADING'}, 'channel': null}}
        ); // Now we validate that the state is the correct.

        // The next stop is the fetchGnomes API
        const callGnomes = generator.next();
        expect(callGnomes.value.CALL.fn).toEqual(fetchGnomes);

        // The next stop before receive the gnomes is disable the loading, here the fetch fails, we don't care the error, but we need to hanlde it.
        isLoading = generator.next({ error: true });
        expect(isLoading.value).toEqual(
            {'@@redux-saga/IO': true, 'PUT': {'action': {'payload': false, 'type': 'IS_LOADING'}, 'channel': null}}
        );

        // We received the data already, but now we call the redux action who change the state with the payload received [1,2,3]
        const gnomesNotReceivedAndDone = generator.next();
        expect(gnomesNotReceivedAndDone).toEqual({'done': true, 'value': undefined});
    });

I basically change the API function to receive an error, when there's an error my code just doesn't update the gnomes state. If I have more than one call to any server, parser logic, or any other scenario, I should include a test to validate each scenario assuming that at any moment something can fail, if we code thinking that our code is fragile, we will be able to understand and prevent problems on the future, this's the reason behind why I should have so many tests.

Conclusion

So, we should test everything?
I tried to explain 2 common places on our react applications where we can have a lot of logic, components and the middleware, but we should not test everything just because is the rule, we should test everything that handles logic that affects our business scenarios.

the coverage it's a lie?
No, but trust only in the coverage without check the quality of the tests is the same that don't do any test. Part of a code review should include verifying that the test is ok for what's intended to test, a high coverage means test but is in the little details where our code fails, and the coverage doesn't say is we're ok on that sense.

Should I use jest only?
Jest is very powerful but is not the only one, you can use chai, mocha or any other framework, the library is just a help, in our first example we don't use any framework, the quality on a test is not for the tool used, is the test itself who can assure that.

How to create a culture of test on my team?
Is hard, because no one likes to write test, but teaching how to test, and explaining the value should be the first step.

How to make better tests?
Write better code, if you apply good patterns and principles, the test should be simple, if we realize that a test takes so much of our time, and is overly complicated, maybe the problem is our code and no the test itself. Divide and Conquer

Should I mock?
Depends on what you are trying to test, in you try to test a code that consumes multiple services, the best is just mock that services, replicating the real responses. A unit test should be isolated.

Well, I hope this post helps you to understand a little more about the testing process, not just how to test but why. Hope you enjoy the read.

In the code we trust

Check the second part of this post:

The What, Why and How of React (Testing with Hooks)

Check my previous posts

The What, Why and How of React (Styles)

miguel-penaloza — Wed, 26 Sep 2018 00:28:28 +0000

Hello, this is my third post about the React ecosystem, and today is the turn of one of the most important parts in the development of any FE, the styles. Everytime that I have to explain what a frontend developer do in words that even a five years boy or girl can understand, I always start saying that a website as like a human body, the HTML could be the bones, the javascript can be the brain, and the CSS would be the appearance. S0 you need a healthy osseous system, be mentally stable too and obviously, you need the looks good, sound narcissist, but in the end, all the Frontends are little narcissists.

In 2018 we're in a moment when you can do amazing things with javascript, we already have almost 10 years since HTML 5 becomes the final standard for HTML and is hard to find someone who tries to implement an alternative to the style of a website using something different to CSS, the style is what makes the difference between an ugly site and a modern one. In this post we're not going to talk about UI/UX, naming conventions or best practices when you try to give the style to your page (or at least not in detail), today we're going to focus on how to include this big world of styling in our React application.

What's style in React?

React allow you to include CSS in his components in several ways, so you can have 2 approaches when you try to style a React component, each one totally different to the other, basically you can create components where the component can know or handle his own style, or totally agnostic about how they will look, I’m not talking about the Components vs Containers struggle, this approach is about the way how we include the style in our React Component, based on that we have these 2 approaches:

SelfStyled Components(The Cool ones): The component should include his own definition of whom they should look, with this the one who consumes the component should not care about defining a style and also you don’t need to have big modules of CSS, just include the style (we will talk about how to make this later) directly in the component, let each one decide.
Pure Components: These components don’t know how they should look, they don’t care, they will use a reference to indicate what component it’s, and trust that doesn't matter where the component is used, some global style will make it looks ok based in that reference, that can be a class name but you don't write any line of CSS.

NOTE: For this context the Pure Component term is not the same that the React API PureComponent.

Both approaches are ok, just depends on what you need. The idea of the first kind of components is that nobody should modify his looks, they own how they should look, no matter who will use it or where the looks are always the same, for the second one, they just don’t care.

Obviously, you can use both approaches, you can have Self Styled components for specific components, like a particular input, DatePicker or Layout; and also have a global style who care about the big picture, resetting some values by default or even selecting the fonts, IMPORTANT: If you decide to mix, is extremely important be meticulous in differentiating what you consider global, otherwise you will be fighting on a war that you won't be able to win against the specificity of CSS. If you are going to use CSS, try to follow a name convention, line BEM or whatever like you.

NOTE: If you decide to use Self Styled components don’t try to override specific styles in your global CSS, because you will find yourself writing CSS solutions that will finish with a big selector and using !important everywhere.
NOTE 2: If you decide to have a global style or any CSS framework like bootstrap, try to follow best practices at the moment of extending styles, sass and less have excellent documentation about how to keep your CSS maintainable.

Why should I care about style in React?

React is a powerful library where we can have a component, who mix the HTML and the js, into one class or function. That class or function handle the render states, how to initialize the component, how to behave after and before a render, an update or an elimination. But is not just business logic, we need to create components who should look ok for what they pretend to do.

So you need to have a way to include the style in your react component, the real question is if I should use a Self Styled component or a Pure Component? You can use both, base on what you really want. I will give some examples of where you should use one or another.

These are the best scenarios to use Pure components:
I wanna use a CCS framework built (or bought) in our frontend If you use something like bootstrap, material UI, or your own CSS framework and you wanna use that in your react application. You need to use a Pure Component approach.
I wanna keep consistency between all my FEs is also a possibility that you have built multiples FE in others frameworks if you don’t wanna worry about defining a CSS framework for each project and usability.

And these are the why for Self Styled components:
I don’t wanna have a big CSS monolith framework, sometimes big monoliths are not the best, one project against other can have particular differences or requirements that can convert our CSS monolith in an awful spaghetti code.
I wanna use the latest css, If you want to use the latest features for your sites, you should use this one, because you can be sure of implement what you want in a reduced scope, otherwise, that new CSS feature that works perfectly in your project can create infinite bugs in others projects.

How implement styles in React

We talk enough about what and why let's go now to the action, I will give simple examples of how to make a Pure Component and a Self Styled Component, let's see:

Pure Components
The Pure components, as we said before, don’t have a definition of his style, only a reference to indicate how our component should look and we can use the class name for that, in React we cannot use class we should use className, in that attribute of our component we can make a reference to any kind of CSS class used for our Application, like this:

import { Component } from 'react';

class PureComponent extends Component {
    render() {
    return (
            <div className="container">
                <div className="child" />
            </div>
        );
    }
}

export default (PureComponent);

We can see that we have 2 references, one class name called container and child, for the context of the component, they don’t care about what that means, the definition of the rules for that class is totally independent of the component itself.

But, Where is that style defined? All depends on our architecture, and where’s is running our React Application. I will let you some links to others blogs where you can find specific information about how implement based on what you might have:
Boostrap, to allow to use classes like col-lg-x or any other bootstrap class you should read this link
Material UI, to use the Material UI components
Css Loaders to include my own CSS, if you wanna include your own CSS, you should read this

In the most of the cases to use a CSS library what you need to do is include a Link reference, then you should be able to use it just calling the correct class.

Self Styled Components
We now are going to talk about the other way to do styling, sometimes what we need is define the specific style for our component, we don’t wanna use any kind of class name or reference to give the styles to our component, what we need is delivery a Component with his logic and style, and we can do it in several ways:

Including styles with a json
We can define a JSON, who contains the styles and then injected directly into the component, like this:

import { Component } from 'react';

const container = {
    margin: '30px',
    padding: '5px 10px',
    textAlign: 'center'
};

class SelfStyledComponent extends Component {
    render() {
        return (
            <div styles={container}>
                <div style={{color: blue}}/>
            </div>
        );
    }
}

export default (SelfStyledComponent);

We need to remember that for properties like text-align we should pass that to camel case and usetextAlign instead.

Styled Components
We have a library that allows you to create a Self Styled component in a more friendly way than just injects JSONs, we can use Styled Components, with this we can include small(or biggest depends on you) parts of SCSS, an assign directly to the React component, like this:

import React from 'react';
import styled from 'styled-components';

const Container= styled.div`
    margin: 40px 20px 15px;
    display: flex;
    margin-left: auto;

    div {
        padding: 10px;

        &::after {
            backgroung: gray;
        }
    }
`;


const Child = styled.div`
    color: ‘blue’
`;


class SelfStyledComponent extends Component {
    render() {
        return (
                <Container>
                    <Child />
                </Container>
        );
    }
}

export default (SelfStyledComponent);

With style components you can create custom components taking advance of all the latest features of CSS and SCSS, you can also handle the styles of the components with variables that are very good when you work with themes._

EDIT September 2018:
Styled Component is not the only library that allows you to create SelfStyled components how was mention in the comments, there are a lot more repos that will bring you an alternative to do the same. You can check it this githup repo written by Michele Bertoli, where you will find a detailed list of libraries to make CSS-in-JS for more information.

As you can see, we can have several ways to do the same, the best option depends on you, your technical staff and what do you expect to build. There’s a big number of benefits of each approach, performance, scalability, reusability, and others. Hope this helps you to understand in how to deal with style while you’re developing in React.

InTheCodeWeTrust

How to survive to Chrome for Android disabling JavaScript for 2G or slower connections?

miguel-penaloza — Tue, 28 Aug 2018 01:45:14 +0000

I found this article and after reading carefully I start thinking a lot about that, I will share with your the link right here.

What basically says is that Google is considering the idea of disable JavaScript in his browsers for slow internet connections in Android and maybe in the future for all his versions.

Looks like an odd move from Google, if this comes true, how the JS world will survive?

Today we cannot talk about Front-end or Web development without talk about JavaScript. Now we have very popular frameworks and libraries like React, Angular, Vue, etc. And almost a new JS framework every month(or week?).

I was thinking in how work with this new scenario, maybe use some progressive Enhancement, create phantoms layout before render anything, and realize that now we not only have to support old browsers but also slow networks.

What scares me about the idea of disable JS when the network become slow, is what new weird behaviours and bugs can we have to support? If now we should handle that a browser will shoot down your app, will we have that states (onJsDisabled?)? How the new net neutrality regulations will affects the speed in our sites?

Maybe I'm a little paranoid, but I wanna know what the community thinks about this? how this posible change can affect us? And how to deal with it?

Best regards.
A worried Dev.

The What, Why and How of React (Routers)

miguel-penaloza — Sat, 25 Aug 2018 14:29:57 +0000

Hi, this is the second article about React fundamentals, today we’re going to talk about one of the most important parts of any web application, The Routing. Every site has a particular way to deal with his navigation.I will try to explain a different approach and try to give you a more clear idea of when you have to use a library and when it's better do it by yourself.

What's Routing?
The routing is basically how you're going to move inside your website. You can start with an index, a home or a dashboard page, then each section of your site will have a domain based on what you want to display, you can have something like this:

The name of the resource of domain: e.g, for a page with the list of books, you will have something like this: books.
The details of the resource: To see the details of one specific resource in this case a book, you will have a url like: books/{id}.
To Create, Manage, Edit, etc. a resource: You can add a description of what do you want to do next to the domain, such as, to create a new book, you can use: books/create and for edit you can use: books/edit.

This’s the most used pattern and works all right. These sites can grow up exponentially, and this is superb because this will give you an idea of Domain and Ownership. Also usually, a domain become in a big module with several logic and with a particular way to navigate.

In almost all the tutorials and documentation of React, they recommend you create a SPA (Single Page Application), and what’s that? Well is just a page that can have inside domains, resources or even others SPAs.

Why routing in React?
The basic idea of a SPA is that you can have a full operative application, in just one page, with only one call to the server, without change url, or at least without to consume a new Page. In most of the React Apps, you have an Index.js, who start everything (redux, sagas, etc.), then you have a Magical component that decides which one of the infinitive number of components that you can have in your code is the one who should be rendered.

This Magical Component who decided which component needs to be rendered is what we can name Router in React.

The idea of having a SPA is that you can get everything what you need at the beginning, resources, images, components, etc. If you’re in the page books, you should not render a new full-page for the books/id, just change the component, and maybe consume a number of services with the information that you may need in the new page without reload the entire page, if we need information to render our page. A Router should provide some useful solutions that help us with our implementation, these are the minimal requirement that we expect of a Router:

Just change the component, not reload the entire page.
The state should be the same, change the route doesn't mean start over again.
Be able to move between all our pages.
The router should be able to know when return a specific page, a default page, a not found page, etc.
Should be able to consume the query params or any information provided in the url, in the best of the cases as a nice a beauty Object.

If we can build or use something that give us these functionalities, we will be able to build a good application that can grow up, and be as complete as you wish. Also, there’s a lot of discussion about file structure and navigation, is common that the domain give you a directory level in your code, you need to care avoid too much nesting. That’s why a good definition of your routing will help you to get a better application.

How use a Router in React?
Here’s the tricky part, as we say before routing is one of the most important parts in our development, basically the navigation flow is what give us the identity of our site, this flow should be natural, intuitive and accord with your business model.

Then, what should I use? A library? Build my own router? If I choose use a library, which one? If I found the library, what version? Sadly if you are in early version of React you will have your options, if you’re in a latest version you will have to use another one, even for the same library base on your React version you should use a oldest or latest version. The navigation in a site can be so custom that the perfect router is something that depends of what you want.

In the official documentation of React, they recommend a list of libraries, with a tinny comment. This’s common in the React documentation. They don’t give you opinions in this kind of themes, they just give some information and after that they just tell you try these options, hope something works for you, that is a real good thing, because they don’t marry with any library and give you the freedom to find what fits for you.

But also in almost all the React tutorials that you can find online they use React Router as the default router library depends of the year of the tutorial you will find that they use a specific version, you need to be careful with this, I’m not going to repeat these tutorials, I will let you here a list with what I think are the best in the web today.

Routing React Apps: The Complete Guide , This one is one of the best and complete, he talks at lot about dependencies, structure files, theoretical concepts and is fantastic to understand the details of the implementation.
React Trainning React Router , This one is a good one too, because they bring you the implementation and give you examples of almost all the Api that React Router provide us.
A Simple React Router v4, this’s excellent because is more practical, is like a mix of the 2 above. Also is for the latest version that works fine with React 16.
React Router Tutorial Official, Is the official documentation, you can be sure that this one should be the most accurate and updated of all.

What I will bring to you, is a simple example of how code it yourself, the idea is understand what is going on with all these libraries are doing, and don’t think in this as a magic thing and no one understand what’s going on.

The first thing that you need to understand is that the route is just a state, that will have the current path. In this example I will use an action that will change the current path to another one, no matter what we pass it to this action, that will be the current path. The first route taken is the one in the window.location, then we only can change the route using the push action.

// Action
import { createAction } from 'redux-actions';

export const push = createAction('PUSH');

// Reducer
import { handleActions } from 'redux-actions';

const { pathname } = window.location

export const routerState = {
    route: 'pathname'
};

export default handleActions({
    PUSH: (state, { payload }) =>
        Object.assign({}, state, {
            route: payload
        })
}, routerState);

The reducer just handles the action, receive a new route and now that’s the current path, you can include more information in this state, like history, and of course more actions, like goBack, goToTheMainPage, goTo404, etc. All this depends of what is your navigation, for simple redirections this’s just fine.

After that we need 2 components, a Router that will handle the decision of which Route should be rendered and the Route that should be a simple component that the Router can read and understand.

import { Component, Fragment, createElement } from 'react';
import { connect } from 'react-redux';

// Route
export const Route = ({ component }) => createElement(component, this.props);

// Router
export const Router = ({ children, route }) => <Fragment>
    { children.find(childrenRoute => route === childrenRoute.props.path) }
</Fragment>

export const mapStateToProps = (state) => ({
    route: state.router.route
});

export default connect(mapStateToProps)(Router);

As you can see here, the Route, just return the Component passed as props and the Router will have as a children all the Routes, then just return the one who match with the current path. The Router receive the current path when we connect the state with the props, and when someone dispatch the action push, our Router will refresh the Component based on that, with this we can navigate between pages without losing the state.

Note:the Fragment is just a fancy React component that I like to use, give you a wrapper without insert any element.
Note 2: The filter is straightforward, but you can extract in a more complex function based on how you want to handle the navigation on your site.
Note 3: You also can define in the Router, a default Route (like home, or 404) when the filter won’t find anything.
Note 4: Also, the Route in this example looks like is not doing anything, but you can include more logic there, that you don’t want to include in the real component, like special validation for the path, extra props that you may need. That’s why I create this Route

And then we have the implementation, here we have a BooksPage, a BooksDetails and a BooksCreate that are just components, with his own logic, and I don’t want to implement any kind of routing logic in this components, In this example we can go on and include as many routes as we want, this is very similar with the React Router implementation, but without all the others functions and components that they provide but we don’t need it right now if our navigation is no so complex.

export class Index extends Component {
    render() {
        return (
            <Router>
               <Route path=“books” component={BooksPage}/>
               <Route path=“books/{id}” component={BooksDetails}/>
            <Route path=“books/create” component={BooksCreate}/>
            </Router>
        );
    }
}

And finally the last thing that we need, is how to change the route? Well from any part of your application you can just dispatch the action push with the new route like this:

dispatch(push(‘books/create’));

The reducer handle this dispatch, when the state changes the Router will update the page keeping our state without refresh the entire page. This router is raw and also there’s a lot of functionalities and logic that are missing (you need to realize that existing libraries already solve these problems), like the change of the url, handle the history, go back to the last page, but this implementation, do the most simple thing: navigate in a SPA.

Hope this helps you to understand what’s a Router, and help you with the decision of which Library use, and how deal with his implementation, also you can try to build it yourself and deal with all your specific requirements of your navigation flows.

What you need to realize is that develop a new Router for your site should not become in a try to reinvent the wheel, also if you decide include a existing library with his implementations, won't become our project in a monster that depends in so many things and you finish installing dependencies of the dependencies just to make one thing works as you want.

Really Hope you've enjoyed reading. See you in the next post.

InTheCodeWeTrust

Previous: The What, Why and How of React (High Order Components)

The What, Why and How of React (High Order Components)

miguel-penaloza — Thu, 19 Jul 2018 21:38:27 +0000

Hi, in these series of articles I will talk about React concepts, try to explain what exactly means that concepts, why you could need it and how use it, in this post we're going to talk about the High Order Components (HOC). In simple words is a pattern to create logic that could be easily reused for other components, and you will see why for the HOCs you need to learn it to understand that you always needed it.

What is a High Order Component?
If we go to the React documentation, there says something like this: is a function that takes a component and returns a new component.. With that definition you maybe can think. why don’t create a class and just extended it? we can have core logic that can be reused in a parent class and extended for all his children yes, but the advantage of use a HOC is that the object of this pattern is return a Component, a simple transaction, I give you my component and the HOC returns a improved new Component with the logic that I need.

So, we can say that a HOC is function, that receive a series of data, properties and a component, include his logic, a context or something else and return a new Component with that logic included, with this pattern you can also be sure that what you need to provide to your component is centralized in one place, and will be consumed always in the same way, like this example:

import React, { Component } from ’react’;

//Create your child component
const  ChildComponent = (props) => (<div> Hello Folks<div>);

// Create your HOC 
const higherOrderComponent = (ChildComponent) => {
    return class extends Component {
    render() {
        return (<ChildComponent props={}/>);
        }
    }
}

// Then You send your ChildComponent and receive a new one with some new props provided for the HOC
const newEnhancedComponent = higherOrderComponent(ChildComponent);

As you can see, the sky's the limit for what you can send or provide in your HOC.

Why should I use this?
When you’re building your components, you should always try to create the most simple components as you can with with the least possible responsibility, but sometimes you find yourself with a big component, with a lot of things, and worst, with a lot of logic that you see is redundant. When you see that you need apply some patterns that will make your code more scalable and reusable, so the first reason is a big component doing a lot of stuffs.

The second and more important reason is when you see that a lot of components (more than one can be a lot sometimes) will use some base logic. These 2 will the perfect reasons for you to try to apply this pattern in your proyect.

How should I use?

In the HOC you can add, edit or even remove some props that you will use in your Child or Enhance Component. You can include a context, or even make a call, subscribe to a service, resolve a promise and handle the response in the HOC, instead of make a dispatch in each componendDidMount and have a lot of repeated code. I will give you a list of the most common examples on where and how we can use this pattern with problems and real-life scenarios.

You already use one, when you use the “connect” of react-redux. If you use redux to hanlde the state and dispatch actions in your code, you're alredy using a HOC, the connect is a HOC that receive your childComponent and your state mappers, and return you a ConnectedComponent. The connect not only gives you the dispatch but also gives you the props and notifies you if these change.


export const mapStateToProps = (state) => ({
   information: state.information
});

export default connect(mapStateToProps)(ChildComponent);

When you need to include an UI component or behaviour to your Child Component. Let's say that you have a component, and you need to include an alert (This can be a modal, change a color, open a hidden text or whatever). And you need that all your components include this extra UI thing. You can just have a HOC that keep the two things together, but each one will be independent with his own responsibilities, like this:

import React, { Component, Fragment } from ’react’;

//Create your child components
const  HelloComponent = (props) => (<div> Hello Folks<div>);
const  GoodBayComponent = (props) => (<div> And Goodbay<div>);
const  AlertComponent = (props) => (<div> I’m an alert <div>);

// Create your HOC 
const componentWithAlert = (ChildComponent) => {
    return class extends Component {
    render() {
        return (
        <Fragment>
            <AlertComponent  />
                        <ChildComponent props={}/>
                </Fragment>
            );
        }
    }
}

const HelloWithAlert = componentWithAlert(<HelloComponent />);
const GoodbayWithAlert = componentWithAlert(<GoodbayComponent />);

As you can see here, we have 2 independent components in one, you also can see that I use Fragment instead of a normal div, but Fragment don’t include you any extra markup or element, and let you group without problems and I prefer that.

When you have a context. Let's say that we have an important information, like the theme with all the brandings, the i18n resources or any kind of information, that you need to provide to all your components. Is very important always try to keep your information in only one source, each component should not be the one of charge of determinate which color or translation based on the language or theme should be used, to handle this situations you need a Context

The Context in React is an API that allow you pass data through the component tree without having to pass props down manually at every level, this’s something very good and useful when we need to handle this kind of problems. The Context needs a Provider and a Consumer, The Provider will have the relevant information and you will need all your childs components wrapped inside the Consumer, so, therefore is a perfect example of where do you need a HOC, you need one to include the theme consumer context logic in the component regardless of which component is, so you don't need to call the ThemeContext everytime you use the component.

import React, { Component } from ’react’;


const ThemeContext = React.createContext({});

class ThemeProvider extends Component {
    render() {
        const {theme } = this.props;
        return (
            <ThemeContext.Provider
                value={theme}
            >
                {Children.only(this.props.children)}
            </ThemeContext.Provider>
        );
    }
}

const withTheme = (ChildComponent) => {
    return class extends Component {
    render() {
        return (
        <ThemeContext.Consumer>
                    {
                        theme =>
                            <ChildComponent
                                theme={theme}
                                {props}
                            />
                    }
                </ThemeContext.Consumer>
            );
        }
    }
}

I will talk more about context in a next post because what is really importanttoday is the HOC. Now you have an example of how a HOC can help you with different problems. And I hope that this blog will help you to better understand this concept and that your code will be better and better. Hope you enjoy. See you in the next post!

InTheCodeWeTrust

Next: The What, Why and How of React (Routers)

When SCRUM is not the correct choice?

miguel-penaloza — Wed, 18 Jul 2018 22:27:55 +0000

Hi, as most of you, I've worked on diverse companies, each one with different cultures, policies and rules, but all they work with people, and at the end the target is the same. Finish what you need to do!, well, sometimes is not that easy, constants delays, changes at the last moment, nightmare deadlines create the conditions to a perfect storm, that usually translate in extra hours, extra efforts and a lot of coffee and stackoverflow.

I've worked in companies with total "Freedom" to manage your projects, where you can choose frameworks, libraries and even the methodologies (and in a few of places the methodologies used is no methodology at all), but in the most of the offices today I found that there's a lot of people who talk about "SCRUM" as the holy grail, the secret tool that will make all your projects finish at time, make all your devs happy and make the company the best company of the world.

Works with SCRUM is not magical, you have roles, ceremonies, and a lot of planification. I’m not saying that SCRUM or any other agile methodologies is a bad option. It's very good if all the member of the team understand his roles, respect the object of the ceremonies and are machines able to estimate with a 100% of accuracy the time and effort for a task. Here you will find a list of common errors that will make SCRUM not your best choice.

When a planning is a status, and the status is a grooming, and the retro is a forum and go on…
Is very common among the member of a team lose the focus of a meeting, for several reasons you can find yourself talking about a task of the next sprint in the current planning. This is usually a sign that you’re not taking the advantage of the current meeting. If the team is not coding, validating of doing something because they have to go to a meeting, they should respect the objective, and is a job for all keeping in that way. Planning is to planning for this sprint, retro is to understand what happends in the sprint, status is to talk about the current status and stand up is to say what're you doing, sounds silly but you should respect your ceremony.

When the stand up is at 11am, but the monday is at 10am, the thursday is at 3pm, the noon days will be at 12pm and for the nights of moonlight will be a 12am.

The stand up should be the most fast, easy and clean meeting of all the ceremonies, what’re you doing?, what are you going to do?, and if you are blocked ask for help. The development work is doing with the head, you shouldn't force your team to stop his work and concentration to attend a stand up in a not schedule time. The Stand up should be always at the same time to create the habit.

When each retro you find yourself with a lot of not finish task, and you’re not open to change anything
This’s the most important reason to don’t use SCRUM. If your team doesn't finish his work and you aren’t open to change anything in the way that you’re doing right now, you’re losing your time. One of the great things that Agile give you is the chance to catch the delays and try to identify the problems, and base on that apply the possible solutions. Remember that you’re in software development the changes are inevitable.

When your have more time of meeting in a week that actually development
This’s a sign that your salary is to assist to meetings and not to development.

When you can pass weeks without talking with the PMs, or any of the owners of the product.
The communication is vital for any team and project. If your team is working hard to get the project done, but any of the PMs are there to check what’s going on, involve in the creation of the stories and the definition of the goals. You’re not in SCRUM, you’re in a bad implemented Waterfall

When your team is always talking about how much they hate SCRUM
All the team should be ok with the methodology. All the team should be compromise with the way of the things are been doing. The team using SCRUM should be the most Agile fanboys of your company, otherwise you will have a not motivated team.

How you see this blog should be named “When you don’t use SCRUM correctly”, but the name was decided already, hope this small list of common errors helps you to understand better SCRUM, and share with your team to see if you're on the correct path.

In the code we Trust!