DEV Community: Kelvin Liang

Work as A Developer in 2021

Kelvin Liang — Fri, 12 Feb 2021 11:29:46 +0000

After 2 years of study and researching, I finally landing a developer job in an international company to work as a Frontend developer at the end of 2020.

2 months into my new role, I would like to share some afterthoughts about the job searching and advice here. I hope it can help somebody still looking for developer jobs or just get started.

Photo by Saulo Mohana on Unsplash

Job Opportunities & Future

At first, I would like to share some good news with whoever just start to learn how to code or thinking about it, I can tell you - your instinct is right, this industry is booming and there are full of opportunities waiting for you.

I knew it because I saw many opportunities while I was in the journey of job searching, and I continue seeing them even after I got a job.

I knew it also because after I joined my first developer role, I have learned more about why I am getting the job, as while as others in the same company.

Finally, I knew it because the more I did the job, the more I believe this job has great potential, this is the "must" have skill across industries and companies in the coming decade. (Once again proven my belief before I start to learn the code)

So believe me, go for it. (of course, make sure that is really what you want but not the money)

Photo by Victoriano Izquierdo on Unsplash

What to Learn?

Second, I like to talk about what techs you should choose in general and how much you should learn about them.

There are always debates about whether we should learn the hottest, sexiest tech vs. we should just learn something just less cool but we like.

I think there is no right or wrong, having knowledge of the hottest tech means you will have a lot of competitors while you do the job searching while learning some minority tech would be a difficult journey because there are fewer supporting documents and fewer communities support.

And just like most of the code newbies, when I start to learn how to code, I try to learn as much as possible, as deep as possible.

That is a common mistake, isn't it? While, that is not that obvious when you still learning and don't have a job, at least that is for me.

There are always temptations that trigger you to start to learn new tech, either just out of curiosity or the intention of getting a job after viewing some job descriptions.

Again, there is no right or wrong. You may end up getting a job because you know everything, or because you just know one thing well.

The point is, we all human beings, our energy is limited. Since there are almost infinite technologies available in the market, and there are more coming, we should really narrow down our list of learning.

So my advice is, once you find one tech that you love or good at, stick with it, try to learn more about it, and practice it, it will lead you to a job eventually because the market is big enough to accommodate any developer who has some practical skill sets.

Photo by Annie Spratt on Unsplash

Keep Learning

Finally, I would like to mention the importance of keep learning.
Even I just started my new job in less than 2 months, I can't help to notice the importance of keep learning. (It validate the points from most experiences developers agree on)

Why?
First, it will just help you in the job and put you in a more advanced position if you know more.

Second, even you think you know everything about your job, you should not stop neither.

Because technology is changing every day in the outside world. You never know whether your company will dump one tech and in favor of another tomorrow, or decide to go deeper with the current one.

Third, you never know what and when the opportunities will come, the odd of getting those opportunities will definitely bigger if you know more.

What to Learn?

But then you might wonder - what I should learn? as I mention earlier, we can't learn everything. so I have some thoughts to share here for you.

At first, I think it is always important to re-learn the basics, either you are work as frontend or backend, the fundamental knowledge in your area is always important and very practical.

Because they will help you solve problems that require fundamentally understanding the technology you use, accelerate your speed of learning if you know how things work in your world.

Take Frontend as an example, I think JavaScript, data structure, and algorithms are fundamental for the entire frontend world.

Second, if you are already working, the chance is, you already have some ideas on what needs to learn, new tech stacks, corporate culture, collaboration, team building, and agile management, the question for you now is what to choose first and how to learn them within a given time frame. My advice is to learn technical things while you coding (because you are a developer), learn the other things slowly, one at a time, keep persistent but don't give up because they are also very important for your career.

Third, when you settling down in a role and you feel still have some extra time, it is good to think about expanding your horizon and go deeper, but most of the time, I would suggest picking something that is related to your works now or something that can help improve your efficiency.

