.svg)
.svg)
Basic JavaScript, TypeScript
To make the reader understand the use/effect of test cases in software development.
In the world of coding, we're often in a rush to complete work before a deadline hits. And let's be honest, writing test cases isn't usually at the top of our priority list. We get it—they seem tedious, so we’d rather skip this extra step. But here's the thing: those seemingly boring lines of code have superhero potential. Don't believe me? You will.
In this blog, we're going to break down the mystery around test cases. No jargon, just simple talk. We'll chat about what they are, explore a handy tool called Jest, and uncover why these little lines are actually the unsung heroes of coding. So, let's ditch the complications and discover why giving some attention to test cases can level up our coding game. Ready? Let's dive in!
A test case is a detailed document specifying conditions under which a developer assesses whether a software application aligns with customer requirements. It includes preconditions, the case name, input conditions, and expected results. Derived from test scenarios, test cases cover both positive and negative inputs, providing a roadmap for test execution. This one-time effort aids future regression testing.
Test cases offer insights into testing strategy, process, preconditions, and expected outputs. Executed during testing, they ensure the software performs its intended tasks. Linking defects to test case IDs facilitates efficient defect reporting. The comprehensive documentation acts as a safeguard, catching any oversights during test case execution and reinforcing the development team's efforts.
Different types of test cases exist, including integration, functional, non-functional, and unit.
For this blog, we will talk about unit test cases.
Unit testing is the process of testing the smallest functional unit of code. A functional unit could be a class member or simply a function that does something to your input and provides an output. Test cases around those functional units are called unit test cases.
There are various frameworks for unit test cases, including:
Jest is used and recommended by Facebook and officially supported by the React dev team.
It has a great community and active support, so if you run into a problem and can’t find a solution in the comprehensive documentation, there are thousands of developers out there who could help you figure it out within hours.
1. Performance: Ideal for larger projects with continuous deployment needs, Jest delivers enhanced performance.
2. Compatibility: While Jest is widely used for testing React applications, it seamlessly integrates with other frameworks like Angular, Node, Vue, and Babel-based projects.
3. Auto Mocking: Jest automatically mocks imported libraries in test files, reducing boilerplate and facilitating smoother testing workflows.
4. Extended API: Jest comes with a comprehensive API, eliminating the necessity for additional libraries in most cases.
5. Timer Mocks: Featuring a Time mocking system, Jest accelerates timeout processes, saving valuable testing time.
6. Active Development & Community: Jest undergoes continuous improvement, boasting the most active community support for rapid issue resolution and updates.
Describe
It
Matchers
| // For each unit test you write, | |
| // answer these questions: | |
| describe('What component aspect are you testing?', () => { | |
| it('What should the feature do?', () => { | |
| const actual = 'What is the actual output?' | |
| const expected = 'What is the expected output?' | |
| expect(actual).toEqual(expected) // matcher | |
| }) | |
| }) |
Mocks: They are objects or functions that simulate the behavior of real components. They are used to create controlled environments for testing by replacing actual components with simulated ones. Mocks are employed to isolate the code being tested, ensuring that the test focuses solely on the unit or component under examination without interference from external dependencies.
It is mainly used for mocking a library or function that is most frequently used in the whole file or unit test case.
Let Code.ts be the file you want to test.
| import { v4 as uuidv4 } from uuid | |
| export const functionToTest = () => { | |
| const id = uuidv4() | |
| // rest of the code | |
| return id; | |
| } |
As this is a unit test, we won't be testing the uuidV4 function, so we will mock the whole uuid module using jest.mock.
| jest.mock('uuid', () => { uuidv4: () => 'random id value' })) // mocking uuid module which will have uuidV4 as function | |
| describe('testing code.ts', () => { | |
| it('i have mocked uuid module', ()=> { | |
| const res = functionToTest() | |
| expect(res).tobeEqual('random id value') | |
| }) | |
| }) |
And that's it. You have mocked the entire uuid module, so when it is coded during a test, it will return uuidV4 function, and that function, when executed, will give a random id value.
Spies: They are functions or objects that "spy" on other functions by tracking calls made to them. They allow you to observe and verify the behavior of functions during testing. Spies are useful for checking if certain functions are called, how many times they are called, and with what arguments. They help ensure that functions are interacting as expected.
This is by far the most used method, as this method works on object values and thus can be used to spy class methods efficiently.
| class DataService { | |
| fetchData() | |
| { | |
| // code to fetch data | |
| return { 'real data'} | |
| } | |
| } |
| describe('DataService Class', () => { | |
| it('should spy on the fetchData method with mockImplementation', () => { | |
| const dataServiceInstance = new DataService(); | |
| const fetchDataSpy = jest.spyon(DataService.prototype, 'fetchData'); // prototype makes class method to a object | |
| fetchDataSpy.mockImplementation(() => 'Mocked Data'); // will return mocked data whenever function will be called | |
| const result = dataServiceInstance.fetchData(); // mocked Data | |
| expect(fetchDataSpy).toHaveBeenCalledTimes(1) | |
| expect(result).toBe('Mocked Data'); | |
| } | |
| } |
One of the best uses of Jest is to mock a database call, i.e., mocking create, put, post, and delete calls for a database table.
We can complete the same action with the help of only Jest spies.
Let us suppose we have a database called DB, and it has lots of tables in it. Let’s say it has Table Student in it, and we want to mock create a Student database call.
| function async AddStudent(student: Student) | |
| { | |
| await db.Student.create(student) // the call we want to mock | |
| } | |
Now, as we are using the Jest spy method, we know that it will only be applicable to objects, so we will first make the Db. Students table into an object with create as method inside it, which will be jest.fn() (a function which can be used for mocking functions).
Students an object with create as method inside object which will be jest.fn() (a function which can be used for mocking functions in one line without actually calling that function).
| describe('mocking data base call', () => { | |
| it('mocking create function', async () => { | |
| db.Student = { | |
| create: jest.fn() | |
| } | |
| const tempStudent = { | |
| name: 'john', | |
| age: '12', | |
| Rollno: 12 | |
| } | |
| const mock = jest.spyon(db.Student, 'create'). | |
| mockResolvedvalue('Student has been created successfully') | |
| await AddStudent(tempStudent) | |
| expect(mock).tohaveBeenCalledwith(tempStudent); | |
| }) | |
| }) |
Sometime, in development, we write private code for classes that can only be used within the class itself. But when writing test cases, we call the function by creating a class instance, and the private functions won’t be accessible to us, so we will not be able to test private functions.
But in core JavaScript, there is no concept of private and public functions; it is introduced to us as TypeScript. So, we can actually test the private function as a normal public function by using the //@ts-ignore comment just above calling the private function.
| class Test() | |
| { | |
| private private_fun() { | |
| console.log("i am in private function"); | |
| return "i am in private function" | |
| } | |
| } |
| describe('Testing test class', () => { | |
| it('testing private function', () => { | |
| const test = new Test() | |
| //calling code with ts-ignore comment | |
| //@ts-ignore | |
| const res = test.private_fun() // output ->> "i am in private function "// | |
| expect(res).toBeEqual("i am in private function") | |
| }) | |
| }) |
P.S. One thing to note is that this will only work with TypeScript/JavaScript files.
Makes code agile:
In software development, one may have to change the structure or design of your code to add new features. Changing the already-tested code can be risky and costly. When you do the unit test, you just need to test the newly added code instead of the entire program.
Improves code quality:
A lot of bugs in software development occur due to unforeseen edge cases. If you forget to predict a single input, you may encounter a major bug in your application. When you write unit tests, think carefully about the edge cases of every function in your application.
Provides Documentation:
The unit test gives a basic idea of what the code does, and all the different use cases are covered through the program. It makes documentation easier, increasing the readability and understandability of the code. Anytime other developers can go through the unit test interface, understand the program better, and work on it fast and easily.
Easy Debugging:
Unit testing has made debugging a lot easier and quicker. If the test fails at any stage, you only need to debug the latest changes made in the code instead of the entire program. We have also mentioned how unit testing makes debugging easier at the next stage of integration testing as well.
So, if you made it to the end, you must have some understanding of the importance of test cases in your code.
We’ve covered the best framework to choose from and how to write your first test case in Jest. And now, you are more confident in proving bug-free, robust, clean, documented, and tested code in your next MR/PR.
Did you like the blog? If yes, we're sure you'll also like to work with the people who write them - our best-in-class engineering team.
We're looking for talented developers who are passionate about new emerging technologies. If that's you, get in touch with us.
Basic JavaScript, TypeScript
To make the reader understand the use/effect of test cases in software development.
In the world of coding, we're often in a rush to complete work before a deadline hits. And let's be honest, writing test cases isn't usually at the top of our priority list. We get it—they seem tedious, so we’d rather skip this extra step. But here's the thing: those seemingly boring lines of code have superhero potential. Don't believe me? You will.
In this blog, we're going to break down the mystery around test cases. No jargon, just simple talk. We'll chat about what they are, explore a handy tool called Jest, and uncover why these little lines are actually the unsung heroes of coding. So, let's ditch the complications and discover why giving some attention to test cases can level up our coding game. Ready? Let's dive in!
A test case is a detailed document specifying conditions under which a developer assesses whether a software application aligns with customer requirements. It includes preconditions, the case name, input conditions, and expected results. Derived from test scenarios, test cases cover both positive and negative inputs, providing a roadmap for test execution. This one-time effort aids future regression testing.
Test cases offer insights into testing strategy, process, preconditions, and expected outputs. Executed during testing, they ensure the software performs its intended tasks. Linking defects to test case IDs facilitates efficient defect reporting. The comprehensive documentation acts as a safeguard, catching any oversights during test case execution and reinforcing the development team's efforts.
Different types of test cases exist, including integration, functional, non-functional, and unit.
For this blog, we will talk about unit test cases.
Unit testing is the process of testing the smallest functional unit of code. A functional unit could be a class member or simply a function that does something to your input and provides an output. Test cases around those functional units are called unit test cases.
There are various frameworks for unit test cases, including:
Jest is used and recommended by Facebook and officially supported by the React dev team.
It has a great community and active support, so if you run into a problem and can’t find a solution in the comprehensive documentation, there are thousands of developers out there who could help you figure it out within hours.
1. Performance: Ideal for larger projects with continuous deployment needs, Jest delivers enhanced performance.
2. Compatibility: While Jest is widely used for testing React applications, it seamlessly integrates with other frameworks like Angular, Node, Vue, and Babel-based projects.
3. Auto Mocking: Jest automatically mocks imported libraries in test files, reducing boilerplate and facilitating smoother testing workflows.
4. Extended API: Jest comes with a comprehensive API, eliminating the necessity for additional libraries in most cases.
5. Timer Mocks: Featuring a Time mocking system, Jest accelerates timeout processes, saving valuable testing time.
6. Active Development & Community: Jest undergoes continuous improvement, boasting the most active community support for rapid issue resolution and updates.
Describe
It
Matchers
| // For each unit test you write, | |
| // answer these questions: | |
| describe('What component aspect are you testing?', () => { | |
| it('What should the feature do?', () => { | |
| const actual = 'What is the actual output?' | |
| const expected = 'What is the expected output?' | |
| expect(actual).toEqual(expected) // matcher | |
| }) | |
| }) |
Mocks: They are objects or functions that simulate the behavior of real components. They are used to create controlled environments for testing by replacing actual components with simulated ones. Mocks are employed to isolate the code being tested, ensuring that the test focuses solely on the unit or component under examination without interference from external dependencies.
It is mainly used for mocking a library or function that is most frequently used in the whole file or unit test case.
Let Code.ts be the file you want to test.
| import { v4 as uuidv4 } from uuid | |
| export const functionToTest = () => { | |
| const id = uuidv4() | |
| // rest of the code | |
| return id; | |
| } |
As this is a unit test, we won't be testing the uuidV4 function, so we will mock the whole uuid module using jest.mock.
| jest.mock('uuid', () => { uuidv4: () => 'random id value' })) // mocking uuid module which will have uuidV4 as function | |
| describe('testing code.ts', () => { | |
| it('i have mocked uuid module', ()=> { | |
| const res = functionToTest() | |
| expect(res).tobeEqual('random id value') | |
| }) | |
| }) |
And that's it. You have mocked the entire uuid module, so when it is coded during a test, it will return uuidV4 function, and that function, when executed, will give a random id value.
Spies: They are functions or objects that "spy" on other functions by tracking calls made to them. They allow you to observe and verify the behavior of functions during testing. Spies are useful for checking if certain functions are called, how many times they are called, and with what arguments. They help ensure that functions are interacting as expected.
This is by far the most used method, as this method works on object values and thus can be used to spy class methods efficiently.
| class DataService { | |
| fetchData() | |
| { | |
| // code to fetch data | |
| return { 'real data'} | |
| } | |
| } |
| describe('DataService Class', () => { | |
| it('should spy on the fetchData method with mockImplementation', () => { | |
| const dataServiceInstance = new DataService(); | |
| const fetchDataSpy = jest.spyon(DataService.prototype, 'fetchData'); // prototype makes class method to a object | |
| fetchDataSpy.mockImplementation(() => 'Mocked Data'); // will return mocked data whenever function will be called | |
| const result = dataServiceInstance.fetchData(); // mocked Data | |
| expect(fetchDataSpy).toHaveBeenCalledTimes(1) | |
| expect(result).toBe('Mocked Data'); | |
| } | |
| } |
One of the best uses of Jest is to mock a database call, i.e., mocking create, put, post, and delete calls for a database table.
We can complete the same action with the help of only Jest spies.
Let us suppose we have a database called DB, and it has lots of tables in it. Let’s say it has Table Student in it, and we want to mock create a Student database call.
| function async AddStudent(student: Student) | |
| { | |
| await db.Student.create(student) // the call we want to mock | |
| } | |
Now, as we are using the Jest spy method, we know that it will only be applicable to objects, so we will first make the Db. Students table into an object with create as method inside it, which will be jest.fn() (a function which can be used for mocking functions).
Students an object with create as method inside object which will be jest.fn() (a function which can be used for mocking functions in one line without actually calling that function).
| describe('mocking data base call', () => { | |
| it('mocking create function', async () => { | |
| db.Student = { | |
| create: jest.fn() | |
| } | |
| const tempStudent = { | |
| name: 'john', | |
| age: '12', | |
| Rollno: 12 | |
| } | |
| const mock = jest.spyon(db.Student, 'create'). | |
| mockResolvedvalue('Student has been created successfully') | |
| await AddStudent(tempStudent) | |
| expect(mock).tohaveBeenCalledwith(tempStudent); | |
| }) | |
| }) |
Sometime, in development, we write private code for classes that can only be used within the class itself. But when writing test cases, we call the function by creating a class instance, and the private functions won’t be accessible to us, so we will not be able to test private functions.
But in core JavaScript, there is no concept of private and public functions; it is introduced to us as TypeScript. So, we can actually test the private function as a normal public function by using the //@ts-ignore comment just above calling the private function.
| class Test() | |
| { | |
| private private_fun() { | |
| console.log("i am in private function"); | |
| return "i am in private function" | |
| } | |
| } |
| describe('Testing test class', () => { | |
| it('testing private function', () => { | |
| const test = new Test() | |
| //calling code with ts-ignore comment | |
| //@ts-ignore | |
| const res = test.private_fun() // output ->> "i am in private function "// | |
| expect(res).toBeEqual("i am in private function") | |
| }) | |
| }) |
P.S. One thing to note is that this will only work with TypeScript/JavaScript files.
Makes code agile:
In software development, one may have to change the structure or design of your code to add new features. Changing the already-tested code can be risky and costly. When you do the unit test, you just need to test the newly added code instead of the entire program.
Improves code quality:
A lot of bugs in software development occur due to unforeseen edge cases. If you forget to predict a single input, you may encounter a major bug in your application. When you write unit tests, think carefully about the edge cases of every function in your application.
Provides Documentation:
The unit test gives a basic idea of what the code does, and all the different use cases are covered through the program. It makes documentation easier, increasing the readability and understandability of the code. Anytime other developers can go through the unit test interface, understand the program better, and work on it fast and easily.
Easy Debugging:
Unit testing has made debugging a lot easier and quicker. If the test fails at any stage, you only need to debug the latest changes made in the code instead of the entire program. We have also mentioned how unit testing makes debugging easier at the next stage of integration testing as well.
So, if you made it to the end, you must have some understanding of the importance of test cases in your code.
We’ve covered the best framework to choose from and how to write your first test case in Jest. And now, you are more confident in proving bug-free, robust, clean, documented, and tested code in your next MR/PR.
.svg)
.svg)
.png)
