Testing Aggregates with PHPUnit and Laravel

Question

I am looking for some advice on testing aggregate objects with PHPUnit and Laravel.

In my app, I have three classes which form a whole:

Condition "belongsTo" ConditionGroup
ConditionGroup "belongsTo" ConditionResult

These classes are used together to determine whether a set of conditions evaluate to true or not. Conditions in a Conditiongroup represent an "AND" test (ie all Conditons must evalute to true for the ConditionGroup to return true) and ConditionGroups in a ConditionResult represent an "OR" test (ie any of the ConditionGroups can return true for the ConditionResult to return true)

It makes no sense for a Condition or ConditionGroup to exist on their own without being part of a ConditionResult and so I have a ConditionManager class with a static 'create' method to instantiate all three classes and ensure they become related. I also throw custom exceptions when attempts to instantiate instances of Condition or ConditionGroup are made. (These are ultimately PDOExceptions as I have ensured that in the migrations, these fields must have a value - ie they are not "nullable")

My problem is that when I want to test the functionality of Condition, I need to use the ConditionManager to create all three classes and then get an instance of Condition through relationships and the test the function on it's own.

$conditionresult = ConditionManager::create($params);
$condition = $conditionresult->conditiongroups->first()->conditions->first();
//can now test Condition

It seems that when I create tests for Condition, I am indavertantly, testing ConditionGroup and ConditionResult and so repeating tests.

What would be the best approach? Is what I am doing "okay" in the testing world? Some other things I have considered:

1. Forget enforcing that Condition and ConditionGroup should not be created on their own. Not keen on this as I would like to enforce the nature of these classes but it seems the most logical for testing purposes. As a side note, this app is being created as a package to be reused in other projects so I believe it is the responsibility of the package to not allow this to happen.

2. Forget testing Condition and ConditionGroup and use the tests for ConditionManager ensuring I test each aspect. Not sure I like this either as it goes against "unit testing".

Any help appreciated!

Answer 1

First of a unit test should test a unit of behavior, which does not automatically mean a class.

If it does not make sense for class A or B to exist without C, then A, B and C form a single unit of behavior together. Meaning you should only test class A, B and C together.

If testing those three classes together leads to a lot of testcases or a lot of mocking, it probably means that they do not describe a single unit of behavior. In that case I'd say you'll have to reconsider you class design.

That's as much as I can say about your issue without seeing the actual implementations of the classes in question.