Take me for example, now I have to deal with complex form handling every day. I took my free time to learn related react packages and practical examples which in turn I can use that knowledge back in my daily work, not only I learn faster and deeper but also I have more confidence in this skill set because I have so many practical experiences.

Another example is, I use VSCode as my daily IDE at work, although this is a tool most people can easily get started with, mastering it does require patient and effort. Spend some time to learn about it on daily basis would definitely help improve your daily work. And because it is a universal skill set that will follow you in your entire career journey, so that is a good time investment anyway.

Photo by LinkedIn Sales Navigator on Unsplash

Final words & Summary

In the end, I would like to thank you for stay until the end, I really hope that my two cents can help some of you out there, especially for someone just starting to learn how to code.

I know some of my thoughts and thinking maybe too naive or imperfect, but I would rather write them out to take criticism rather than bury them in my head until I forget them, I would very much appreciate that if you have different opinions and share them with me, so we, together can help more people out there.

Finally, just like Steve Jobs once advised - Stay Hungry, Stay Foolish. It pretty valid the point I am trying to make above and it will continue valid as long as we are still in the computer industry.

Strategy to get a developer job in 2020

Kelvin Liang — Thu, 23 Jul 2020 10:20:13 +0000

I list my thinkings and plans on getting a developer job in the next 3 months, I hope it will work and you can find them relevant and helpful.

I think everyone should have a unique strategy of getting a developer job because I believe everyone is different and so is the market.

First, there are some mysteries during the job searching process.

1.Should I choose the hottest technologies to learn?

Most of the time, choosing the hottest tech stack to start and move forward is nothing wrong, just keep in mind that the competition is fierce as well, therefore, your chance of getting a job would be lower.

Suggestion

If you already in the job search phase, you probably can't change quickly, so just stick with them.
If you are learning and searching at the same time, choosing the honest tech stack still the right choice, but you need to think about what is your niche.
Try to build something around it while you learning. For example, among so many other react developers around the world, I picked testing in react as my unique toolchain to move forward.

2.Should I only interested in some particular jobs?

When I first start to job search, it is easy to think I should narrow down the scope and focus on the most interesting jobs out there, that is nothing wrong.

But again, please keep in mind, the more restrictions you put on your job search criteria then the less chance of getting a job you will have.

Suggestion

You should put the restrictions on only if you are 100% certain, otherwise, widen your search criteria will help you to see more opportunities out there.

I made these mistakes on the first months of job searching, I was wondering why so little job is available in the market.

3.Should I learn more before applying?

There are always temptations of trying to make your portfolio perfect by learning more, doing more projects and having more networking, etc.

However, at the same time, the more energy you spend on improving your portfolio, the less time you will spend on job searching, therefore, the chance of getting a job is not promising.

Suggestion

Spread your time and energy in both improving and job search, and use them wisely.
Be careful about taking a big side project while you are on job searching.
You couldn't perfect everything, chose something it is important to you, and ignore the others.

4.Should I only focus on these companies?

Choosing to open or close to some particular companies is totally up to you, but again, the more close you are, the little you will know what is the reality of the job market.

When we first start to search, it is easy to think that we should focus on the companies we know, but the reality is there are many companies and startups out there we have never heard about do offering pretty good positions out there.

Suggestion

You should be more open when just start to search, it will help you know more companies and markets out there.
Once you know more about the market and understand what you want, you can start to narrow down your shortlist to save your time and energy.

Second, Make a plan.

Photo by bruce mars on Unsplash

Please Note - You have to give yourself time to get to know the market and yourself better before jump into the conclusion on what you want.

When I first start looking for a job, it seems obvious that I should make a plan, but it was actually not.

I actually just trying to find jobs spontaneously. I applied for 20 jobs in one week but only 3 jobs another week, I jump on to learn something new for one month then I do nothing for the coming month, take a lot of time to start a side project but never have time to finish it.

