The testing phase is one of the most essential phases of the software development life cycle process. The different types of testing discussed in this article can be executed through both manual and automated tests. But how do you know which testing is best for certain parts of the application testing? How do you know you will get full test coverage?
This article will cover:
Unit testing
Integration test
System test
Why do we need all these different types of tests?
Unit testing
A unit test can be seen as the first building block of testing. The unit test should test the smallest part of the code that you can isolate in a system. Unit tests should not rely on any external systems or factors. This includes interacting with a database, file system, or any other configurations.
Next, you might be wondering, who should be creating the unit test? It is suggested that the developer who created the code creates the unit test for the code. This can even be part of the development phase of the software development life cycle. This is because they are most familiar with the codebase and the different parts of it. They will also be able to know what should be mocked so each part can be tested as a stand-alone unit. It is the easiest to pinpoint what is causing a bug in this part of testing because everything is isolated.
Example
You create a function that takes 2 positive numbers and adds them together.
Test 1- give the function 2 positive numbers and confirms it returned the correct output.
Test 2- give the function a negative number and a positive number and confirm an error message is thrown because the function should only receive positive numbers
Test 3- give the function a string(letters) and a positive number and confirm an error message is thrown because the function should only receive positive numbers
Integration testing
Integration tests are the step-up from the unit tests we just discussed. The purpose integration test is to verify how the different units and modules of the software interact with each other. The reliance on different modules will initially be tested here as well as the data that is being shared between modules.
Next, you might be wondering who creates an integration test as you did for the unit test, this can be done by the developer or a software tester who is familiar with the software being tested. There is usually less integration test than unit testing.
Example
You create an application that takes 2 positive numbers from a user’s input, adds them together, and then returns the sum to the end-user.
Test 1- You prompt the user for an input and pass the received value to the function we tested with the unit test. You then check to make sure the input typed in from the end-user has the same value as what is getting passed into the function. This differs from the unit test because prior we were directly passing a value into our function. Now we are receiving the value from user input. The different entities being tested here are the addition function that you have created as well as the part of the application that interacts and receives information from the end-user.
Test 2- You receive a value returned from the function and now you want to verify that the value is returned properly to the end-user that we tested with the unit test. The different entities being tested here are the addition function that you have created as well as the part of the application that interacts and displays information to the end-user.
System testing
System testing, sometimes referred to as end to end testing, can be seen as the step up from the integration test. This tests a complete user workflow. Because the tests usually include many different aspects, they often are larger and take longer to run than the unit and integration test. It is always best practice to have at least one positive and negative flow for system testing.
System testing is usually done by a dedicated tester. The goal should be to have as few system tests as possible because all of the specific different flows should be tested in the unit and integration tests. System tests can also be part of a regression suite for future releases.
Example
You create an application that takes 2 positive numbers from a user’s input, adds them together, and the sum is returned to the end-user.
Test 1- First, you go to the website where your application is located. You then navigate to the addition application and verify it is located where it is supposed to be. You then put 2 positive integers(7,3) into the prompt and verify you are returned the correct sum(10). You then verify that you are successfully able to close the application. This test is very different than the 2 previous types of tests we discussed. It goes through the complete user flow as if they were accessing the application, instead of just pinpointing certain parts of it.
Test 2- First, you go to the website where your application is located. You then navigate to the additional application and verify it is located where it is supposed to be. You then put 2 invalid values(a,-3) into the prompt and verify you are returned an error message(“Invalid values were inputted”). You then verify that you are still successfully able to close the application. This test is very different than the 2 previous types of tests we discussed. Just like test 1, it goes through the complete user flow as if they were accessing the application, but this test 1 negative flow that the user may experience.
Why do we need all of these different types of tests?
The earlier we can catch bugs and defects in the software development life cycle process, the easier it is to fix them. All of these tests should also be written out in the testing plan to ensure the different testing coverage. Unit testing is needed to test all of the different variations that the developed application may experience. The step above, integration tests, serve the same purpose. Because these tests are smaller it allows for testing the different variations efficiently.
System tests are more high level and test the complete user flows. It mimics a usual end-user experience such as actually navigating to the application, using the application, and then closing the application. Because these tests are longer it would be less efficient to try to test all of the different possible variations. This is which is why we leave the different variation testing to the unit and integration testing. This should all be communicated while creating the test plan to make sure full test coverage is created.
コメント