1

I'm looking to add some junit to our code base.

We have a set of classes that inherited from an abstract base class. The inheritance is several layers deep (Base-> A, B, C ->C1, C2, C3->C3-1, etc). Sometimes someone overrides a method of a class (Class A) which has several child classes. But because of that, we get bad results for those in call children classes of Class A.

So, I'm looking for solutions to be able to try to prevent this and create a testing framework to deal with this.

My initial though is that we would need to create a TestSuite that would need to check that the TestClass has at least 1 test case for every method in the Base class via reflections. This would make sure the person who added a overridden a method in a mid-level Class know that their change will affect child classes.

Also, I was talking to someone who said that there might be library already out there that does this.

I'm looking for thoughts and examples of how to write tests to handle this scenario. Refactoring is not an option in this case.

S T
  • 61
  • 2

1 Answers1

1

Sorry, but the proper answer to a bad design is not to "fix" it by coming up with "interesting" unit tests.

You fix a bad design by fixing the bad design.

In other words: the very first thing about OO to understand is LSP (Liskov substitution principle). In other words: when your developers change something in "the middle" of your inheritance tree, and that causes unexpected behavior in child classes further down, then you should rather invest in education and design sessions.

Beyond that, you don't need specific testing. When all public methods of your public classes are thoroughly tested, then you should quickly catch such kind of problems. But there is no way to determine pro grammatically that you have good tests for all classes. The fact that there are n test methods for some method X ... doesn't tell anything about the quality of any of the test methods. It doesn't help to know that you have "enough" tests ... but sorry, unfortunately, half of the tests isn't doing proper checking/verification; and thus they just keep passing all the time.

Long story short: you are looking at an XY problem here. Your Y problem is "our tests don't fail when we mess up code". But your X problem is: you created a bad design in the first place; and now you are searching for ways to work around that. And that will simply not work out in the long run.

Community
  • 1
  • 1
GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Was hoping for an answer like this. He he – David Rawson Feb 06 '17 at 01:53
  • You are very welcome. Although I have the vague feeling that the OP won't be too happy about it. – GhostCat Feb 06 '17 at 04:15
  • 1
    @GhostCat I'm not mad, I'm not happy. I'm just trying to deal with the situation at hand. In a perfect world, we all write tests, do code reviews and refactor and live with a beautiful code base. Unfortunately, that isn't the case here. I'm trying to make the best of what I can do with the code base given the situation. – S T Feb 08 '17 at 01:49
  • @ST As said: the key point is that you can "construct" (generate) testcases automatically. The only thing that helps here is to have **good** tests for **each** of your child classes; so that you at least notice when some C breaks because A was changed. – GhostCat Feb 08 '17 at 15:39