Starting from open-source projects to enterprise software, most softwares have a huge codebase. Don't believe me? Here is a fact! Some of the Google codebases have over 2 billion lines! Understanding and debugging each line manually is something that probably only Superman can do. So when contributing to a project, it is essential to keep in mind that your code doesn't disrupt the existing functionalities.
What is Testing? 🧪
In software, testing is the process of finding any gap, error, or missing requirements and verifying if it matches our needs.
Suppose you give an input in an electrical DC Machine. With your theoretical knowledge, you will have some expected output right? But in real life the output might be a bit different. So in testing, we generally determine the difference between the expected and the actual values and try to fix it as much as possible.
Software testing is divided majorly into 3 categories:
- Unit Testing: testing a single function
- Integrating Testing: testing a function that calls a function
- End to End Testing: validating a DOM (i.e. we check if everything is in sync)
In this article, let's focus on Unit Testing. Why? Because it is easy to implement and very commonly used.
But how do we know what to test? 🤓
When it comes to testing, even a simple block of code could paralyse beginners. The most common question is "How do I know what to test?"
Suppose we're writing a web application, a good starting point would be testing every page of the app and every user interaction. But, web applications are also made of units of code like functions and modules that need to be tested too.
While writing code, there are mostly two scenarios:
- You inherit legacy code which comes without tests
- You have to implement a new functionality out of thin air
What to do? For both the cases we can think tests to be bits of code that check if a given function produces the expected result or not. Here's how a typical test flow looks like:
- import the function to test
- give an input to the function
- define what to expect as the output
- check if the function produces the expected output
Really, that's it! Testing won't be scary anymore if you think in these terms:
input - expected output - assert the result
What is Jest? ✨
Jest is a JavaScript testing framework powered by Meta. It focuses more on simplicity and support for large web applications. It is used for testing applications using Babel, TypeScript, Nodejs, React, Angular, Vuejs, and Svelte. Jest is one of the most popular test runners these days and the default choice for React projects.
Jest ships in the NPM package and you can install it in any JavaScript project by running:
npm install --save-dev jest
Let's see a demo 💥
Setting up the project
mkdir jestDemo
cd jestDemo
Now you are in your directory, so let’s initialise it with NPM.
npm init -y
The flag -y helps you initialise with all default values. Now, let’s install the jest NPM package.
npm install --save-dev jest
The project structure is very important, so let’s make it now.
For testing, it is essential to name the testing file with the name of your JavaScript file you want to test and concatenating the word test in between. In this demo we will be testing a script to subtract 2 elements. The script is written in subtract.js
so the corresponding testing file will be subtract.test.js
.
Open up package.json and configure a script named test for running Jest:
"scripts": {
"test": "jest"
},
Now we are good to go😁 Let’s start with the scripting of subtract.js and subtract.test.js
In subtract.js:
function subtract(a,b){
return a-b
}
module.exports = subtract
In subtract.test.js:
const subtract = require('./subtract')
test("Must subtract properly",() =>{
expect (subtract(1,2)).toBe(-1)
})
And that's it! Now let’s test it.
npm test
After the test, it gives you an output showing the status of the code and comparing it with the actual result and the specified expected value. You will get an output similar to
To get a more detailed and structured visualisation of you tests run:
jest --coverage
Jest coverage command gives a more detailed analysis where the test fails and code can be improved accordingly.
Outro 💚
Testing is a big and fascinating topic. There are many types of tests and many libraries for testing. In this Jest tutorial, you learnt how to configure Jest for coverage reporting, how to organise and write a simple unit test, and how to test JavaScript code. There’s no better way to test-drive Jest than by diving in and playing with it.
The purpose of the blog is to create awareness about Jest and similar testing tools. To learn further it is recommended to go through the Jest's official Documentation. In case you have some questions regarding the article or want to discuss something under the sun feel free to connect with me on LinkedIn 💕
If you run an organisation and want me to write for you please do connect with me 🙈
Top comments (33)
Worth mentioning that Jest will only test your JavaScript.
But don't rely only on Jest.
A real browser is more than just a JavaScript interpreter.
The best practices mention that you should run automated tests in all major browsers, including Safari (which is used by 20% of users, including myself).
A few weeks ago, I wrote a small article:
What Happens When You Don't Test in Safari
Even using clean vanilla code can lead to major cross-browser issues.
Users can choose the best browser, Safari is becoming the new Internet Explorer, users insist to use it relying on thought about performance/battery and other stuff. Of course performance is important, but new technologies require new behaviors. If you choose Safari you're choosing not to have new technologies. 🤷♂️
That's how democracy works, and I think it's great that users can choose from a number of browsers that are decent.
You have to test in the browsers used by your users, that's why it's important to get that information from your analytics.
Accessibility means making your website work for as many users as possible.
In some cases, that could mean supporting small screen resolutions or certain browsers.
Now, even if we will live in a totalitarian world where Chrome will be the only browser, you'll still have Chrome on Windows and Chrome on Mac.
Ever noticed that the select elements look different on Chrome on Mac vs. Chrome on Windows?
That's just one of the many differences you'll encounter.
Testing on different browsers can be painful, but it's a best practice, there is no workaround.
combine with Playwright to do actions and Jest to assert
Some folks are complaining that Playwright, Puppeteer and others are not following any open standards.
That means there's a risk they might stop working out of the blue with certain browsers or other components.
What will happen then?
You have written a masterpiece, thanks for commenting otherwise I would have missed it. Specially taking Safari as the corner case is genius never actually thought what happens in it.
To be honest the most beginner friendly testing article I have read so far. The way you have explained what is jest and how to do write tests are just amazing. Ultimately, the demo makes it more surreal and useful 😍
Thanks for your time and your comments means a lot 💕
Wow! This made testing so much easier for me. Will definitely try the demo myself🔥
Thanks for your time and your comments means a lot 💕
Very nice document to start with Jest :)
Thanks for your time and your comments means a lot 💕
Great quick intro for beginners getting into Jest 💪
Hearing this for you means a lot. Let me know if this gets a place in your newsletter 😛
Very interesting post
Thanks Jack
A great and useful blog ✨🔥
Got to learn about testing🧪
Thanks for your time and your comments means a lot 💕
Simple and insightful blog ✨ Really liked it
Thanks for your time and your comments means a lot 💕
Love the work
Thanks for your time and your comments means a lot 💕
The article is informative and easy to understand. Keep up the good work!! 🔥
Thanks for your time and your comments means a lot 💕