I am learning unit testing on the job, at a new job. The testing team is small, (1 other), and all of the tests are written in the following fashion.

class TestClass(unittest.TestCase):
    def testFunction(self):
        #Test - 1

        #Test - 2


So, asserting, then re-assigning the variables and asserting again.

Now, this is different from what I'm reading about unit tests online about unit tests (One test per method).

This makes it hard to debug tests because if there are say, 12 tests, and an error in the 12th, I have to step through 11 different tests to check the stack data and/or errors.

Is this normal?

  • 2
    No, that doesn't seem normal. But why not discuss it with the team?
    – jonrsharpe
    Commented May 17, 2017 at 18:48
  • 6
    Possible duplicate of Is it OK to have multiple asserts in a single unit test?
    – Doc Brown
    Commented May 17, 2017 at 18:57
  • 1
    I have to disagree regarding the above possible duplicate post. That is regarding having multiple asserts for a single test, this one is about cramming multiple tests into a single method. Commented May 18, 2017 at 4:40
  • @jonrsharpe I brought it up and the answer was: personal preference
    – Godron629
    Commented May 18, 2017 at 15:24
  • 1
    Well it seems bananas to me ("I prefer to make my life more difficult in the long run than write one extra line per test"), but it's up to you whether you can accept it or not. If there's only two of you maybe you can extol the virtues of doing things that make sense.
    – jonrsharpe
    Commented May 18, 2017 at 15:34

1 Answer 1


Is this normal?

Sadly, yes. Many don't see the benefit of writing one test per test class method and instead seem to focus on the speed of writing tests with multiple tests per method. Basically they take the easy way out and write things in a way that is easy to write, rather than easy to maintain.

How can we change this behavior (i.e. the unspoken question)? By writing the best tests we can so that, hopefully, other people will have to deal with our tests breaking in the future and then notice that it is easier to figure out what is happening when a method is doing only one test. I also tend to mention this during code review, although due to time constraints it is rarely implemented.

  • "Time. The enemy of us all." plus budget of course! Commented May 18, 2017 at 5:51
  • Indeed, Time is money (a.k.a budget). By using best practice testing, we can hope to save money and time in the future with more maintainable tests, rather than trying to save time in the present by writing quick and dirty tests. Commented May 19, 2017 at 2:02
  • Unfortunately most program managers are more concerned with how much their project costs than saving the company money in the long term - I don't see a fix for this with the current accounting practices in most companies. Commented May 19, 2017 at 5:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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