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