5

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;
}
|improve this question|||||
  • Possible duplicate of How should I test the functionality of a function that uses other functions in it? – gnat Apr 19 '16 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 Apr 19 '16 at 16:19
  • 2
    +1 for "a unit is not necessarily a single class". That's also worth considering. – Fabian Schmengler Apr 19 '16 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"? – candied_orange Apr 20 '16 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 Apr 20 '16 at 2:03
5

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.

|improve this answer|||||
  • 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 Apr 19 '16 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? – candied_orange Apr 19 '16 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. – candied_orange Apr 20 '16 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 Apr 20 '16 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. – candied_orange Apr 20 '16 at 10:39
3

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.

|improve this answer|||||
  • 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 Apr 19 '16 at 15:01
  • Then only pay attention to the first paragraph of my answer. Are you familiar with the concept of mock objects? – Fabian Schmengler Apr 19 '16 at 15:05
  • You can validate calls to the faked object using fakeiteasy. A.CallTo(() => fakedObject.SomeMethod()).MustHaveHappened(Repeated.Exactly.Once); – Fran Apr 19 '16 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 Apr 20 '16 at 7:09
  • No, mock objects should be able to verify exactly which methods are called with which parameters. – Fabian Schmengler Apr 20 '16 at 7:15
0

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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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