# How to unit test a top level method

I'm trying to unit test a small program I wrote.
My problem is that I can't see an easy way to unit test my top level class (Matcher) that exposes a single public method (MatchAll).
I do have tests for my inner classes, but they are largely trivial.

Let me present a problem and a sketch of my solution:

Problem: Given list of people, list of their preferred teams and rankings for each team, find a match that both maximizes team rank and takes candidate preferences into consideration.

My solution:

• Candidate - Holds a list of preferred teams and a rank score for each respective team
• Team - Holds list of accepted candidates. As long as the team has room, it accepts any candidate. Once it fills up, it only accepts candidates that improve its score. It also purges the candidate with lowest score.

Team exposes the following methods:

1. IsBetterMatch
3. PurgeWeakest

Matcher - Contains the list of candidates and list of teams and implements the core logic of assigning candidates to a team.

My matching logic is as follows (Pseudocode):

``````function Matchall()
while candidates != empty
c <- candidates.getFirst()
for each t in c.teams
betterMatch = t.IsBetterMatch(c)
if betterMatch
weakest = t.purgeWeakest()
``````

Assuming team methods are thoroughly tested, how would you suggest to test this function?

The tests that I can think of for this function are very complex both to formulate and to setup.

For example:

When two candidates have same rank and want the same team and the team has room for only one, the first one should be assigned to the team. Second one should be assigned to another team down his preference list.

It seems to me that they fall more under the integration tests category, which is why I'm confused. It's my understanding that the unit tests should be short and simple to write

• Delete the function, write a failing test, then write the function again following strict TDD. Even if it's just an exercise, it will force you to write testable code.
– Tim
Commented Apr 16, 2015 at 13:10
• Although Tim's answer probably isn't sufficient, it is a nice exercise suggestion. Commented Apr 16, 2015 at 13:19
• It's unclear to me what's unclear to you. You inject a couple of teams and rankings, determine beforehand what result should be returned and verify that it is in fact returned. Then you write another test for two teams that result in an equal match and verify equality returns the correct result. Do this for each distinct scenario. Can you specify what you're having trouble with? Commented Apr 16, 2015 at 13:26
• Jeroen's comment is what I would say, with this addition. It seems like an integration test because you are doing an integration test by the strictest definition. You are integrating with the Team and Candidate classes. However, that's the route most people would probably take. The other route would be to mock your Team and Candidate classes in order to give yourself very explicit control of the results, but I don't know how that might help you because Team and Candidate seem so trivial.
– Dunk
Commented Apr 17, 2015 at 16:41
• To add to Jeroen's good point: You could create some helper functions for your test to simplify creation of teams and rankings for your tests. Then the seemingly huge effort for setting up the fixture of each test may turn out quite manageable. Commented Feb 5, 2018 at 22:38

• I disagree with: `You cannot test a method which accepts no arguments and returns no results.` If function `void foo()` changes the state of the object/program, and you can measure that change, then you can check for an expected state after running `foo`.