Kelvin Liang's Blog

How to write tests for React in 2020 - part 2

Kelvin Liang — Thu, 18 Jun 2020 10:14:28 GMT

Writing React Test with React recommend libraries - Jest & Testing Library for React Intermediate users.

Please Note

In this article, I will explore more advanced concepts in React Testing, I hope you find them helpful for your situations. If you are a beginner in React or new to testing, I would suggest you check out Part 1 Here to have some fundamental knowledge before continue, thanks!

First, let's look at the Accessibility Test.

Front-end development is all about visualization and interacting with end-users, Accessibility Test can ensure our apps can reach as many as possible users out there.

From - https://reactjs.org/docs/accessibility.html

Writing Accessibility Test for every aspect of your app seems very intimidated, but thanks for Deque Systems - A company dedicated on improving software accessibility by offering Axe testing package freely available online, we can now easily leverage the expertise from many senior developers around the world by importing Jest-axe along with Jest Library to test a web app's accessibility.

npm install --save-dev jest-axe

yarn add --dev jest-axe

With the package install, we can add the Accessibility Test into a project like this:

// App.test.js
import React from 'react';
import App from './App';
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

describe('App', () => {
  test('should have no accessiblity violations', async () => {
    const { container } = render(<App />);
    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });
});

It will help to ensure your FrontEnd Development complies with the latest version of WCAG(Web Content Accessibility Guidelines). For example, if you assign a wrong role to your Navigation bar component,

// ./components/navBar.js
...
"navbar" role='nav'>
   ...
</div>
...

It will alert you like below:

Check out a List of WAI-ARIA Roles - Here.

Replace nav with navigation role as below, the test will pass.

// ./components/navBar.js
...
"navbar" role='navigation'>
   ...
</div>
...

As we can see above, this test will help ensure you follow the WCAG(Web Content Accessibility Guidelines) standard so your app can reach most of the people out there.

Second, adding a Snapshot Test.

Snapshot tests are a very useful tool whenever you want to make sure your UI does not change unexpectedly. -- From Jest

You can put the test on the entire app or one specific component.

They can serve different purposes during the development cycle, you can either use Snapshot Test to ensure your app's UI doesn't change over time or compare the differences between the last snapshot with current output to iterate through your development.

Let's take the example of writing a test for the entire App to show you how to write a snapshot test.

// App.test.js
import React from 'react';
import App from './App';

import renderer from 'react-test-renderer';
...


describe('App', () => {
  ...

  test('snapShot testing', () => {
    const tree = renderer.create(<App />).toJSON();
    expect(tree).toMatchSnapshot();
  });

});

If this is the first time this test run, Jest will create a snapshot file(a folder "__snapshots__" will create as well) looks similar to this.

// App.test.js.snap
// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`App snapShot testing 1`] = `

  
    ....

With this test in place, once you make any change over the DOM, the test will fail and show you exactly what is changed in a prettified format, like the output below:

In this case, you can either press u to update the snapshot or change your code to make the test pass again.

If you adding snapshot test at the early stage of development, you might want to turn off the test for a while by adding x in front of test, to avoid getting too many errors and slowing down the process.
 xtest('should have no accessiblity violations', async () => {
   ...
  });

Third, let's see how to test a UI with an API call.

It is fairly common now a frontend UI has to fetch some data from an API before it renders its page. Writing tests about it becomes more essential for the Front End development today.

Now, let's look at the process and think about how we can test it.

When a condition is met (such as click on a button or page loaded), an API call will be triggered;
When data come back from API, usually response need to parse before going to next step (optional);
When having proper data, the browser starts to render the data accordingly;
On the other hand, if something goes wrong, an error message should show up in the browser.

In FrontEnd development, we can test things like below:

whether the response comes back being correctly parsed?
whether the data is correctly rendered in the browser in the right place?
whether the browser show error message when something goes wrong?

However, we should not:

Test the API call
Call the real API for testing

Because most of the time, API is hosted by the third party, the time to fetch data is uncontrollable. Besides, for some APIs, given the same parameters, the data come back may vary, which will make the test result unpredictable.

For testing with an API, we should:

Use Mock API for testing and return fack data
Use fake data to compare UI elements to see if they match

If you got the ideas, let's dive into the real code practice.

Let's say we want to test the following News page component, where it gets the news from getNews API call and render them on the browser.

// ./page/News.js
import React, { useState, useEffect } from 'react';
import getNews from '../helpers/getNews';
import NewsTable from '../components/newsTable';

export default () => {
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(true);
  const [errorMsg, setErrorMsg] = useState('');
  const subreddit = 'reactjs';

  useEffect(() => {
    getNews(subreddit)
      .then(res => {
        if (res.length > 0) {
          setPosts(res);
        } else {
          throw new Error('No such subreddit!');
        }
      })
      .catch(e => {
        setErrorMsg(e.message);
      })
      .finally(() => {
        setLoading(false);
      });
  }, [])

  return (
    <>
      <h1>What is News Lately?h1>
      <div>
        {loading && 'Loading news ...'}
        {errorMsg && <p>{errorMsg}p>}
        {!errorMsg && !loading && <NewsTable news={posts} subreddit={subreddit} />}
      div>
    
  )
}