Sounds like you? Maybe you are better than me, but to be honest, job searching is really confusing for most of us. Frustrations and motivations come at the same time, opportunities and self-confidence are not equally spread, time always not enough but at the same time, you seem not sure what to do next.

There are many ideas that led me into different directions and paths that seem can get me to start, except they are not.

After 3 months, below are what I have learned:

The first coding job is usually hard for junior dev, frustrations and rejections are daily routines in our job searching life, it is normal to take up to 12 months until the first job is landed.
I still have to put some faith in myself and the industry, be consistent and persistent.
Focus on things I could change, not the things I couldn't change.
- location/culture/nationality/work permit
- tech stack (it is not realistic that pick up another tech stack while job searching)
- background (such as language, work experiences, degrees, etc)
There are still many things I can change, but I need to choose carefully because I have limited time and energy.

After rationalizing the situation, I started to make plans.

I start to set some more measurable targets every week (just like you are at work), such as:

Applying for 20 jobs a week,
Connecting 3 recruiters on LinkedIn every week,
Do a mock interview at pramp.com etc.

I start to write technical articles regularly to recording down my journey of job search (Just a personal preference, a way to networking, and learning).
I start to brainstorm side project ideas, target at:
- Open-source project,
- Frontend related,
- Javascript base,
- lightweight(Can be finished in one month).

Third, aim for a bigger goal.

Photo by Poodar Chu on Unsplash

Although this article is talking about finding a job in 2020, we should always aim for a bigger target in the long run.

Still, remember why we want to learn code in the first place? Getting a better lifestyle? Love doing problem-solving? or Adapting the new changes in the industry?

For me is trying to get a better work-life balance and adapting the new changes. As for now, I aim for a junior frontend developer job.

It has to be a frontend and it has to be a coding related job because I aim for getting into top-tier high-tech companies in 3 years as a senior Frontend developer.

And in 5 to 10 years, I want to start my own business/startup in China.

Once these goals have been set, I have a better idea of what kind of company I am looking, and what kind of job I should give more thought about.

For example, I am more tended to join startup companies vs. established companies, I think a more versatile role is better than a more static role because of the reason above.

Final words.

Photo by Joshua Earle on Unsplash

I knew many developers written about their job searching journey every month, but I still want to have my own version here to remind me how I get through the process.

I wrote this article mostly is for self-encouragement and self-affirmation, I can't say the above strategy will work, but I can say it is most suitable for me now.

I do hope from the process and thinking I shared here, you will be inspired and make your own strategy on your job search journey. And I would love to hear comments and suggestions from you.

Finally, I do get inspiration and idea from some other resources, I will share them below, hope can help you as well.

Reference

This Post original posted at my blog here.

What is my reason to learn to code

Kelvin Liang — Thu, 16 Jul 2020 17:44:30 +0000

I like to tell you what is my reason for the "learn to code" phenomenon, and I hope you can find out yours after reading this.

I started my coding career 3 years ago by joining a Chinese tech startup to work as a team lead there. After that, I have tried many different things to become a professional developer, because being a badass programmer is my long time dream.

Photo by National Cancer Institute on Unsplash

In the industry for a long time.

Actually, I have been in the tech industry for a fairly long time now. But I have always worked in the backstage - designing & building system infrastructure, implementing solutions, supporting users, and writing documentation. All of these jobs are fantastic and have a lot of potentials. However, there was always something missing in my mind that I didn't feel right.

Being an IT professional is great to gain many hands-on experiences and get to see how systems work at the very end of its life cycle.

But there is a downside.

Nowadays, all the systems and apps we use daily are designed and developed by others - from big tech companies (such as Microsoft, Google, Apple, Tencent, and Alibaba), to individual developers, 3rd party software agencies.

Photo by whoislimos on Unsplash

As an end-user, you have no control over how the applications should work and look, and what functions they should have, you have no choices but comply.

