0

Class A: Class being tested. Class A extends class B and overrides its method common().

i.e.

class B { 
  fun common() {}  
}

class A : B { 
 override fun common() { 
  if(x) { 
   doSomething() 
} else 
   super.common() }
}

Now if you are testing class A’s common() method, how will you verify that it is calling super.common() from within?

Bharat
  • 904
  • 6
  • 19
  • May I suggest https://stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones is worth a read. – Richardissimo Mar 21 '23 at 08:21
  • @Richardissimo it looks unrelated. Are you sure you linked the correct page? – Bharat Mar 21 '23 at 08:39
  • 1
    Absolutely the correct page. There are 31 answers there, so don't just stop at the first one. Lots of discussions there about whether testing should care about internal implementation details or not; and lots of suggestions about how this can be handled, including scenarios where people decide to test private implementation details, or refactor the code because they then realised that if it was so important that it should be tested, then perhaps it shouldn't be an internal implementation detail. – Richardissimo Mar 21 '23 at 08:45
  • 1
    For example, have you considered using [composition over inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance). – Richardissimo Mar 21 '23 at 08:49
  • With all due respect, I understand diff b/w composition and inheritance, and what should be tested in a unit test. I have many reasons for an abstract class and a concrete class. Please learn to stick to the context when you answer a question. It saves a lot of time and energy. – Bharat Mar 21 '23 at 11:32
  • 1
    `Please learn to stick to the context when you answer a question.` I didn't offer an *answer*, I offered a *comment*. The "many reasons" that you mention are not cited in your question, so anybody volunteering to help you can't possibly have known this "context"; but I'm glad you've cleared that up in comments. `Please learn` May I suggest that the criticism of someone who is trying to help you was unwarranted, as you didn't provide the context in your question - the context which isn't given can be just as important as the context which is, when trying to help people. – Richardissimo Mar 22 '23 at 13:58

1 Answers1

1

Unit tests are supposed to verify the effect of code. A very simple, generic and non-working, example is

code.setProperty(value);
assert(code.getProperty() == value);

Thus, I suppose your common does something in doSomething. This is what you test. If your common method would not do anything - it cannot be tested.

Your question is not complete in this aspect, so it cannot be answered more precisely at this moment.

Ralf Ulrich
  • 1,575
  • 9
  • 25
  • you have to understand that this is a sample code for understanding. In practice, you would like to test that if "if" condition is true, you are doing something, if "if" condition is false, you are falling back to default implementation provided by the parent. – Bharat Mar 21 '23 at 07:58
  • As I wrote, the effect of "doSomething" must be testable. So just assert it.... – Ralf Ulrich Mar 21 '23 at 08:00
  • you are missing the point. I want to test the behaviour of A.common() when "if" condition results false. – Bharat Mar 21 '23 at 08:01
  • 1
    Then you need to find some external effect of `A.common()` and check it in your test. – tgdavies Mar 21 '23 at 10:34
  • @tgdavies some interactions may not have external effects e.g. API calls. – Bharat Mar 21 '23 at 11:35
  • 1
    Not all code is testable as originally written. You may need to refactor for testability. – tgdavies Mar 21 '23 at 12:01