Question

I have a class called FooJob() which runs on a WCF windows service. This class has only 2 public methods, the constructor, and a Run() method.

When clients call my service, a Dim a new instance of the Job class, pass in some parameters to the ctor, then call Run()…

Run() will take the parameters, do some logic, send a (real time) request to an outside data vendor, take the response, do some business logic, then put it in the database…

Is it wise to only write a single unit test then (if even possible) on the Run() function? Or will I wind up killing myself here? In this case then should I drill into the private functions and unit test those of the FooJob() class? But then won’t this ‘break’ the ‘only test behavior’ / public interface paradigm that some argue for in TDD?

I realize this might be a vague question, but any advice / guidance or points in the right direction would be much appreciated.

Drew

Answer 1

do some logic, send a (real time) request to an outside data vendor, take the response, do some business logic, then put it in the database

The problem here is that you’ve listed your class as having multiple responsibilities… to be truly unit testable you need to follow the single responsibility principle. You need to pull those responsibilities out into separate interfaces. Then, you can test your implementations of these interfaces individually (as units). If you find that you can’t easily test something your class is doing, another class should probably be doing that.

It seems like you’d need at least the following:

1. An interface for your business logic.
2. An interface defining the request to the outside vendor.
3. An interface for your data repository.

Then you can test that business logic, the process of communicating with the outside vendor, and the process of saving to your database separately. You can then mock out those interfaces for testing your Run() method, simply ensuring that the methods are called as you expect.

To do this properly, the class’s dependencies (the interfaces defined above) should ideally be passed in to its constructor (i.e. dependency injection), but that’s another story.