You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Speeding up writing Unit Tests

0.00 avg. rating (0% score) - 0 votes

Unit Tests writing, contrary to popular coding humour, is an important aspect of the development process. The process of writing Unit Tests reveals setbacks in one’s code. It helps us identify complicated logic, magical functions, magic inside functions and non testable pieces of code

(ex: – an if condition which is impossible to execute).

Most of the programmers find writing Unit Tests tedious and cumbersome. But at Naukri we transform it into a fun way of learning more about the code base we are working on.

Creating a test file is initially a repetitive process. It involves declaring a class which extends a KernelAwareTest file, instantiating an object of the original file, of which the UT is being written, writing data providers and finally executing the function to obtain and assert/compare the result.

To tackle this problem at Naukri, we employ the use of skeleton generator. It is a utility which automatically generates an empty test case file for us to work upon. With all the grunt work out of the way, we now can put our entire focus on writing test cases.

$ phpunit-skelgen generate-test –bootstrap=”path/to/bootstrap.php.cache” className path/to/class testFileName path/to/testfile

Use Case : A JobSearch Team’s Perspective

Having an increased Unit Tests coverage in each iteration is one of the KRA’s of the entire team. Not to mention that a 100% Unit Test coverage is imperative for CI/CD to work. In our effort to achieve this coverage goal, we use a strategy every iteration.

A zero point story is put in each iteration consisting of the targeted files for Unit Tests coverage. Each member of the team takes the ownership of one of those particular files. Then, the skeletons of all the files in the story are created and pushed into origin at the beginning of the iteration itself.

In this way, those are circulated with the initial pull and everybody has access to all the skeletons.

With the natural progression of the iteration, consecutive pushes and pulls reveal the UT growth in the code to all the members irrespective of which file they took ownership of. In this way, we are able to gradually and significantly improve our coverage with each iteration.

Common issues we encountered while implementing skeleton generator :- 
(and how we tackled it)

1. Class not found error.

Sometimes the utility may throw a runtime exception with a message “Class Not Found”. To solve this we commented out all the namespaces and use statement in our original file (of which skeleton is being generated) and reran the command.

2. Parent Class file not found on running the unit test.

We made the namespace of the test file (skeleton file) equivalent to original file (of whom skeleton has been generated). We inserted use statement to import the original file into the skeleton file. We also inserted use statement corresponding to import the PHPUnit class (usually KernelAwareTest).

3. Access to setup() method should be public error.

We changed the access specifiers of the setUp() and tearDown() functions from protected to public in the skeleton file.

What benefits we get from generating a skeleton:-

A setup() method, which automatically instantiates a protected variable ‘object’ which is key to calling original functions of the class you are writing Unit Tests for. Empty test cases for all the methods inside of that class.

By default, all the tests have been marked as incomplete, so running a skeleton file immediately after generating its skeleton will give you tests marked as incomplete.

Now with all the housekeeping out of the way, you can focus entirely on writing your data providers, mocking and logic.