I'm writing a software library for some numerical computations. I'd like to use Boost Unit Test framework to write a hierarchical unit-test covering not only basic input/output behavior of functions but also the higher functionality, e.g. correct results to some test problems etc.

However, I'm afraid, that I'll get lost in a complexity of tests. Is there any standard way to list them? Like some unit-test diagram?

  • "I'm afraid, that I'll get lost in a complexity of tests" - is this based on facts because you have already written several hundred tests and loosing control, or is this just something you assume which could happen, though you did not write many tests so far? – Doc Brown Sep 8 '18 at 11:08
  • @DocBrown I assume it will happen - I have several tens of tests and I see, that there will be needed much larger number. – Eenoku Sep 8 '18 at 11:21
  • 1
    Unit tests are for humans. Write them to be readable. Code review them just like normal code. If anyone is getting lost in them then write clearer tests. – candied_orange Sep 8 '18 at 11:28
  • @candied_orange I'm not having problems with unit-test code readability. I'm trying to describe a structure of a large number of unit-tests. – Eenoku Sep 8 '18 at 11:30
  • Describe the structure how? Say I'm a new coder looking at all these tests. Why do I care about their structure? What do I need to be able to do that understanding this structure will help me do? – candied_orange Sep 8 '18 at 11:33

I don't think there is a "standard diagram", but there are naming conventions for unit tests around, like this one or this one.

I would recommend first and foremost to have a good structure and documentation for the library. Then, one should establish a rigid naming convention for the tests so it stays easy to see which test belongs to which part of the library. In general, the structure of unit tests should follow the structure of the subject under test. For example, for every class or module Foo, the related tests could be in a class TestFoo or FooTest. For a more sophisticated convention, follow the links above.

If you go that route, the structure of your lib imposes enough structure on your tests that you do not need some extra "list" or "diagram".


A possible solution is to reduce the complexity of tests. For instance, with property-based testing (eg, ScalaCheck, QuickCheck) a single test could replace several unit tests as special cases. Then the whole testing hierarchy is flattened. Property testing fits maths/numerical applications particularly well, but at a computational cost.

A complementary approach, in line with the OP's hunches, is to use a testing framework amenable to a hierarchy of tests. This goes towards behaviour-driven development (BDD). You could have a high-level function (= BDD "Feature") and low-level supporting functions ( = BDD "Scenarios"). BDD testing tools easily accommodate this hierarchy. Some of them have nice GUIs visually organising, if not diagramming, it. In addition, they can serve as living documentation.

Some BDD references/search terms: "BDD In Action", Dan North, cucumber, serenity tool.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.