TDD4C (“Test Driven Development 4 Consulting”) is small library that allows logics to be run locally in Studio as well in any Continuous Integration service such as GitLab, GitHub, BitBucket, Azure or others. The main goal is to provide simple and easy way of writing unit tests for the logics. 

When to write unit tests

Writing and maintaining tests can be very time consuming effort so you should use them wisely.

Since the configuration evolves during the project and the logic change massively during the development sprints, the unit tests created early in the projects typically cannot identify many bugs and the maintenance effort and cost is huge. So it usually does not pay off. However, as the project goes to UAT or GO LIVE phase, the importance of unit tests grows. All the bugfixes or changes introduced after acceptance testing may have an impact on the functionality and therefore the functionality should be retested. With the big number of such changes the need of retesting grows. And that’s the moment having unit tests can pay off.

Not all the types of logic support unit testing or the testing does not pay off. Thefore the focus should be always on:

• functionality that is most critical and has to work without a compromise, or

• most complex functionality that is difficult to oversee, or

• functionality that most time consuming to re-test manaully

Prerequisite for development of unit testable logics

The unit testing should be independent of the partition data being queried by the logic - since that data can change. Instead the unit test should be supplied with the same input data sets every time it is run. Therefore it is necessary to follow special practice when coding the logics. Every logic element or a groovy or library function performs either:

• query the data from the partition

or

• use the data for calculation

Querying data cannot be unit tested, only calculation elements or groovy functions can.

Unit testing allows IntelliJ IDEA debugging

There is a positive side effect of mocking API calls: since the API calls to the backend are mocked, backend is not used and that allows you to utilize the built-in IntelliJ debugger to do real step-by-step debugging of the elements.

See more: