How to organize my test functions?

Question

I'm writing a software application of a few thousand lines of code (in Python), and in order to keep the whole thing together, slowly but certainly the need for unit tests (and later, other types of tests...) has arisen.

My problem is how to organize the many testing functions that I've written so far: Suppose I have a function myfunc for which I want to write tests. What I have are functions like so:

test1pos_myfunc():
    #...

test2pos_myfunc():
    #...

test3pos_myfunc():
    #...

#and so on...

that each test whether one input if myfunc delivers the correct output. Then I also have another suite of functions where I test where the correct exceptions get thrown if I give bad input to myfunc; these are

test1neg_myfunc():
    #...

test2neg_myfunc():
    #...

test3neg_myfunc():
    #...

#and so on...

This setup seems less than ideal, in particular for "negative" tests, because often I group together those functions that test whether the same exception gets thrown - e.g. test1neg_myfunc, test2neg_myfunc and test3neg_myfunc might all test if the same exception MyError gets thrown for different inputs and test4neg_myfunc and test5neg_myfunc might test if the same MyHorribbleError gets thrown.

Now if I want to add one more testing function to test ´MyError` I have to renumber all the other functions. What would be a better way to organize this?

Here are some solutions I thought of, but none satisfy me:

• use the name of the exception in the function name and restart numbering for every test of a new exception (seems like a bad idea, because it will reduce readability), e.g. test1MyError_myfunc, test2MyError_myfunc and so on.

• take all tests of one exception and lump them as methods in a class; and then also lump all tests belonging to one function in a class (this is better my test names will become shorter and - but then again it feels bad, because I'm importing a concept from OOP into a setting where I'm programming strictly procedurally! And using a class just to lump together some functions seems overkill; doesn't Python offer anything better as a container to store other things?)

• outsource all the tests, similar to the organization in classes, in different modules (everything I wrote about classes applies, but with the huge disadvantage that I will have a ton of files then laying around)

Can anybody come up with something better? What are industry standards here? (I'm a novice programmer.)

Answer 1

In general you should be able to understand what a test does/checks from only looking at its name. That means you should give your tests expressive names. This could also include very long names that you typically don't use in your production code. A common naming scheme is related to Meszaros four phase test pattern (Arrange, Act, Assert, Annihilate). This means your test consists of four parts. In the first part you "arrange" your test fixture by configuring the object you like to test (System Under Test / "SUT"). In the second part you tell the SUT to "act" by calling a method and in the third "assert" phase you verify your expectation. The three phases can also be reflected in the name of the test method. You often find names that read like Given_When_Then.

In the "Annihilate" phase you usually tear down dynamically created objects used in the test. You will mostly find this if you need to do the memory management manually.

Please, also be aware that your unit tests should be independent of each other. That means that your tests can be executed in any order. Numbering your tests suggest that they should be executed in a certain order.