ReactFoo Mumbai

ReactFoo Mumbai

On React, alternatives to React, ReactNative and front-end engineering

##About ReactFoo Mumbai

ReactFoo Mumbai is an event for JavaScript, front-end adnd mobile engineers. The conference will feature talks on:

  1. Latest features of React
  2. Webpack, GraphQL and Apollo
  3. React Native
  4. Front-end workflows and design systems
  5. CSS and React

Format #

ReactFoo Mumbai is a single-day event with full-length and crisp talks, and Birds Of Feather (BOF) sessions on how to grow your career as a front-end engineer, and on state management.

On 27 May, we are hosting a hands-on workshop on GraphQL and Apollo conducted by Kiran Abburi. Workshop tickets have to be purchased separately.

Who should attend #

  1. JS engineers from enterprises.
  2. JS engineers from startups.
  3. Architects.
  4. Cross-platform mobile developers.
  5. Front-end engineers.

Why you should attend? #

  1. To learn from and network with peers from the industry.
  2. To gain insights from case studies of practical implementation, and evaluate ReactJS and React Native for your work.
  3. To program better with React and React Native.

If you are attending ReactFoo Mumbai, submit a flash talk – of 5 mins – about a project you are working on or a tool you have discovered and that you’d like the community to benefit from. #

Dates: #

ReactFoo Mumbai conference – 26 May 2018 at ISDI DICE, Lower Parel, Mumbai.
GraphQL and Apollo workshop – on 27 May 2018 at Endurance International, Goregaon, Mumbai

##Contact details:
For more information about speaking, ReactFoo, sponsorships, tickets, or any other information contact or call 7676332020.

Event website:

Hosted by

A community - for and of - front-end engineers to share experiences with ReactJS, performant apps with React, crafting better User Interfaces (UI) with React and GraphQL ecosystem. ReactFoo also discusses design patterns and user experience. more

Aakash N S


Unit Testing for Fun and Profit

Submitted Mar 30, 2018

I’ve been using React for almost 5 years, but I hadn’t written a single test till quite recently. I always felt that testing is difficult, time consuming and mostly unnecessary. But after trying it, I realized that it’s actually really really easy to test React & Redux applications, and requires almost zero setup to get started. It’s totally worth the investment!

Besides, it doesn’t have to be “all or nothing”. You can test specific parts of application logic in isolation, and save yourself from hours of mindless debugging. Moreover, writing tests also acts as a forcing function to write modular, encapsulated and testable code.

This talk should be accessible to most developers familiar with React JS and Redux.

Outline #

I plan to spend about 5 minutes talking about each of the following topics:

  • Why, when and what to test?
  • Testing React+Redux apps
  • Writing testable code
  • Testing Redux reducers and action creators
  • Testing presentational components using snapshots
  • Mocking network requests and testing asynchronous code
  • Putting it all together

The talk will involve some live coding and testing.

Following is a detailed outline of the talk:

Introduction to Unit Testing in React #

(7-8 minutes)

Unit testing refers to the testing of individual components or ‘units’ of an application in isolation, to validate that each unit is working as expected, and identify errors and bugs before shipping the code to production. Unit testing is also helpful while refactoring code, to ensure that no unexpected changes or bugs are introduced during the refactor.

The first step for testing is to ensure that the codebase is cleanly separated into various parts like Style Guide presentational components, reducers, action creators, containers, pages etc., we can easily test each part in isolation. We’ll use Jest as our testing framework, since it is automatically installed with create-react-app and is really easy to use.

Tests can be executed by running the following command from the root directory of a React application:

npm run test

Tests are run in watch mode by default, which means they are re-executed every time source files are modified and saved. This makes it really easy to write code and monitor the test results side-by-side.

<Some simple live coding examples of testing>

Unit Testing Reducer & Action Creators #

(5 minutes)

Since reducers and action creators are just plain functions, we can test them in isolation by providing some sample arguments to the functions, and asserting that the outputs are as expected.

<Some simple live coding examples of testing>

Unit Testing Async (Thunk) Action Creators #

(7-8 minutes)

Unit testing reducers and standard action creators in isolation is simple, since they are pure functions. However, the same isn’t true for asynchronous action creators, for two reasons:

They are not pure functions i.e. they have side-effects e.g. making network requests or accessing local storage. Depending on the network can make the tests slow and flaky. Also, it’s impractical to maintain a server simply for running unit tests.
They contain asynchronous code i.e. they have promises and callbacks which are invoked in the future, long after the original function has returned.
To address the first issue, we’ll create mock functions to replace the network calls, and the use those for testing.

<Some simple live coding examples of mocking & testing using mocks>

Snapshot Testing of Presentational Components #

(7-8 minutes)

Snapshot testing is used to ensure that our UI does not change in unexpected ways. The basic idea is to capture a sample snapshot of the DOM tree rendered by a React component and compare against it whenever there is a code change.

<Some simple live coding examples of snapshot testing>

Unit Testing Business Logic & Miscellaneous Code #

(5 minutes)

Apart from reducers, action creators, presentational components, container components etc. our application also contains several miscellaneous and utility functions, which are used all over the application. They are generally placed in util directories adjacent to containers, reducers, pages etc.

Utility functions are generally pure functions, without side effects like making network requests, accessing local storage, modifying global variables etc. This makes it really easy to test them in isolation, just like reducers and action creators.

Because pure functions are easy to test, it is a good idea to extract parts of business logic into small, standalone utility functions, instead of writing the logic inline within React components. It also promotes code reuse.

<Some simple live coding examples of testing>

Closing thoughts and Q&A - 5 minutes

Requirements #


  • React JS
  • Redux

Speaker bio #

I’ve been using React JS since 2013, and React Native since its initial release, so I’m well versed with the tools, libraries, community best practices etc. As a part of my consulting and freelance work, I have helped several teams adopt React JS and related tools & technologies (React Router, Redux, Webpack etc.) for large enterprise-scale applications.

I’ve also created several open source projects related to React JS and React Native, the most popular of which is ‘react-native-dialogs’ which has 400+ stars on Github and is used by 2500+ developers every month (more at ) . Apart from this, I also blog frequently about React/React Native and related topics at .


{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

A community - for and of - front-end engineers to share experiences with ReactJS, performant apps with React, crafting better User Interfaces (UI) with React and GraphQL ecosystem. ReactFoo also discusses design patterns and user experience. more