How to test the function behavior in unit test?

Question

Hi Everyone,

If a function just calls another function or performs actions. How do I test it? Currently, I enforce all the functions should return a value so that I could assert the function return values. However, I think this approach mass up the API because in the production code. I don't need those functions to return value. Any good solutions?

I think mock object might be a possible solution. I want to know when should I use assert and when should I use mock objects? Is there any general guide line?

Thank you

Answer 1

Yes, mock is generally the way to go, if you want to test that a certain function is called and that certain parameters are passed in.

Here's how to do it in Typemock (C#):

Isolate.Verify.WasCalledWithAnyArguments(()=> myInstance.WeatherService("","", null,0));
Isolate.Verify.WasCalledWithExactArguments(()=> myInstance. StockQuote("","", null,0));

In general, you should use Assert as much as possible, until when you can't have it ( For example, when you have to test whether you call an external Web service API properly, in this case you can't/ don't want to communicate with the web service directly). In this case you use mock to verify that a certain web service method is correctly called with correct parameters.

Answer 2

Sorry for not answering straight but ... are you sure you have the exact balance in your testing?

I wonder if you are not testing too much ? Do you really need to test a function that merely delegates to another?

Returns only for the tests

I agree with you when you write you don't want to add return values that are useful only for the tests, not for production. This clutters your API, making it less clear, which is a huge cost in the end.

Also, your return value could seem correct to the test, but nothing says that the implementation is returning the return value that corresponds to the implementation, so the test is probably not proving anything anyway...

Costs

Note that testing has an initial cost, the cost of writing the test. If the implementation is very easy, the risk of failure is ridiculously low, but the time spend testing still accumulates (over hundred or thousands cases, it ends up being pretty serious).

But more than that, each time you refactor your production code, you will probably have to refactor your tests also. So the maintenance cost of your tests will be high.

Testing the implementation

Testing what a method does (what other methods it calls, etc) is critized, just like testing a private method... There are several points made:

1. this is fragile and costly : any code refactoring will break the tests, so this increases the maintenance cost
2. Testing a private method does not bring much safety to your production code, because your production code is not making that call. It's like verifying something you won't actually need.
3. When a code delegates effectively to another, the implementation is so simple that the risk of mistakes is very low, and the code almost never changes, so what works once (when you write it) will never break...

Answer 3

"I want to know when should I use assert and when should I use mock objects? Is there any general guide line?"

There's an absolute, fixed and important rule.

Your tests must contain assert. The presence of assert is what you use to see if the test passed or failed. A test is a method that calls the "component under test" (a function, an object, whatever) in a specific fixture, and makes specific assertions about the component's behavior.

A test asserts something about the component being tested. Every test must have an assert, or it isn't a test. If it doesn't have assert, it's not clear what you're doing.

A mock is a replacement for a component to simplify the test configuration. It is a "mock" or "imitation" or "false" component that replaces a real component. You use mocks to replace something and simplify your testing.

Let's say you're going to test function a. And function a calls function b.

The tests for function a must have an assert (or it's not a test).

The tests for a may need a mock for function b. To isolate the two functions, you test a with a mock for function b.

The tests for function b must have an assert (or it's not a test).

The tests for b may not need anything mocked. Or, perhaps b makes an OS API call. This may need to be mocked. Or perhaps b writes to a file. This may need to be mocked.

Answer 4

Let's use BufferedStream.Flush() as an example method that doesn't return anything; how would we test this method if we had written it ourselves?

There is always some observable effect, otherwise the method would not exist. So the answer can be to test for the effect:

[Test]
public void FlushWritesToUnderlyingStream()
{
   var memory = new byte[10];
   var memoryStream = new MemoryStream(memory);
   var buffered = new BufferedStream(memoryStream);

   buffered.Write(0xFF);
   Assert.AreEqual(0x00, memory[0]); // not yet flushed, memory unchanged
   buffered.Flush();
   Assert.AreEqual(0xFF, memory[0]); // now it has changed
}

The trick is to structure your code so that these effects aren't too hard to observe in a test:

• explicitly pass collaborator objects, just like how the memoryStream is passed to the BufferedStream in the constructor. This is called dependency injection.
• program against an interface, just like how BufferedStream is programmed against the Stream interface. This enables you to pass simpler, test-friendly implementations (like MemoryStream in this case) or use a mocking framework (like MoQ or RhinoMocks), which is all great for unit testing.