More than just static expected output values at unit tests

We’ve discussed this feature and came to the preliminary conclusion that this is not something we are very excited to support.

The piece of logic that says dateadd(month, 1, getdate()) would be verified with an expression in the unit test that is exactly the same. The risk of programming errors on both the code and the unit test is equal at that point. We are trying to avoid logic in the unit tests as much as possible, also to prevent copy-pasting expressions from the actual logic to the unit tests.

We came to the conclusion that logic that needs to be tested is generally not the correct behavior of the dateadd function or the getdate() function. These are built-in functions that do not really require a unit test.

When the months to be added is a static number, creating a unit test becomes debatable. The logic becomes interesting to subject to a unit test when the actual added months to the current date is variable, based on a decision. This decision should then be covered by a unit test.

To allow for a more testable system in these scenarios, it would be an option to create columns for the creation date and the number of months to add. A calculated column or expression can be used to display the result date to the user.

There are a lot of votes for this idea, we’d love to hear further input.

In the meanwhile, we will work on implementing the following comparisons for unit test checks:

• is not null
• is null
• equals

In the 2021.2 version of the Thinkwise Platform, the following comparisons for unit test checks will become available:

• is not null
• is null
• equals

The necessity of being able to work with dynamic values becomes necessary when testing legislative or business rules. Determining an ultimate response date or a delivery date has probably a function without an input for the current day, but has an output that is dependent on the current day.

Although I understand that this is probably a duplication of the functionality (at least in part), creating another sort of unit test probably requires writing another procedure that surrounds the unit test. And in this way losing the focus on this particular unit test.

One of the reasons we have unit tests is also as a warning that something has changed and is tested. Keeping this as close to the unit as possible is preferable … at least in my opinion.

But am curious to know why you prefer to either skip the unit test or embed it into a unit test of a specific test-procedure.
​​​