First, let's create a __mocks__ folder at where the API call file located. (In our case, the API call file call getNews.js), create the mock API call file with the same name in this folder. Finally, prepare some mock data inside this folder.

Mock API file(getNews.js) should look sth like below -

// ./helpers/__mocks__/getNews.js
import mockPosts from './mockPosts_music.json';

// Check if you are using the mock API file, can remove it later
console.log('use mock api'); 

export default () => Promise.resolve(mockPosts);

Vs. Real API Call

// ./helpers/getNews.js
import axios from 'axios';
import dayjs from 'dayjs';

// API Reference - https://reddit-api.readthedocs.io/en/latest/#searching-submissions

const BASE_URL = 'https://api.pushshift.io/reddit/submission/search/';

export default async (subreddit) => {
  const threeMonthAgo = dayjs().subtract(3, 'months').unix();
  const numberOfPosts = 5;

  const url = `${BASE_URL}?subreddit=${subreddit}&after=${threeMonthAgo}&size=${numberOfPosts}&sort=desc&sort_type=score`;

  try {
    const response = await axios.get(url);
    if (response.status === 200) {
      return response.data.data.reduce((result, post) => {
        result.push({
          id: post.id,
          title: post.title,
          full_link: post.full_link,
          created_utc: post.created_utc,
          score: post.score,
          num_comments: post.num_comments,
          author: post.author,
        });
        return result;
      }, []);
    }
  } catch (error) {
    throw new Error(error.message);
  }
  return null;
};

As we can see from the above codes, a mock API call just simply return a resolved mock data, while a real API call need to go online and fetch data every time the test run.

With the mock API and mock data ready, we now start to write tests.

// ./page/News.test.js
import React from 'react';
import { render, screen, act } from '@testing-library/react';
import { BrowserRouter as Router } from "react-router-dom";
import News from './News';

jest.mock('../helpers/getNews');  //adding this line before any test.

// I make this setup function to simplify repeated code later use in tests.
const setup = (component) => (
  render(
   // for react-router working properly in this component
  // if you don't use react-router in your project, you don't need it.
    
      {component}
    </Router>
  )
);

...

Please Note:
jest.mock('../helpers/getNews');
Please add the above code at the beginning of every test file that would possibly trigger the API call, not just the API test file. I make this mistake at the beginning without any notifications, until I add console.log('call real API') to monitor calls during the test.

Next, we start to write a simple test to check whether a title and loading message are shown correctly.

// ./page/News.test.js
...
describe('News Page', () => {
  test('load title and show status', async () => {
    setup(<News />);  //I use setup function to simplify the code.
    screen.getByText('What is News Lately?'); // check if the title show up
    await waitForElementToBeRemoved(() => screen.getByText('Loading news ...'));
  });
...
});

With the mock API being called and page rendering as expected. We can now continue to write more complex tests.

...
test('load news from api correctly', async () => {
    setup(<News />);
    screen.getByText('What is News Lately?');

    // wait for API get data back
    await waitForElementToBeRemoved(() => screen.getByText('Loading news ...'));

    screen.getByRole("table");  //check if a table show in UI now
    const rows = screen.getAllByRole("row");  // get all news from the table

    mockNews.forEach((post, index) => {
      const row = rows[index + 1];  // ignore the header row

       // use 'within' limit search range, it is possible have same author for different post
      within(row).getByText(post.title);  // compare row text with mock data 
      within(row).getByText(post.author); 
    })

    expect(getNews).toHaveBeenCalledTimes(1); // I expect the Mock API only been call once
    screen.debug(); // Optionally, you can use debug to print out the whole dom
  });
...

Please Note
 expect(getNews).toHaveBeenCalledTimes(1);
This code is essential here to ensure the API call is only called as expected.

When this API call test passes accordingly, we can start to explore something more exciting!

As we all know, an API call can go wrong sometimes due to various reasons, how are we gonna test it?

To do that, we need to re-write our mock API file first -

// // ./helpers/__mocks__/getNews.js
console.log('use mock api');  // optionally put here to check if the app calling the Mock API
// check more about mock functions at https://jestjs.io/docs/en/mock-function-api
const getNews = jest.fn().mockResolvedValue([]); 
export default getNews;

Then we need to re-write the setup function in News.test.js file.

// ./page/News.test.js
...
// need to import mock data and getNews function
import mockNews from '../helpers/__mocks__/mockPosts_music.json';
import getNews from '../helpers/getNews';
...
// now we need to pass state and data to the initial setup
const setup = (component,  state = 'pass', data = mockNews) => {
  if (state === 'pass') {
    getNews.mockResolvedValueOnce(data);
  } else if (state === 'fail') {
    getNews.mockRejectedValue(new Error(data[0]));
  }

  return (
    render(
      <Router>
        {component}
      Router>
    ))
};
...

I pass the default values into the setup function here, so you don't have to change previous tests. But I do suggest pass them in the test instead to make the tests more readable.

Now, let's write the test for API failing.

// ./page/News.test.js
...
test('load news with network errors', async () => {
    // pass whatever error message you want here.
    setup(<News />, 'fail', ['network error']);
    screen.getByText('What is News Lately?');

    await waitForElementToBeRemoved(() => screen.getByText('Loading news ...'));
    screen.getByText('network error');

    expect(getNews).toHaveBeenCalledTimes(1);
  })
...

Finally, you can find the complete test code from here.

Please Note The above examples are just simple test cases for demonstration purposes, in real-world scenarios, the tests would be much more complex. You can check out more testing examples from my other project here.

Photo by ThisisEngineering RAEng on Unsplash

Final words

I followed the best practices Kent C. Dodds suggested in his blog post - Common mistakes with React Testing Library published in May 2020, in which you might find my code is slightly different from Test-Library Example (I think soon Kent will update the docs as well), but I believe that should be how we write the test in 2020 and onward.

I use both styled-componet and in-line style in this project to make UI look better, but it is not necessary, you are free to use whatever CSS framework in react, it should not affect the tests.

Finally, Testing is an advanced topic in FrontEnd development, I only touch very few aspects of it and I am still learning. If you like me, just starting out, I would suggest you use the examples I show here and in my previous article to play around with your personal projects. Once you master the fundamentals, you can start to explore more alternatives on the market to find the best fit for your need.

Resources and Article I referenced to finished this article:

Special Thanks for Johannes Kettmann and his course ooloo.io.

I have learned a lot in the past few months from the course and some study fellows from the course - Martin Kruger and ProxN, who help inspire me a lot to finish this testing series articles.

Below are what I have learned,

Creating pixel-perfect designs

Planning and implementing a complex UI component

Implement data fetching with error handling

Debugging inside an IDE

Writing integration tests

Professional Git workflow with pull requests

Code reviews

Continuous integration

This is the finishing project as the outcome.

How to write tests for React in 2020 - part 1

Kelvin Liang — Mon, 01 Jun 2020 10:37:56 GMT

Write React Test with react recommend libraries — Jest & React Testing Library for a complete beginner.

From https://reactjs.org/docs/test-utils.html#overview

This article is intended to who just start to learn React and wonder how to write some simple tests with their React applications. And just like most of the people start to create React app using create-react-app, I would start with it as well.

First, let's start with the default example.

Default Dependencies with create-react-app (2020/05/22)

"dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.3.2",
    "@testing-library/user-event": "^7.1.2",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-scripts": "3.4.1"
  }

There is one test already written to help you to start.

// src/App.test.js
import React from 'react';
import { render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  const { getByText } = render(<App />); //render is from @testing-library/react
  const linkElement = getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument(); //expect assertion is from Jest
});

If you run the command $ yarn test App, you will see a similar result as the following:

With the default create-react-app setting, you can start to write a test without install or configure anything.

From the example above, we should learn -

Where and how I can put my test files? - as you can see App.test.js file is put next to App.js file in the same folder, and it put .test.js suffix after App component name as its filename. It is the default conventions suggested by create-react-app team (link here).

Jest and React Testing Library are the tools chain behind the test. They both are ship with create-react-app by default.

// setupTests.js
// Jest is importing from a global setup file if you wonder
import '@testing-library/jest-dom/extend-expect';

I am creating a NavBar component that contains links and logo in it.

First, I would start writing test without writing the actual component (Test Drive Development).

// navBar.test.js
import React from 'react'; 
// use "screen" - a newer way to utilize query in 2020 
import { render, screen } from '@testing-library/react'; 
import NavBar from './navBar'; // component to test

test('render about link', () => {
  render(<NavBar />);
  expect(screen.getByText(/about/)).toBeInTheDocument();
})

The test will fail first since I didn't write any code in navBar.js component yet.

With code below in navBar.js, the test should pass now.

// navBar.js
import React from 'react';

const NavBar = () => (
  <div className="navbar">
    <a href="#">
      about
    a>
  div>
);

export default NavBar;

For now, you should learn:

expect( ... ).toBeInTheDocument() assertion is from Jest.
render(); and screen.getByText(/about/) is from Testing Library.
Jest and React Testing Library work together to make writing tests in React easy.
screen.getByText(/about/) use "getByText" instead of select by class name is because React Testing Library adapting the mindset of focus on User experiences over implementation detail.
To learn more to expand and alter the test, you can check out the following resources:
- Jest Testing with React App Tutorial
- React Testing Library syntax cheatsheet

Now let’s expand the test and component to make it more real -

// navBar.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import NavBar from './navBar';

// include as many test cases as you want here
const links = [
  { text: 'Home', location: "/" },
  { text: 'Contact', location: "/contact" },
  { text: 'About', location: "/about" },
  { text: 'Search', location: "/search" },
];

// I use test.each to iterate the test cases above
test.each(links)(
  "Check if Nav Bar have %s link.",
  (link) => {
    render(<NavBar />);
//Ensure the text is in the dom, will throw error it can't find
    const linkDom = screen.getByText(link.text); 

//use jest assertion to verify the link property
    expect(linkDom).toHaveAttribute("href", link.location);
  }
);

test('Check if have logo and link to home page', () => {
  render(<NavBar />);
        // get by TestId define in the navBar
    const logoDom = screen.getByTestId(/company-logo/); 
        // check the link location
    expect(logoDom).toHaveAttribute("href", "/"); 
    //check the logo image
  expect(screen.getByAltText(/Company Logo/)).toBeInTheDocument(); 
});

This is what a NavBar component usually look like (maybe need to add some styles).

// navBar.js
import React from 'react';

