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).