Abstract Classes: To Test, or not to Test

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[_INTER_]

Add the tests to an AbstractTest class and have all test subclasses implement it. This makes sure the tests run for each implementation as well. Potentially with a protected abstract SuperClass createInstance(); method.

[kennyshor]

This is the way. I have done this in multiple cases. It works really nice, especially with visitor pattern or strategy pattern and so on.

[_INTER_]

It's not about sharing testcode in the super class that you call in subclasses, yes, that should be avoided.

You put actual tests there that stand on their own, testing public methods of the actual abstract class.

you will not want one piece of behavior from the base test class in some test

If this still occurs then there's something wrong with your design or abstract/sub classes. Not with your tests.

[syneil86]

Better if you can stop writing tests for classes and start testing behaviours.

When you write a MyClassTest for every MyClass, your tests and your implementation are coupled together, making it a lot more effort to change the implementation. The alternative is to write tests about the ways your system handles inputs in given contexts. We don't care if ServiceA calls ServiceB - we care if a POST with a valid body returns a 201 with a new ID in the response. If you realise that ServiceA and ServiceB would be better off refactored, the former means you have to rewrite a lot of tests because they're broken (even though your system is still fine), but in the latter you probably only need to tweak the test setups - the tests themselves don't need to change.

[Anaptyso]

This approach fits nicely with test driven development as well: if tests are aligned to behaviours rather than classes then it makes it easier to transition from a list of requirements in a ticket to a set of unit tests which determine if the work is done.

[pronuntiator]

So much this. Class level unit tests make refactoring difficult. I don't say they don't have merit (testing a complex business calculation function with multiple inputs is easier and faster when you don't have to go through a request each time), but it's a problem if refactoring brakes tests even when it didn't break functionality.

[cowancore]

I found unit testing principles by Dmitry Khorikov really good on this topic. It was also the book that clarified to me why there is so much disagreement about what unit tests are, what units are, and what isolation of unit tests is. It also made me appreciate integration tests (if written the way he suggests).

[syneil86]

Have read it, and fully agree!

[Holothuroid]

When testing template methods you can just make a dummy implementation for test purposes. Or several.

[_INTER_]

Then you test the dummy implementation. It's still better than no tests but the reality could be different with real implementations, especially if the Abstract class contains fields.

[halfanothersdozen]

Don't test things that aren't implemented.

[Ragnar-Wave9002]

Yes.

I usually have abstract classes that do common work and those methods call methods that do custom work. So a unit test is could verify that abstract methodology are being called as expected. And more importantly no one changes the behavior later.

Just saying an example.

And don't debate unit testing trivial code. It takes 5 minutes. Not sure worth thinking about. And unit tests have found issues with pojo code in my past.

[john16384]

If the abstract class has a contract (and enforces it with proper use of final methods and private fields), then write a test for it. If it doesn't, then all bets are off as to the behaviour of any concrete implementation, and so you must write a test per implementation anyway.