const NavBar = () => (
  <div className="navbar">
    <a href="/" data-testid="company-logo">
      <img src="/logo.png" alt="Company Logo" />
    a>

    <ul>
      <li>
        <a href="/"> Home a>
      li>
      <li>
        <a href="/about"> About a>
      li>
      <li>
        <a href="/contact"> Contact a>
      li>
      <li>
        <a href="/search"> Search a>
      li>
    ul>
  div>
);

export default NavBar;

After writing a test for static content, let's write a test for more dynamic content - a signup form.

First, let's think in TDD way - what we need in this signup form (no matter how it look):

An input field for name, which only allows string between 3 to 30 long.
An input field for email, which can check whether it is a valid email address.
An input field for password, which can check its complexity (at least 1 number, 1 string in lower case, 1 string in upper case, 1 special character)
A submit button.
All 3 inputs above are required, can't be empty.

Now, let's write the test.

/*  Prepare some test cases, ensure 90% edge cases are covered.
    You can always change your test cases to fit your standard
*/
const entries = [
  { name: 'John', email: 'john_doe@yahoo', password: 'helloworld' },
  { name: 'Jo', email: 'jo.msn.com', password: 'pa$$W0rd' },
  { name: '', email: 'marry123@test.com', password: '123WX&abcd' },
  { name: 'kent'.repeat(10), email: 'kent@testing.com', password: 'w%oRD123yes' },
  { name: 'Robert', email: 'robert_bell@example.com', password: 'r&bsEc234E' },
]

Next, build up the skull of the test.

// signupForm.test.js
// this mostly a input validate test
describe('Input validate', () => {
  /* 
   I use test.each to iterate every case again
   I need use 'async' here because wait for 
   validation is await function 
  */     
  test.each(entries)('test with %s entry', async (entry) => { 
    ...

    })
})

Now, let building the block inside the test.

// signupForm.test.js
...
test.each(entries)('test with %s entry', async (entry) => { 
//render the component first (it will clean up for every iteration    
    render(<SignupForm />); 

/*  grab all the input elements. 
I use 2 queries here because sometimes you can choose
how your UI look (with or without Label text) without
breaking the tests
*/     
    const nameInput = screen.queryByLabelText(/name/i)
      || screen.queryByPlaceholderText(/name/i);
    const emailInput = screen.getByLabelText(/email/i)
      || screen.queryByPlaceholderText(/email/i);
    const passwordInput = screen.getByLabelText(/password/i)
      || screen.queryByPlaceholderText(/password/i);

/* use fireEvent.change and fireEvent.blur to change name input value
and trigger the validation
*/
    fireEvent.change(nameInput, { target: { value: entry.name } }); 
    fireEvent.blur(nameInput); 

/* first if-statement to check whether the name is input.
second if-statement to check whether the name is valid.
'checkName' is a utility function you can define by yourself.
I use console.log here to show what is being checked.  
*/
if (entry.name.length === 0) {
      expect(await screen.findByText(/name is required/i)).not.toBeNull();
      console.log('name is required.');
    }
    else if (!checkName(entry.name)) {
      // if the name is invalid, error msg will showup somewhere in the form
      expect(await screen.findByText(/invalid name/i)).not.toBeNull();
      console.log(entry.name + ' is invalid name.');
    };

// With a similar structure, you can continue building the rest of the test.
        ...

/*  Remember to add this line at the end of your test to 
avoid act wrapping warning.
More detail please checkout Kent C.Dodds's post:
(He is the creator of Testing Library)
https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning
*/
     await act(() => Promise.resolve()); 
})
...

For the complete Testing code, please find them here.

