CODEWITHSUNDEEP
c#unit-testingnunitmoq
ImmortalStrawberry
ImmortalStrawberry

Reputation: 6101

Should I unit test code with no obvious returns from methods?

I have a class thats sole purpose is to run a method on other classes from an Interface.

Testing the interface of the classes is no problem, but the runner doesn't actually DO anything and (as it stands) the only parameter passed into the constructor is kept private.

In my case, the classes are importing text files into a database.

internal DataImporter
{
  private List<IFileImporter> _importers;

  public DataImporter(List<IFileImporter> importers){
    _importers = importers;

  public bool RunImporters()
  {
    //foreach importer, call its "Run" method - each one then does whatever it needs to do
    //however, this need not call a specific "Run" method on IFileImporter
    //I have another app that uses IFileImporter to check for presence of a file first
    //then allow user to choose to import or not.
  }

It seems to me there is nothing to test here? I can't test the value of _importers, and I don't want to make it public JUST for the sake of testing. DataImporter is specific to this instance, so creating an interface seems to add no benefit.

I've re-used IFileImporters elsewhere, but this is the only "bulk" importer, others are called manually from a winforms app, still others are not in this project at all.

So, do I need to test this...what CAN I test about this?

Upvotes: 3

Views: 152

Answers (3)

k.m
k.m

Reputation: 31464

Your method returns bool and that's where you start, for example:

  • What happens when there is no importers? Example: Run_ReturnsFalse_WhenThereIsNoImporters
  • What happens when one of them breaks (or throws)? Example: Run_ReturnsFalse_WhenAtLeastOneImporterFails
  • What is indicating success (returning true, I suppose)? Example: Run_ReturnsTrue_WhenAllImportersSucceed

You setup your mocks to simulate each of those scenarios and test agains that. When there's trully no observable effects (like returned value), you'll do it by verifying that calls were made on mocked objects.

Upvotes: 1

Jon Limjap
Jon Limjap

Reputation: 95452

You can assert that the methods have been called. You can refer to these questions to see how that's done:

You can also assert that no exception was encountered within the DataImporterclass.

If you have absolute control over the interface used it might be helpful to have each one of them return a boolean indicating whether the specific operation was successful or not.

Upvotes: 2

Steve Py
Steve Py

Reputation: 34908

In a nutshell, yes. I can think of a number of tests right off the top of my head.

Your test ensures that all importers are called by mocking out IFileImporters you pass in the constructor. At a minimum it asserts that what you pass in the constructor are actually used by the method.

A test to ensure that if any importer that raises an exception, your class behaves as you expect.

A test should assert the behaviour if the list is empty. (default to True return?)

A test should also assert the behaviour you expect if one or more importers fail. (Are you and-ing or or-ing your importer results for your RunImporters result?)

Does the method run every importer regardless of if a previous fails, or returns false on the first failure?

There should also be a test on your constructor or Assertion for if its provided a null list.

Upvotes: 2

Related Questions