“Unit Testing” is a tricky affair. I am pretty sure that testers at some point in time would have complained about the developer not doing unit testing properly and delivered a poor quality build. On the other hand, developers find it difficult to create and maintain unit test cases along with maintaining the agility of the system.
Whatsoever, there is no doubt that unit testing is a crucial part of SDLC and the first step towards testing.
Here I am going to discuss more the unit testing standards which we can leverage in our testing and automation to make it more effective and efficient.
What is unit testing?
Unit testing is a type of testing which is performed to ensure that individual units or components of the application are working as expected. The units or components, in this case, are independently tested using stubs and drivers. Unit testing is crucial as it finds out defects at an early stage and thus reducing the overall project cost and ensuring the code stability.
As a tester, It is also our responsibility to make sure that unit tests are part of our deployment pipeline. As the role of QA has evolved in the last few years, they not only perform functional and integration testing but also actively participating in unit testing. In continuous integration and delivery, the role of QA has become multidimensional and more agile. It’s important to know what unit tests are executed as a part of the release and what is the coverage. I am not going to discuss the importance of unit testing here, I believe that’s pretty clear to everyone.
This article is about how unit test cases are designed and how we can leverage that in our automation test design.
Understanding the concept of unit testing-
It’s important to understand the core concept of unit testing. A unit is any entity that can be executed independently. It can be a few lines of code or an entire feature for that matter. The bottom line is it should be an independent executable piece of code. Here is the first take away.
While designing out automation framework, we should also treat our tests as a single independent unit so that they can be tested and executed independently.
Unit testing involves unit test frameworks, drivers, stubs and mocks /fake objects. It works on the basis of a white box technique where conditions, loops, and code coverage are tested.
Below are some unit testing principles which equally hold good for automation testing, let’s revisit them-
- Tests should be independent- This is the basic principle, there should not be any dependency among the test cases. This is important because one test case result should not impact subsequent cases.
In automation, we should make sure that there is no dependency such as environment setting, creating instances of shared resources and cleaning up the same. - Tests should be deterministic- A test should either pass or fail all the time. The worst test is the one that passes some of the time. We should always have a definite reason if the test fails and when correcting that, the test should always pass.
- Tests should hold good for pass/fail cases- By this, I mean that a test should fail when it meant to fail. Put assertions carefully and run the test for a fail condition also.
- Tests should be self-validating- This means that the test should itself determine that the output is expected or not. There should not be any manual interpretation.
- Repeatable- Test should produce the same output every time it runs. This can be accomplished by making them isolated and independent.
How unit testing is performed
Unit testing requires Mocking. It works on mock objects that fill the missing part of functions to be tested. As the other components are still in development or yet to develop, we would need some piece of code to ‘act’ like those components.
Another crucial component of unit testing is APIs. APIs provide an interface for communication between two components. APIs contain business logic and the way APIs work makes it very handy to use them in unit testing.
Both mocking and API go hand in hand to perform unit testing.
How test automation leverage from unit testing-
With more and more organizations going into the agile model, testing (both manual and automation) starts in the initial phase of SDLC. To expedite the process automation has a key role to play. Now we know that in agile requirements keep on changing, development is still in progress and in that situation, API and mocking can be very helpful for automation.
Use of Mock objects- Data mocking can be used to speed up the process rather than depending on the real test data. When the automation test interacts with an object’s properties rather than its functions and behaviors, mocking can be used. Mocking is mostly required when an application interacts with any external service but it can be used in other scenarios also.
A mock object can be used when the real object is:
- Slow in operation, for eg- Database access
- Hard to trigger for eg- A server crash scenario or a network error.
- Still in development.
- Not compatible or needs high-cost setup for testing environment.
There are various libraries available for Mocking. Some mocking frameworks are- Mockito, powermock, and easymock for mocking.
Use of APIs- let’s come straight to the point, APIs are faster. Also, API tests are reliable. UI tests can be flaky and slow to execute but API tests will either pass or fail. Of course, we need UI tests but its always a good idea, to begin with, API testing. APIs are developed before UI in most cases so we can always kick start with API testing.
APIs are also useful while writing integration tests and an end to end testing. We can always integrate APIs in the UI test framework to perform pre-requisite. APIs make them faster and thus reduce overall test suit execution time making it more efficient for releases.
To know more about API testing, you can refer to-
Conclusion- Almost all unit testing principles and techniques are relevant to the automation and automation engineers should leverage them as and when needed rather than only relying on the traditional automation methods.
Published on Java Code Geeks with permission by Arun Kulkarni, partner at our JCG program. See the original article here: Better QA: Learning from unit testing standards Opinions expressed by Java Code Geeks contributors are their own. |