And it is even worse for an IT professional, not only I need to comply with whatever systems or applications my end-users use, but also I need to learn into detail about them that I can support my end-user and maintain my system properly and hope there will be nothing change ...for a while, at least.

That is a fairytale, however.

Photo by Markus Winkler on Unsplash

Because I have been in the industry long enough that I knew it - everyone wants to change once a while, and everyone does things slightly differently.

The result is, there are endless bugs and issues to fix when different systems and applications work together. And to make things even worse, once a company decided to modify its software or replace something, both the end-users and I need to start over again to adapt them without many choices.

Photo by Dmitrij Paskevic on Unsplash

I understand "the changes are for the greater good!". But still, being led by others and wait for the fortune come by itself is not my style. And I guess it is not for most people out there neither.

There is a way to change it.

Photo by Noah Buscher on Unsplash

Today, many tech companies or startups start to put the "developer" tab on their websites, offering APIs and even source codes of their products, so other developers or companies can manipulate and use their services in the way they like and want.

However, the problem is, I need to know how to code, or at least, you need to understand the code and protocols those tech companies providing, so I know what are the options out there and where I can find the help.

In addition, with the ability to code, I can create customized applications that just for myself. I can define how the apps look like, what features I would like to include, and how they work.

That is it. The codability that makes me understand the languages that speak in 2020 in the IT industry, take control of my future career on my hand instead of others.

I think that is probably why I want to learn to code in the first place.

How it turns out today ...

Photo by Free To Use Sounds on Unsplash

As I made the decision 2 years ago, I have been trying many ideas to get started - data analysis, machine learning, big data, data science, and finally, web development.

I still remember that excitement that I finish my first machine learning model about titanic disater, first time build a website from scratch to use multiple state of art technologies build a fancy personal portfolio website.

Fast forward today, I do not regrade my decision. I am actually pretty happy that I made that decision earlier than later.

Check out the latest tech news today -

Microsoft acquired Github, NPM - some of the most famous open sources companies out there and try to become an open-source company itself in 2020.
COVID-19 pandemic makes Work from home (WFH) becoming a norm in many industries (especially for the tech industry) in 2020.

So I think now I have more confidence in what is coming next in my career and I knew the more experiences I get into the coding world, the brighter future my career will be. That is probably the reason why I like to Learn to Code.

Photo by Josh Rakower on Unsplash

In the next article, I will try to explain what is my strategy for getting a developer job from China in 2020.

I hope my experience above can give you some insight into why coding is becoming more and more important today and it helps you to make your decision in any way.

How to write tests for React in 2020 - part 2

Kelvin Liang — Sat, 20 Jun 2020 05:09:21 +0000

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 accessibility 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
...
<div className="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
...
<div className="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`] = `
<div
  className="App"
>
  <div
    className="navbar"
  >
    ....
```
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:

![snapshot-test-error](https://dev-to-uploads.s3.amazonaws.com/i/etzzsl0hfx3baavp8kvd.png)

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 a 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 the test, to avoid getting too many errors and slowing down the process.
```js
 xtest('should have no accessibility 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.

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

![web-api-datafetch](https://dev-to-uploads.s3.amazonaws.com/i/eh5nxp4ev3m0wfopnd4t.png)

1. When a condition is met (such as click on a button or page loaded), an API call will be triggered;
2. When data come back from API, usually response need to parse before going to next step (optional);
3. When having proper data, the browser starts to render the data accordingly;
4. 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: 

![web-api-datafetch-Test](https://dev-to-uploads.s3.amazonaws.com/i/iomgaf7qmiuwguu2ze0n.png)

* 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.
```js
// ./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 folder](https://dev-to-uploads.s3.amazonaws.com/i/qle8njo9k4h7erxo0f0l.png)

**Mock API** file (`getNews.js`) should look sth like below -
```js
// ./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
```js
// ./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` needs 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.
```js
// ./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.
    <Router>
      {component}
    </Router>
  )
);

...
```
> **Please Note:**
```js
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.
```js
// ./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 ...'));
  });
...
});
```
![mock_api_first_test_pass](https://dev-to-uploads.s3.amazonaws.com/i/9lznaamxzq3bleuccs3s.png)

With the mock API being called and page rendering as expected. We can now continue to write more complex tests.
```js
...
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**
```js
 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.
```js
// // ./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.

