TABLE OF CONTENTS
A unit test is a few lines of code which tests a small part of the product’s source code and checks the results obtained. This process of checking the code is called agile unit testing. The developers in the product team make use of this when developing a product.
Unit tests can have either one of two results and are hence binary in nature. The result would be 'pass' if the code acts in accordance with the expectations. If this is not the case, the result would be 'fail'.
Usually, developers write a large number of unit tests to validate the various program behaviors. This makes up a 'test suite'. The results are identified by color code by common convention. The green color represents that all unit tests in a program have passed. Red shows that one or more unit tests have failed. These color codes have been accepted for quite a few years now, dating back to JUnit at least.
'Test-runners' are a type of software to execute unit tests. The developer provides the following info in unit tests:
Then, the dev executes their code with the input and compares results with the expected one. You can consider this as a 'pass' when the results of the execution match the expected results. If not, the test is a 'fail'.
In the event that a code depends on external data, it cannot be fully tested. In such cases, the dev replaces the external dependencies with 'mock data'. Mock data is static data that is used to restrict the tests to the functionality of the unit.
So how did agile unit testing come about? David J Panzl, a well known agile author, wrote a series of articles talking about tools with features very similar to JUnit. This was in 1976, and these articles testify the long history of automated unit tests.
The years 1988-1990 saw a rise in event-driven GUI software. Testing challenges in these paved the way for capture and replay test automation tools. Companies like Segue and Mercury made these, and they went on to dominate the market for about a century.
In 1997, JUnit, the testing tool, was written by Beck and Gamma. It drew inspiration from Beck's prior work on 'SUnit.' JUnit grew massively popular over the next few years, ending the 'capture and replay' age.
Unit testing is popular as it serves the following use cases and makes the life of the developer easier. All these make unit tests indispensable to the development process.
There are two main steps to unit testing in agile. One is to write code that is testable. The other, to use suitable software to test this code.
The first step, to write testable code, means that the functions you write to test the code should be clean. This means that they shouldn't have side effects and should only work on the given parameters. So, there should be a minimum number of parameters as every new parameter makes testing a lot harder. This is because you then have to test all sorts of combinations with these parameters. There should also be no external dependencies. For this, the mock data spoken of above proves handy.
The next is to use the right tool. A number of tools are used for unit testing in web projects. Some examples are:
The app you're developing would decide the unit testing software that you need.
Some things to remember while making use of agile unit testing are:
Name the test methods such that it makes the need clear and you don't have to look at other places for info. There are many popular unit testing naming conventions you can make use of for this.