Writing test-cases as per the developers is a tedious job. A developer is not able to see a bigger problem they are trying to solve by writing test-cases in their project. It is not 100% their fault. The problem is the way we developers learn, we always give priority to write code first.
This is the series where I will take you through the Testing guide — Why, How and when?
We are working in the world of agile. The requirements keep changing and we developers keep re-writing code. Sometimes, it looks like never ending loop.
However, there is 4 major reason as per me why we should consider writing test cases:
- Test-cases act as the documentation of your application’s features and requirements.
- Test-cases helps in covering all the edge-cases and unwritten requirements way ahead before you start writing your code. Test-cases became your base for requirements and you can get validation on them.
- Test-cases is the easiest way to onboard a new developer. Test-cases is the documentation of your project and new dev can easily understand it.
- Test-case’ code coverage represent your’s code and project quality.
Do not think about code
If you are working in the service-based industry then you know the problem of timeliness. As a developer, you are trained to do code first, give an estimation on the basis of how much time you will take to code.
However, the first rule is to think before code.
Write test-cases before writing code (hint, TDD). The second rule is when giving estimations add an hour* for manual and test-cases testing.
What to Test?
The biggest confusion for new devs on testing is what to test?
As a developer, you are the decision maker of what you want to test and how you want to test. The process would be:
- Understand the requirements.
- Start writing the test-case, not the code.
- Eg. Requirement: Click on the button should doSomething. Let’s break this requirement
- What would be the text of the button?
- Would there be any hover event?
- What there be any default text too?
- How the button will be on different screen sizes?
- Would there be any icon or not?
4. Write test case
- The button is rendering on screen.
- The markup or tag is valid Button’s tag.
- Is there any text — if no, is default text is there?
- The datatype of the text should always be String
- Is event on the Button onHover() is working?
- Is event on the Button onClick() is working?
- Is event on the Button onChange() is working?
- Can the user add its own event?
- and so on…
So, this is how you map the requirements with what to be tested. If you follow this process you will be amazed to see how you are able to identify the edge cases way before you write your first line of code.
There are many frameworks available to do testing such as Mocha, chai, and most popular is Jest. In this tutorial, we going to learn about Jest.
What is Jest?
Jest provides you almost all a developer needs to test the project from unit testing, mock functions, snapshot testing.
Why it is popular?
Jest is the very simple framework and you will understand once you will see it how it works. Jest provides developer in the most simple way the most complex work is getting done. If you are following TDD by Jest you can have the maximum code-coverage. (we are going to talk about code-coverage soon)
- Fast and Safe
- Code Coverage
- Easy mocking
- Easy debugging
- Work with almost all popular UI frameworks and libs
- Easy learning curve
- Part 2: Installing Jest in your Reactjs Project
- Part 3: Writing your first Jest Test-case
- part 4: Write your first Snapshot test-case
- Part 5: Deep dive into Jest with Testing Reactjs
- part 6: E2E testing