This is a test design question. I have a class 'handler' that accepts a 'validator' that checks some business logic on what's passed to the handler.

I made the unit tests for the validator and now I'm writing the test for the handler. Obviously I want to make sure that the validator is called when the handler does its thing.

Should I test the cases of the validator once more or is this pointless?


I'll provide a little more insight about what I'm trying to do here, as it seems that questions has more to it than I expected.

What I'm doing is a service to register users for a website and I need to check that the user provided exactly one contact method out of three possible options (email, telephone and postal address). This validation needs to be run both when the user registers in the website and when the user needs to reset his password in case he forgot it.

The method that handles the register users goes like this.

public Headers HandlePetition(Petition petition)
     if (petition == null)
     { throw new ArgumentNullException(); }

     contactPointValidator.ValidateContactPoint(new ContactData
          Email = petition.email,
          PostalAddress = petition.postaladdress,
          Telephone = petition.telephone,

     var response;

     // Do stuff

     return response;
  • Possible duplicate of How should I test the functionality of a function that uses other functions in it?
    – gnat
    Commented Apr 19, 2016 at 14:56
  • 5
    Contrary to other answers here, I don't think you should be Verify()ing calls to internal implementation details. You've tested in the wrong order. A "unit" is not necessarily a single class, although it can be. Write the tests that are most valuable first. If you test your code through its public API, then you will get coverage of those internal POCO (or POJO) classes for free, while keeping your tests and code flexible.
    – RubberDuck
    Commented Apr 19, 2016 at 16:19
  • 2
    +1 for "a unit is not necessarily a single class". That's also worth considering. Commented Apr 19, 2016 at 16:46
  • 2
    @RubberDuck Imagine a class that returns nothing. You can pass it objects that it uses. You can call it's methods. It does stuff. But it never returns anything. It never outputs anything. It never even throws an exception. Infact, it never tells you a damn thing. Yet it does useful work. It calls other objects. Is testing that those calls are made really pointless testing of "internal implementation details"? Commented Apr 20, 2016 at 1:52
  • 1
    @CandiedOrange I'm not saying "never Verify()". I'm saying that it should only be necessary on the very edges of the system. There are lots of ways to skin a cat. I shy away from testing methodologies that cause me to update my tests when internal implementations change. That doesn't mean that I never mock, it just means that I prefer not to under "normal" circumstances.
    – RubberDuck
    Commented Apr 20, 2016 at 2:03

3 Answers 3


It should be pointless. But you should be making sure handler calls what validator needs called.

For unit testing you should be testing in isolation. That means you'll need a stub (or mock) validator to hand to handler when you test handler. You don't check validator business logic when testing handler. You test that handler calls validator (in this case ValidatorStub) when, and with what, it should.

  • Maybe I should create a mock that always raises an exception or make sure that something it passed to it so I can make sure that a validator is properly called?
    – Zalomon
    Commented Apr 19, 2016 at 15:02
  • 1
    That's an idea, but suppose one call to handler is meant to cause two calls to validator. How do you plan to check that both calls happened? Commented Apr 19, 2016 at 15:09
  • Rather than expect exceptions a possibility is to just pass a data structure into the mock and let the mock write to it when called. Your test constructs a Handler(MockValidator(datastructure)). Then make your calls to handler and verify that datastructure has set what should be set. Commented Apr 20, 2016 at 10:19
  • In fact I cannot do that since Validator makes no changes in the structure, just raises an exception if data is not valid.
    – Zalomon
    Commented Apr 20, 2016 at 10:37
  • 1
    Huh? No MockValidator. MockValidator can do whatever it wants once called. It's a mock. The datastructure exists only for testing. It's a moot point if you reactor handler so it has no dependency on validator though. Commented Apr 20, 2016 at 10:39

Obviously I want to make sure that the validator is called when the handler does its thing

Then mock the validator and test that it is called with the right parameters. No need to test the validator itself twice.

On a related note, unit tests have their true value in test driven development. It sounds like you are writing the tests after the code instead. Maybe integration tests are more suitable for you here. Then you would test the handler together with validators, or even a bigger unit in one test that checks if everything works together as expected.

Integration tests are more valuable for regression testing than unit tests as they are more likely to find bugs from unexpected side effects.

  • 1
    In fact I'm writing the tests prior to the code but I just stumbled into this question while doing so. My issue of how to check if the validator is called with the right parameters since this is happening inside the method that I'm testing.
    – Zalomon
    Commented Apr 19, 2016 at 15:01
  • Then only pay attention to the first paragraph of my answer. Are you familiar with the concept of mock objects? Commented Apr 19, 2016 at 15:05
  • You can validate calls to the faked object using fakeiteasy. A.CallTo(() => fakedObject.SomeMethod()).MustHaveHappened(Repeated.Exactly.Once);
    – Fran
    Commented Apr 19, 2016 at 15:13
  • @fschmengler as far as I know using a mock will only validate that the class is referenced somehow, am I correct?
    – Zalomon
    Commented Apr 20, 2016 at 7:09
  • No, mock objects should be able to verify exactly which methods are called with which parameters. Commented Apr 20, 2016 at 7:15

I'll post my last comment to fschmengler's answer as an answer since I think that it is the most fitting way to solve my question.

I think that my problem was that I was facing the problem the wrong way: the handler shouldn't be validating any of that since it's bussiness logic; not even indirectly as it is doing it now. Both the handler and the validator should be encapsulated by an upper class that uses both. I think that this is making more sense to me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.