Ok, now the test is done (maybe we will come back to tweak a bit, but let's move on for now), let's write the component.

// signupForm.js
import React from 'react';
/* 
I borrow the sample code from formik library with some adjustments
https://jaredpalmer.com/formik/docs/overview#the-gist
*/
import { Formik } from 'formik';
/* 
For validation check, I wrote 3 custom functions.
(I use the same functions in test)
*/
import {
  checkName,
  checkEmail,
  checkPassword,
} from '../utilities/check';

const SignupForm = () => (
  <div>
    <h1>Anywhere in your app!h1>
    <Formik
      initialValues={{ name: '', email: '', password: '' }}
      validate={values => {
        const errors = {};
        if (!values.name) {
          errors.name = 'Name is Required'
        } else if (!checkName(values.name)) {
          errors.name = `invalid name`;
        }

        if (!values.email) {
          errors.email = 'Email is Required';
        }
        else if (!checkEmail(values.email)) {
          errors.email = 'Invalid email address';
        }

        if (!values.password) {
          errors.password = 'Password is Required';
        } else if (!checkPassword(values.password)) {
          errors.password = 'Password is too simple';
        }

        return errors;
      }}
      onSubmit={(values, { setSubmitting }) => {
        setTimeout(() => {
          alert(JSON.stringify(values, null, 2));
          setSubmitting(false);
        }, 400);
      }}
    >
      {({
        values,
        errors,
        touched,
        handleChange,
        handleBlur,
        handleSubmit,
        isSubmitting,
        /* and other goodies */
      }) => (
          <form onSubmit={handleSubmit}>
            <label>
              Name:
            <input
                type="text"
                name="name"
                placeholder="Enter your name here"
                onChange={handleChange}
                onBlur={handleBlur}
                value={values.name}
              />
            label>

            <p style={{ 'color': 'red' }}>
              {errors.name && touched.name && errors.name}
            p>

            <label>
              Email:
            <input
                type="email"
                name="email"
                placeholder="Your Email Address"
                onChange={handleChange}
                onBlur={handleBlur}
                value={values.email}
              />
            label>
            <p style={{ 'color': 'red' }}>
              {errors.email && touched.email && errors.email}
            p>

            <label>
              Password:
            <input
                type="password"
                name="password"
                placeholder="password here"
                onChange={handleChange}
                onBlur={handleBlur}
                value={values.password}
              />
            label>

            <p style={{ 'color': 'red' }}>
              {errors.password && touched.password && errors.password}
            p>

            <button type="submit" disabled={isSubmitting}>
              Submit
          button>
          form>
        )}
    </Formik>
  div>
);

export default SignupForm;

And the form will look similar like below (no much style, but good enough for our purpose), And with wrong input, the error message will show below the input:

If you finished the test above, now the test should all pass, run yarn test --verbose in your command line, you should see something similar like this.with the verbose option and console.log message, you can see how each case is being tested and which one is a good case and which one is not.

For more testing code examples and different cases, please check out my repo here.

Final words.

It is difficult for a beginner to learn all of it once so just slow down if it's overwhelming. It took me at least an entire week to learn the basics, and this is just the beginning of writing tests for React applications.

It is a hard topic to grasp, but I believe it is worthy to spend some time on it if you want to become a Pro FrontEnd developer.

And the good news is, you have a good start, you should now know how to leverage Jest and React Testing Library to write tests around your react components, and you can start to explore other libraries and solutions out there with this good foundation.

If you like to learn more about React Testing, I have another article here talking about accessibility test, snapshot test, mock API test, and more, go check it once you master the tests here.

Resources I have referred to this article:

Common Mistakes with React Testing by Kent C.Dodds
Fix the not wrapped act warning by Kent C.Dodds
My Experience moving From Enzyme to React Testing Library (Opinion about which library to use for React Testing)
Testing Library Recipes (More resources learn about React Testing Library)
Inside a dev’s mind — Refactoring and debugging a React test By Johannes Kettmann (I started to learn React Test with this article, but it is much more advance, I will write more about it later)

Special Thanks to ooloo.io and Johannes Kettmann:

For someone who wants to become a job-ready FrontEnd developer, I would recommend trying a course from ooloo.io. It introduces concepts such as - Creating pixel-perfect design, Planning and implementing a complex UI component, Debugging inside IDE, and Writing integration tests, which are not necessary would see from most of the online tutorials or courses. And Yes, I got a lot of inspiration from this course which helped me write up this article eventually.

This article originally posted in dev.to

Why I should check my code's performance?

Kelvin Liang — Wed, 17 Jul 2019 15:39:55 GMT

As a #CodeNewbie, I usually don't care how I solved a coding challenge as long as I am getting the result (maybe I do care a bit about elegance, cleanness of the codes). Until one day, I saw the differences between my code and my teammates' code:
Comparison:
     Yunus's method :   119030.6 i/s
     Ebuka's method :    63232.0 i/s - 1.88x  slower
    Kelvin's method :     6848.0 i/s - 17.38x  slower
I changed my mind since.

Below, I will explore the reasons why I think checking the performance of your code is important, and how we can do it.

First of all, it is fun.

Photo by Ilya Pavlov on Unsplash

When doing a coding challenge, it is fun to compete with your coding partners to see who can solve the same problem first.

The same logic applies for code performance checking, the differences are, not only you can compete with your coding partners or teammates, but also yourself, and even the team of the ruby contributors.

Below is one example -

The challenge - return the median of an unsorted array (size of the array is always an odd number).

# get the median by search every number in the array

def median(array)
  array.each do |x|
    count = 0
    array.each {|y| count += 1 if y <= x}
    return x if count == array.size/2 + 1
  end
end

# Use Ruby build-In sort to find the array

def median_r(array)
  array.sort[array.size/2]  
end

if run above methods in my laptop, I almost can get the same result at the same time. But are the codes really the same? Thanks for the benchmark tools from Evan Phoenix, I can benchmark these 2 blocks of codes from my laptop by just adding a few lines of code.

Benchmark.ips do |x|
    x.config(:time => 3, :warmup => 2)

    x.report("Kelvin's Method") {median(list)}
    x.report("Ruby Sort") {median_r(list)}

    x.compare!    
  end

Please note - All coding block should be in the same file

The result -

# Benchmark test with [7, 3, 9, 8, 2, 1, 5]
Comparison:
               Ruby Sort:  1098170.4 i/s
     Kelvin's Method:   171681.3 i/s - 6.40x  slower

ok, so my method is slower than Ruby build-in method, that is reasonable, I just learn Ruby, I can't compete with the group sophisticate ruby developer. (I will try later !!)

How about my teammates' code?

# Benchmark test with [7, 3, 9, 8, 2, 1, 5]
Comparison:
           Ruby Sort:  1098147.9 i/s
      Yunus's Method:   528263.9 i/s - 2.08x  slower
      Kelvin's Method:   173466.6 i/s - 6.33x  slower

Wow, my teammate's code ran 3 times faster than mine, I want to find out why and how.

Finally, I use my own sorting method (Advance Quick Sort) created another version of find median method.

def median_k1(array)
  temp = array.clone .    #for not modify the original array
  advanced_quicksort(temp) 
  temp[array.size/2]
end

and run the benchmark test again.

# Benchmark test with [7, 3, 9, 8, 2, 1, 5]
Comparison:
           Ruby Sort:              1087509.0 i/s
      Yunus's Method:        525471.1 i/s - 2.07x  slower
     Kelvin's Method:         166969.8 i/s - 6.51x  slower
Kelvin's Adv Sort Method:    151304.6 i/s - 7.19x  slower

ok, it runs even slower, but it is fun when we have tried and see the result, isn't it? (just like we watching horse racing, but we competing with code but not horse)

Sometime, I will repeat the above processes over and over again until I can't think of any way to improve my code.

I might end up re-write my code or just have deeper understand the code I wrote. The point is, I could write better, faster code later, I enjoy more learning to code, it gives me motivations to move forward.

Second, It helps me learn how to code at a deeper level.

When doing the coding challenges with my team, we usually wouldn't notice the differences between solutions, therefore, we would never discuss whether one solution is better than the other, because they all give same results.

But with the comparisons, we suddenly have more topics to discuss and competing with, every team member wants to write faster code, then we will learn from each other.

For example, one of my team members tries to study which Ruby enumerable methods are more efficient given the same situation. His Article

Also, from the sample I mentioned earlier, once I saw the performance of my codes, I have the desires to dig deeper on how and why my code is run slower, even I just try to find a way to beat myself.

Beside comparing codes, actually, there is one more thing we can test - inputs (or DataSet), some code work better with one input but work worse with another. here is some example:

# Benchmark test with [7, 3, 9, 8, 2, 1, 5]
Comparison:
           Ruby Sort:  1041021.5 i/s
      Yunus's Method:   500895.3 i/s - 2.08x  slower
     Kelvin's Method:   165341.8 i/s - 6.30x  slower
    Kelvin's AdvSort:   141434.0 i/s - 7.36x  slower

The situation is changing with an almost sorted array...

# Benchmark test with [0, 1, 2, 4, 6, 5, 3, 8, 9]
Comparison:
           Ruby Sort:   926798.7 i/s
     Kelvin's Method:   253107.0 i/s - 3.66x  slower
      Yunus's Method:   117203.3 i/s - 7.91x  slower
    Kelvin's AdvSort:    68769.3 i/s - 13.48x  slower

The table flipped again with a larger dataset ...

# Benchmark test with an array with 100 unsorted numbers
Comparison:
           Ruby Sort:   108950.9 i/s
    Kelvin's AdvSort:     4935.3 i/s - 22.08x  slower
      Yunus's Method:     4794.6 i/s - 22.72x  slower
     Kelvin's Method:     1216.6 i/s - 89.55x  slower

Interesting, right? After such tests, my team and I wouldn't look at the code the same way as before, we now understand there is no absolute best code, some code work better with one situation, some work better with another situation.

There are many more examples to show how we dig deeper into the code to learn more, the ability to see the performances of our code help us keep doing that.

I guess that is also why most of the coding challenge platform such as LeetCode want to show you the performance after you finish it.

Finally, I think it will matter at work.

When solving a small problem such as coding challenges, even we can see the difference from a performance test, but that comparison might be just 0.001 seconds vs 0.01 seconds, nobody can really tell and it has very little effect in the real world.

But all it is because coding challenges usually only employ very small dataset to prove the concepts or explain the algorithm easily. The story will be totally different once start uses bigger datasets.

# Benchmark with 1,000 size array
Comparison:
           Ruby Sort:     6454.5 i/s
    Kelvin's AdvSort:      336.0 i/s - 19.21x  slower
      Yunus's Method:       45.5 i/s - 141.97x  slower
     Kelvin's Method:       20.1 i/s - 321.18x  slower

# Benchmark with 10,000 size array
Comparison:
           Ruby Sort:      477.6 i/s
    Kelvin's AdvSort:       27.4 i/s - 17.40x  slower
      Yunus's Method:        0.7 i/s - 681.21x  slower
     Kelvin's Method:        0.4 i/s - 1254.91x  slower

The datasets sizes are 1,000 and 10,000 respectively, one of my methods can't even finish in 3 seconds (I pre-set as 3 seconds this benchmark test).

Now I can really feel the difference, it is 5 Seconds. vs 0.005 Seconds, If I put it into my web application, my web app might barely work once my products categories close to 10k.

My first code wouldn't work in a production system like that, my second code (with advance sort method apply) might work better, but still far from the Ruby baseline code. That is the difference between amateur and professional, but I would never know it if I don't do the performance test.

It also reminds me why some programmers being paid 10 or even 100 times salary because they can write more efficient code, help company's website run 1,000 or 100,000 times faster with millions to billions of data.

So if I keep checking the performance of my code, getting to know what works better what works worse, learn the trick along the way of #LeanToCode, I might have chance to become one of those programmers. (always have hope!)

Finally, maybe I am just too optimistic, but check performance or do benchmark testing still a very good practice for either learning code or write code for work, not to mention it makes the journey more fun and interesting, agree?

Photo by Rob Wingate on Unsplash

At the end, I will show you how.

The benchmark tools I use in this article is from Evan Phoenix for #Ruby languages only. There might be similar tools in other languages as well, you can always find them through google.

First, you need to install the package for ruby.

$  gem install benchmark-ips

Second, import it to the file you want to test.

# Find-the-median.rb
require 'benchmark/ips'
...

Finally, add benchmark test code at the end of the file.

...
# all the methods are in the same file.
# also for all the test datasets. 
Benchmark.ips do |x|
    x.config(:time => 3, :warmup => 2)

    x.report("Kelvin's Method") {median_k(list)}           
    x.report("Kelvin's AdvSort") {median_k1(list)}
    x.report("Yunus's Method") {median_y(list)}
    x.report("Ruby Sort") {median_r(list)}

    x.compare!    
  end

You can find the full set of code here.

There might be a better way to test, and a different way to test in a production environment, but the point of this article is telling how important performance test is for both our study and work.

I hope this article is helpful for you, I would love to hear any comment and ideas from you, and I wish all of you - Happy Coding!

How much Bootstrap 4 Can help for a real world project?

Kelvin Liang — Mon, 24 Jun 2019 18:22:12 GMT

I am a junior web developer recently learned Bootstrap 4 and try to explore the possibility of the framework in a real world frontend project.

Before Start ...

To tell the possibility, I decided to do a real-world project with Bootstrap 4 to get the experiences.
I choose to clone the website of an Online Coding School ( Microverse .org ) I am attending to for this project, because:
- It is a Single Page Application which is common for today's job market.
- It has about 7 ~ 8 sections to introduce its features and services which make it complicated enough compared to other real-world projects.
- It uses #Bootstrap4 and custom CSS for its fronted decoration, which is exactly what I am looking for.
I didn't build the website from scratch, but I tried not to get any help from the school or any other people to ensure that is how I will work in the real world project.
I finished this project in about a month, but I was doing few others projects and studying during the period, so the total hours I spent on this project are about 30 ~ 40 hours.
The final project is not completely identical to the original one (and I am not intend to), you can see it from this link.

Below are how I have accomplished this project and what conclusion I came out of it.

Let's get it start => First Part - Project Setup

At first, I go to GetBootstrap .com to download the latest version of Bootstrap Source Files. (It is V.4.2.1), unzip it, and I saw the following files inside the folder. (There are many sub-folders and files I have omitted).

bootstrap-4.2.1 tree -L 2
    .
    ├── CNAME
    ├── CODE_OF_CONDUCT.md
    ├── ...
    ├── build
    │   ├── banner.js
    │   ├── ...
    │   └── vnu-jar.js
    ├── composer.json
    ├── dist
    │   ├── css
    │   └── js
    ├── js
    │   ├── dist
    │   ├── src
    │   └── tests
    ├── nuget
    ├── package-lock.json
    ├── package.js
    ├── package.json
    ├── scss
    │   ├── _alert.scss
    │   ├── _badge.scss
    │   ├── _breadcrumb.scss
    │   ├── _button-group.scss
    │   ├──  ...
    └── site
        ├── _data
        ├──  ...
        └── sw.js

    17 directories, 67 files

For my purpose, I only focus on one major folder - ./scss, because I will compile my own version of CSS through Sass. I copied the entire ./scss folder to my project folder, below are my project folder structure.

➜  clone-microverse git:(development) tree
.
├── [1.0K]  LICENSE
├── [ 736]  README.md
├── [ 224]  assets
│   ├── [ 128]  bootstrap
│   │   └── [1.4K]  scss
│   │       ├── [1.1K]  _alert.scss
│   │       ├── [1.0K]  _badge.scss
│   │       ├── [1.2K]   ...
│   │       ├── [ 920]  bootstrap.scss
│   │       ├── [1.0K]  mixins
│   │       └── [ 576]  utilities
│   ├── [ 128]  css
│   │   ├── [438K]  custom.css
│   │   └── [452K]  custom.map
│   ├── [2.0K]  images
│   │   ├── [9.8K]  1-r-kn-gdqsl-5-lie-3-l-r-7-j-n-0-a-zq-2-x.png
│   │   ├── [9.5K]  2000-px-stack-overflow-logo-svg.png
│   │   ├── ...
│   └── [ 128]  scss
│       ├── [ 27K]  _style.scss
│       └── [1.2K]  custom.scss
└── [ 48K]  index.html
7 directories, 47 files

There are 2 /scss folders in this project, one is ./asset/bootstrap/scss (from Bootstrap source files) and another one is ./asset/scss (for me to write customized code inside), and the output folder is ./asset/css (Where my HTML will refer link to).

For Sass compiler, I use Scout-App to help, it is a Sass GUI so it is very straightforward and easy to set up.
Once I finish the project setup, I start my coding in HTML & Sass files.

Second Part => Coding ... (the hardest part)

Base on Bootstrap Official Documentation, I created a custom.scss file to add my customized elements and bootstrap base file together.

// Custom.scss
// Option A: Include all of Bootstrap

/* -------begin customization-------- */

$theme-colors: (primary: #6f23ff,
secondary: #ffd540);

:root {
  --dusk: #3e396b;
  --very-light-blue: #f8faff;
  --purplish-blue: rgb(111, 35, 255);
  --tealish: rgb(65, 211, 189);
  --light-tan: #f9f1ae;

  --padding-sm: calc((100vw - 540px) / 2);
  --padding-md: calc((100vw - 720px) / 2);
  --padding-lg: calc((100vw - 960px) / 2);
  --padding-xl: calc((100vw - 1140px) / 2);

  --oPadding: calc(0.16 * 100vw);
  --oHeight: calc(0.16 * (100vw - var(--padding-xl)));
  --oHalfHeight: calc(0.16 * (50vw -var(--padding-xl)));
}

/* -------end customization-------- */

/* import Bootstrap to set the changes! */

@import "../bootstrap/scss/bootstrap.scss";

/* ----------- custom font import  ------------ */

@import url("https://fonts.googleapis.com/css?family=Domine:400,700|Maven+Pro:400,500,700,900|Montserrat:400,500,600,700,900&display=swap");

/* ------------ Self-styling -------------- */

@import "./style";

I used "Option A" - to include all the bootstrap components in this project, put all self-styling customization into a separated file ./style.scss, Sass will compile all sass files into one big giant css output to ./asset/css/custom.css, which I refer it back in my index.html file.


<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <link rel="stylesheet" href="./assets/css/custom.css" type="text/css" />
    <title>clone-Microverse - Online Coding Schooltitle>
  head>

So far all the steps above are very clear and easy to follow ( I finish them in about an hour), but what coming in next are out of my calculation.

I spent the first few hours trying to re-create the navigation bar and landing page by myself. The more I tried, the more I found it is hard and complex. I tried to utilize more bootstrap 4 classes and less customize CSS, but it seemed impossible.

The original website looks pretty slick and stylish, isn't it? Yes, but the price is very specified and complex frontend code.

I finally gave it up and try to look at the original website's code to see how they actually come together, the result is shocking - there are more stacks or layers to make up one component than I originally thought, there are more custom CSS than use Bootstrap 4 class directly, they intend to use more #id rather than class for specificity of CSS style. Below are a peek on the code -

# Index.html
"homepage" class="row bg-primary">
        class="content">
          "homepage-navbar-container" class="container-fluid p-0">
            "homepage-navbar" class="navbar navbar-expand-lg w-100">
              class="container">
                "#" class="navbar-band logo">microverse
                 ....
                "navbarToggler"
                  class="collapse navbar-collapse w-100 align-items-baseline">
                  class="nav navbar-nav w-100 justify-content-end">
                    class="nav-item pr-3">
                      class="nav-link font-weight-bold text-white text-capitalize"
                        href="#"
                        >curriculum

\\ _style.scss
#homepage-header {
    margin-top: 163px;
    position: relative;
    z-index: 105;

    .head-line {
      font-family: "Domine", serif;
      font-size: 3rem;
      font-weight: bold;
      line-height: 1.27;
    }

    .head-text {
      font-size: 1.25rem;
      line-height: 1.65;
      margin-top: 15px;
      margin-right: 30px;
      color: #fff;
    }

Because of these complexities, I spent almost one month to finish all the coding, there are some on and off time and I just do this project on my spare time, but it still overly difficult than most of the frontend project I have done before. The final finished index.html file has 1204 lines, _style.scss file has 1512 lines,

├── [1.0K]  LICENSE
├── [ 736]  README.md
├── [ 224]  assets
│   ├── [ 128]  bootstrap
│   │   └── [1.4K]  scss
│   ├── [ 128]  css
│   │   ├── [437K]  custom.css
│   │   └── [451K]  custom.map
│   └── [ 128]  scss
│       ├── [ 27K]  _style.scss
│       └── [1.1K]  custom.scss
└── [ 48K]  index.html

Finally, You can check out all the code in here. I have clone about 95% of the code from the original website, but it still took me many hours to accomplish it. I can't image how much hours I have to spend if I need to do this project from scratch.

Lesson Learn & Conclusion ...

At first, after finishing this project, I think I can answer the question I raise at the beginning now - How much Bootstrap 4 Can help for a real-world project?

A short answer is - "Not much"
A longer answer is - "It help on its grid system and some spacing utilities, but the project still needs a lot of customizing CSS to help make the website look unique and outstanding."
An even longer answer is - "Bootstrap framework help provide a solid foundation for the project, it contributed about 20 ~ 30 % of the code base, but a real-world project needs more unique design and differentiation, imaginations and creativities are needed as a Frontend Developer!"

Second, below are some lesson learned I got from this project -

A Real-world FrontEnd Project is usually complex and challenging. (It will be much more complex than the projects in Odin project or any other online learning platforms).
A Frontend framework such as Bootstrap 4 might help, but diligentness and creativities are still the main contributors.
Frontend development mainly involves repetitive coding and being requested to update frequently, make sure I like this kind of working style before I jump in.
There are still much more to learn about SASS, CSS & HTML.

Finally, due to the limitation of my knowledge and resources, I might do this project in a completely wrong way or an immature way, hence I got a completely wrong answer from it. But so what? I did it and write about it anyway, I definitely learn a lot from it.

There are free resource can help customize Bootstrap 4 theme too, but they seem no fit for this project, so I might try them in the next project.

I will do it again if there is a question I can't get the answer from google or any other sources, I think that is how a self-taught programmer learn to evolve in today's environment.

PS: I am open to your critiques and suggestion for this project, thanks again for you to finish this reading.