What are the valid test cases for method calls within if-else condition

Question

I have a discount service that gets called if certain conditions are met. I need to write test cases to check if the discount service is called. My doubt is checking if the discount service is NOT called for type 4 and 5 is a valid test case scenario.

public void ApplyDiscount(int typeId, double amount)
{

if(typeId == 1)
{
  //call discount service
}

else if(typeId == 2)
{
  //call discount service
}

else if(typeId == 4)
{
   //do other stuff
}
else if(typeId == 5)
{
   //do some other stuff
}

}

Answer 1

(I'm most familiar with Java, Junit, and mockito - so what I write below is based on my understanding of this applied to what I can find)

You are looking for a mocking tool such as Moq.

In this scenario what you would do is mock the object that contains the DiscountService.

At this point, you would do something like (I have no way of verifying if the following code is correct for the framework, but its in the right direction):

public void Test() {
    var mockService = new Mock<IDiscountService>();
    SomeClass.ApplyDiscount(1, 0.0);
    mockService.Verify(
       mockService = foo.ApplyDiscount(), Times.Once());
}

And this will verify that the discount service was called once (and only once) when the ApplyDiscount call was made with the given parameter.

I will caution you that the structure of this code that you have psuedocoded out seems suspect too. The int being passed in and what looks to be something that wants to be a switch statement smells like wishing to be polymorphism.

Consider that if the test is hard to write, sometimes it means that the design of the system is wrong and should be revisited. Well written code tends to be easy to test.

Still, you will want to read up on Moq and use it in the right places (like verifying that something was called the appropriate number of times without putting test code into your actual code - which smells even worse than switches).

Answer 2

At this point there are no valid test cases.

There's not a lot to test here. The method returns void, so any test would be focused on any effect to an object or state that is internal to this method, or alters state the is global in scope. If cases 1 and 2 simply call a service then there is no change in state, so there is nothing to test.

Cases 4 and 5, don't know what kind of stuff you are doing so at this point I would not write any tests for this.

Additionally, I would probably use a switch statement instead of a bunch of if/elses. Looks like case 1 and 2 are the same.

Answer 3

The most easy way to discover the test you nee its thinking in the list of features you want form the code under test, for example:

• "when type is 1,2 call discount service"
• "when type is 4 do some stuff"
• "when type is 5 do some other stuff"

Perhaps you don't need a test to explicitly check that the discount service its not called, probably you have more services in your applications and you don't want to check that there is no calls to all those services.

Answer 4

All good unit test suites do not just test the sunshine cases, but also test to see what happens if something is done that is supposed to be disallowed.

You'll have to make an exhaustive list of cases that your unit has to be able to handle. For every one of your casetypes in the snippet you posted, you'll need to think of at least one case that has to evoke the error handling code in your code for every error handled by your code. For the sunshine cases it matters how much your 'input range' is. You'll have to test for every class of input in the range you're going to handle.

After you've done that, you have to determine which ones are worth working out for complete testing.

Your not calling 4 or 5 should definitely be one of several test cases.

BTW, I agree with @MichaelT and I'd suggest using a strategy pattern [1] to get a better design going. This would also make it easier to build a proper test suite for your application, as all behaviours are in their own classes.

[1]http://en.wikipedia.org/wiki/Strategy_pattern