[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
daniel jaimini wrote:Inheriting a common base class in all subclass practice is followed by many high-end developers, so it won't be problematic at all
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Junilu Lacar wrote:I may seem overly pessimistic with my responses but I'm speaking from first-hand experience.
My last client (my day job is consulting as an Agile technical coach) had such a base test class as I've alluded to in my first response. That base test class had methods that took care of setting up database connections, message queue connections, and other infrastructure concerns. Then they instituted a policy that required developers to extend this class for all their tests, including unit tests.
When I tried to coach them on TDD (Test-Driven Development), we had to wait literally for 5 minutes for each compile/build/test to finish because the tests were all end-to-end tests and did all kinds of infrastructure configuration and setup. You can't do TDD if your red-green-refactor cycle time is at least 20 minutes. And that is just one cycle.
The whole test suite was like that. They had builds that ran forever. Ok, they ran overnight, so developers would leave for the day and come back next morning to find that the tests failed. The tests were flaky, failing inconsistently because of race conditions the tests themselves unintentionally created because of that infernal base test class.
So you see, I'm not just Chicken Little running around telling you that the sky is falling. If you are not careful and you don't entirely know what you're doing (why would you ask the question you did in the first place?), then it is highly likely that the weight of a poorly-designed base test class will eventually make your sky fall down on you.
Junilu Lacar wrote:Stephan cites one valid use case that I have seen is a valid use of inheritance for test cases. This also applies to contract testing, where you have an interface and you want to test various implementations of it. Again, LSP is the motivation. How many people do you know who can properly explain what that principle even means, much less properly design classes that adhere to it? My experience tells me there are more people who can't than can which is why I would advise extreme caution and an overabundance of thoughtful consideration before proceeding to go against "prefer composition over inheritance."
Tom Joe wrote:Seems like a problem with the company policy rather than with using inheritance in tests. Could they have solved the problem by simply having a different base class for unit tests ? If yes, then would inheritance still have been a problem for them ?