Hi!
When unit-testing, for instance default control procedures, I would like to to be able to compare the expected output with something else than a static value. It would be nice to compare the test result with the result of a query or even something like NOT NULL.
I need to check if the result of the test matches the current date + 1 month. Since this changes every milisecond I can’t compare this to a static value. It would be great to compare it to:
dateadd(month , 1 , getdate()) But comparing it to NOT NULL would help too, since this at least gives some convidence that the code is behaving as expected.
As it is, I see no way to create a functional unit test for this default code procedure.
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
dateaddfunction or thegetdate()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:
In the 2021.2 version of the Thinkwise Platform, the following comparisons for unit test checks will become available:
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.