Should unit tests always overlap

Question

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?

EDIT 1:

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;
}

Answer 1

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.

Answer 2

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.

Answer 3

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.