```js
// ./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.
```js
// ./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](https://github.com/kelvin8773/react-test-examples/blob/master/src/pages/News.test.js). 

> **Please Note**
They are just simple test cases for demonstration purposes, in the real-world scenarios, the tests would be much more complex. You can check out more testing examples from my other project [here](https://github.com/ooloo-io/reddit-timer-kelvin8773).

---
![Final Lesson](https://dev-to-uploads.s3.amazonaws.com/i/rjst30dgl43v17rpewjq.jpg)
Photo by [ThisisEngineering RAEng](https://unsplash.com/@thisisengineering) on **Unsplash**

## **Final words**
In this article, I followed the best practices **Kent C. Dodds** suggested in his blog post - [Common mistakes with React Testing Library](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library) published in May 2020, in which you might find my code is slightly different from **[Test-Library Example](https://testing-library.com/docs/react-testing-library/example-intro)** (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-component](https://testing-library.com/docs/react-testing-library/example-intro)** 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 here or some from [my previous article](https://dev.to/kelvin9877/how-to-write-tests-for-react-in-2020-4oai) 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.

### Here are some resources I recommend to continue learning:
* [Testing from Create React App](https://create-react-app.dev/docs/running-tests)
* [Which Query should I use From Testing Library](https://testing-library.com/docs/guide-which-query)
* [More examples from Testing Library](https://testing-library.com/docs/example-codesandbox)
* [Write Test for Redux from Redux.js](https://redux.js.org/recipes/writing-tests)
* [Unit Test From Gatsby.js](https://www.gatsbyjs.org/docs/unit-testing/)
* [Effective Snapshot Testing](https://kentcdodds.com/blog/effective-snapshot-testing) from [Kent C.Dodds](https://kentcdodds.com/).

### Resources and Article I referenced to finished this article:
* [Inside a dev’s mind — Refactoring and debugging a React test](https://dev.to/jkettmann/inside-a-dev-s-mind-refactoring-and-debugging-a-react-test-2jap) By [Johannes Kettmann](https://dev.to/jkettmann).
* [Don't useEffect as callback!](https://jkettmann.com/dont-useeffect-as-callback/) by [Johannes Kettmann](https://dev.to/jkettmann).
* [Common mistakes with React Testing Library](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library) by [Kent C.Dodds](https://kentcdodds.com/).
* [Fix the not wrapped act warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning) by [Kent C.Dodds](https://kentcdodds.com/).
* [Accessibility From React](https://reactjs.org/docs/accessibility.html).
* [Axe for Jest](https://www.npmjs.com/package/jest-axe).

### Special Thanks for [Johannes Kettmann](https://dev.to/jkettmann) and his course [ooloo.io](https://ooloo.io/).

> I have learned a lot in the past few months from both the course and fellows from the course - [Martin Kruger](https://github.com/martink-rsa) and [ProxN](https://github.com/ProxN), who help inspire me a lot to finish this testing 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 Final finishing project](https://github.com/ooloo-io/reddit-timer-kelvin8773) as the outcome.

How to write tests for React in 2020 - part 1

Kelvin Liang — Wed, 27 May 2020 10:41:51 +0000

Writing React Tests with React recommend libraries — Jest & React Testing Library for complete beginners.

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';

Second, write a test for NavBar component.

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(<NavBar />); 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;

Third, write a signup form component test.

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.

I am planning to write another article to cover more advance examples if I got positive feedback on this article, Thanks again for your time.

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.

Why I should check my code's performance?

Kelvin Liang — Wed, 17 Jul 2019 16:06:04 +0000

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! *