I have created a factory and a set of specifications to create and validate an aggregate root. Currently I have some tests for the factory that call the specifications on the product of the factory, but I’m wondering if that’s enough. It might be better from a design perspective to couple the factory to the specifications of it’s product, since they are closely interrelated.
If a specification for an aggregate root product is being used for validation, rather than for creation, does it make sense to call it from inside the factory?
Or is a unit test good enough?
The answer probably depends on how you are using your specifications, and whether the code is breaking a lot during the creation process.
Specifications can be used for almost anything you can think of. At a basic level specifications are merely controllable conditional statements encapsulated into objects. Wherever the code uses conditional logic one could probably refactor that logic into specifications, if the developer felt there was some justification.
There is nothing wrong with using specifications in the actual code, so long as it makes the code more usable, maintainable, or readable. There is also nothing wrong with creating specifications that are only used in tests. Specifications are simple objects, coupling code to specifications in one way or another doesn’t seem to have much of a negative impact on maintenance or reusability due to the relative simplicity of most specifications.
Yes, but probably only if you are having trouble or a lack of confidence in the product of the factory.
Yeah calling a specification from a unit test can be good enough to prove the validity of a factory’s product (at least in regard to what the specification covers). I don’t often use specifications in my unit tests however, only when I’m having a tough time with something, or it’s part of the logic that I’m testing.