1

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
        #Assign
        #Act
        #Assert

        #Test - 2
        #Assign
        #Act
        #Assert

        Cont...

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?

  • 1
    No, that doesn't seem normal. But why not discuss it with the team? – jonrsharpe May 17 '17 at 18:48
  • 6
    Possible duplicate of Is it OK to have multiple asserts in a single unit test? – Doc Brown May 17 '17 at 18:57
  • 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. – Maybe_Factor May 18 '17 at 4:40
  • @jonrsharpe I brought it up and the answer was: personal preference – Godron629 May 18 '17 at 15:24
  • 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 May 18 '17 at 15:34
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! – Steve Barnes May 18 '17 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. – Maybe_Factor May 19 '17 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. – Steve Barnes May 19 '17 at 5:46

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.