1

The CMS we're developing is getting really messy. One of the failing parts is "unit testing".

To put it simple: what we call unit testing actually is something rather vague, closer to integration and functional testing, but one of my coworkers (which unofficially is our lead) doesn't care about "sticking to the definitions": "the tests I wrote works, that's all".

Still, the tests are quite ugly. Virtually 90% of the code can't be properly tested, for multiple reasons:

  • they decided (before I dropped in) to use an "in-house autoloader", calling an object method to "import" modules,
  • most objects need the "context",
  • heavy coupling,
  • violations of most "OOP principles",
  • etc.

All of this ends up in:

  • bloated setups / tear-downs,
  • non deterministic tests,
  • state leaking,
  • tests of class A suddenly failing because we modified class B,
  • etc.

For sure, it is sometimes inevitable that unit testing some parts turns out being complex and not "ideal", but should I keep considering that not being able to properly unit test most part of the source code is a major code smell? Could it serve as a strong argument to try to stick our code base into something cleaner before we even keep adding on it?

I am asking, because I am from the PHP world, where we now tend write more and more rigid, strictly typed, "SOLID aware" code... I'm not really confident in discerning what's really wrong, and what's related to Python (for goods or bad).

||improve this question||||
  • Both "SOLID compliant" and extreme unit testing can also be code smells, one due to the introduction of over-engineering, and the second due to the the destruction of encapsulation as well as over-testing (i.e. testing internal details that have no testing value). I am sure all your concerns are completely valid, but you should be aware of the controversy in the expression of your opinions. – Frank Hileman Mar 9 '17 at 17:43
  • Yes, you're totally right. I tend to say things without nuances, even though I do know that it's only "right" to some extent... Like when saying "singleton are evil", although they do are the best options from times to times ;) – Shirraz Mar 9 '17 at 17:48
  • 1
    The biggest issue that stands out for me, that you have noticed, is the state leaking, and non-deterministic tests. Neither SOLID nor true unit testing address that directly. If tests are hard to write, the API (libraries and object models) are usually problematic. So I am sure you are correct. I think you should clean up the code base. – Frank Hileman Mar 9 '17 at 17:51
2

Clever loaders, non-OOP style, and even the need for a context everywhere may be present and still not preclude heavy test coverage. I've been on a project like that. Most of it can be mocked in a controlled way, helping testing.

'Heavy coupling' seems like a real problem. If you cannot run an important piece of code providing a few mocks, and maybe a test database, it's a reason to start rethinking the code structure around that piece.

State leaking also looks bad.

I hope you'll have no trouble explaining your colleagues why hard-to-test, untested code is bad, and why heavy coupling, both via call graph and data flow (especially state) is bad for maintainability, ease of feature development, etc.

||improve this answer||||
  • Well, "explaining" anything would be another problem... Our "lead" is like hating on instances, patterns, common wisdom, anything higher level than C/assembly... I tried once to explain him that static method calls are one of the worst ennemies to testability (he does call static method from static method A LOT)... He ended up "teaching me" that static method never had been a problem, that I am just not good enough as a dev... – Shirraz Mar 9 '17 at 21:23
  • @Shirraz: In Python @staticmethod is indeed a rare beast and is usually a smell. Fortunately, grafting a same-named method onto an instance under test helps, since the instance method will be dispatched first. (With Java, things are much harder.) – 9000 Mar 9 '17 at 21:42

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.