Re: writing unit test for calc functions

On 16/04/16 16:29, Winfried Donkers wrote:
> One (personal) remark: deciding which use cases, which values, etc. to
> use for unit tests is a bit of a vague area for me. Arguments can be of
> different types (e.g. string, double, single/double external/internal
> reference, matrix, single value or range), can have almost unlimited
> different values and can be optional. Testing all use cases would fill a
> lot of cells and doesn't seem practical to me. But for deciding which
> use cases to test and which to skip clear guidelines would be a great
> help (for me at least).

Might this be an idea ...

The first sheet is a summary sheet.

Functions come in classes - put one class per sheet in the subsequent
sheets.

Each sheet has a sum of how many tests failed, which is then carried to
the first sheet, which then sums that lot up to give a total failure count.

So in the first instance all that needs to be checked is the one cell
that is the total failure count. If that's positive, then checking the
first sheet manually tells you which group of functions contains the
failure. You can then go to that sheet to find which specific tests failed.

Deliberately skipping tests is, I think, a recipe for disaster -
remember Murphy, "if it can go wrong, it will choose the most
inopportune moment to do so".

Clustering tests by function class then enables us to add tests as we
see fit - maybe have guidelines that says "testing just x,y and z is
acceptable as a first stab at it", but anybody working on a function
should add/update the group of tests for that function, making it as
comprehensive as possible.

Actually, it might be an idea, although putting a classes of functions
in separate sheets, maybe each function has a sum of how many tests
failed and that goes on the front sheet, so scanning the front sheet
tells you which function specifically has failed, not which group of
functions has a problem.

Cheers,
Wol