0

In an app I'm working in there's a service class(among others) which is used just to call methods on other classes. Recently I've had to work in that area and add another method that does what all the other methods do, call other methods from other classes. Arguably, this whole class shouldn't exist, but that's another topic.

The unit tests that exist for other methods in that class seem to be doing a lot busy work. Going as far as checking the values returned from a mock.

In my eyes this isn't worth writing a unit test for other than confirming that X method is called from Y class. Also known as verify in Java/C#, spy in PHP , called in Python etc.

Here's some pseudo code to get an idea of what I mean

public class SomeClass{
 public void methodA() { ... }
}

public class SomeOtherClass {
 public String methodB() { ... }
}

public class Service {
 public Service(SomeClass someClass, SomeOtherClass someOtherClass) {
 ... 
 }

 public void doWork() {
  this.someClass.methodA()
  this.someOtherClass.methodB()
 }
}

A unit test would look like this

public class UnitTest {
 public void testStuff() {
    SomeClass someClass= mock(SomeClass.class);
    Service service = ...;
        
    verify(someClass).methodA();
 } 
}
10
  • 1
    I suppose it does. Reading the top answer seems to agree with what I was thinking: for specific cases such as mine it's fine to check that whatever methods you expect to be called are called.
    – Andrei
    Commented Sep 7, 2023 at 18:47
  • 1
    I just want to point out that there's nuance here, there's more than one possible correct answer. For example, if the submethod is one for auditing purposes where failing to do so would land the company in legal trouble, that would be a really strong argument for writing the test to confirm that the auditing methods are being called.
    – Flater
    Commented Sep 7, 2023 at 22:48
  • You don't write tests to confirm a method is called. You write tests to confirm that a result happened. If you're architecture sends results out with a method call then you mock that method call to see what the result was. Not every result comes back in a return. Commented Sep 7, 2023 at 22:55
  • @candied_orange i'm a bit confused "you mock that method call to see what the result was", mocking the method call would make it so that you know before hand what the result is. I'm not sure what you mean here.
    – Andrei
    Commented Sep 8, 2023 at 9:30
  • @Andrei tests of functional code that returns a result are nice and simple. Just check what was returned. However, some code isn’t functional. Some is object oriented. Some code sends messages. And does so by calling a method that lies outside the unit under test. In those cases it makes sense to mock that method to see what the message was. Commented Sep 8, 2023 at 10:07

0

Browse other questions tagged or ask your own question.