2

What are the best practices to organize your unit tests in classes?

I see different possibilities:

1) One would be to write one "container" class for each function you want test and then subclass that to group in each subclass all tests that are similar in some way - e.g. one subclass contains all tests where we make make sure the functions throws errors correctly and one class that contains all tests where we make sure that the function does what it's supposed to.

2) A different one would be to group tests for different functions in one class: Suppose we want to test the functions myprint and mysearch. Instead of having as previously 2 (sub)classes per function (i.e. 4 in total, Test_myprint_Error, Test_myprint_OK, Test_mysearch_Error, Test_mysearch_OK), now we have only 2 classes in total (TestAllErrors and TestAllOK), one containing all tests to check for each function that errors are thrown correctly and one containing all tests that everything works as intended, again for each function (So we have the same tests as in 1), but just arranged differently in classes.)

3) I could come up with even more ways to group tests in classes, but I'll stop here.

(In part 1 of my question I received general advice how to organize my suite of testing functions, but now I'm interested in this more specific query.)

  • Search for videos of Kevlin Henney discussing tests and testing. – VoiceOfUnreason Feb 4 at 21:59
  • @VoiceOfUnreason These are hour-long videos that cover much more than I'm asking here! I can't possible spend days just watching all of his youtube videos to get this answered. But if you could turn the relevant bits from the videos into an answer, I could accept it. – l7ll7 Feb 5 at 9:54
  • 1
    Ok I browsed some more through the first 3 youtube videos of him; while there were a ton of vague, general principles that were discussed, nothing seemed to come even close to the specific question that I have. – l7ll7 Feb 5 at 10:05
  • I don't think there's an universal answer here for all types of code. – bitsoflogic Feb 7 at 16:46
  • In general, I like to separate out the unit tests from the use-case and integration-tests. I find the use-case tests to be your regression tests, while the unit tests are just there to help you code up a method and can be thrown away. For the unit tests, which I think you're asking about, I like to match one test file to the file under test (but this is really bikeshed territory; any convention that is simple to reason about and is consistently followed is good). – bitsoflogic Feb 7 at 16:50
3

What are the best practices to organize your unit tests in classes?

The most interesting structured approach I have seen is that described by Kevlin Henney, what he calls "Propositional Style Naming", using a Most Recently Used List as an example.

His hierarchical structure is based around Hoare Triple's, which you will recognize if you have ever invested in Given-When-Then or Arrange-Act-Assert.

  • At the top level, he names the specification itself.
  • At the second level, he names the precondition from which all of the tests will start
  • In naming the test, he describes the post condition.

In the environment that he is using, when you ignore the boilerplate what you get is something that looks like an outline.

Presumably, that will give you a decent structure in any test reporting framework that supports hierarchical groupings of test results.

  • So in the usecase I mentioned in case 2), how would that translate (very roughly) to the Henney's outline? (I'm more of a beginner in programming and not really familiar with Hoare's triple et al) – l7ll7 Feb 11 at 20:04
1
+50

Approach designing your tests in the same way you approach other software design activities. Your test code is code that has to be understood and maintained, and as such, all of the packaging and naming considerations you apply to shipping software should apply to your test software.

As such, a test function needs to gather resource, set up the unit under test, run the test and determine whether the test passed. Gathering resources is usually done by executing the function in a context that supplies the resources, for instance, a class or set of classes with mixins that puts together the resources, initializes them and wires them together.

This test provisioning process is often critical to any non-trivial testing that you may do, and will often drive the design of testing process.

  • How would the usecase I mentioned in case 2) translate (very roughly) to the Henney's outline? (I'm more of a beginner in programming - Python and pytest.) Would either setups of either cases make sense? – l7ll7 Feb 11 at 20:05
  • I cannot imagine the need for separate classes for separate methods. However, create the test classes around what is necessary to provision the testing process. In particular, for testing the printing functionality, you would want a test harness that can inspect the output of the printing function. – BobDalgleish Feb 12 at 13:28

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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