I’m developing custom serializer as hobby project and I would like learn the TDD on it.
I have a tests for serialization & deserialization simple object graphs.
Now I want test some complex graphs with non-trivial deserialization (i.e. classes with no parameterless constructor, cyclic references, large amount of objects, etc …).
I need test the “building” and “extracting” graph of serialization and I need test the serialization & deserialization of created graph. I would like test all four actions with several graph (from simple over complex to super-complex graphs).
Should I create some non-Test class providing the predefined graphs for all tests or every test should have own source of graphs?
I’m asking this question because I see possible problem with dependecny several tests on one clas (the provider of graphs).
Thanks.
There’s not necessarily a “right” answer here; it depends on your project and your tests. It seems to be a good idea to have a common source of graphs – not necessarily a single class but maybe a set of classes (i.e. a graph factory/repository) that could generate graphs representing different concepts (the class lacking parameterless constructor, cyclic references etc).
This doesn’t avoid the risk of having multiple tests relying on a common source but you need to weigh that against the cost of defining the construction of each graph. You could end up with a lot of duplicated code across tests. If there is benefit to re-using a given graph definition; the graph factory may be the way forward.
One idea may be to have a meta-test/set of meta-tests against each graph so that you can confirm the graph validity. The point being that if a set of actual tests that all consume the same graph are suddenly failing you look to the meta-tests first and ensure that they are passing. The tests that you are planning should each be focussing on a single aspect (build/extract etc) and those tests can then rely on the graph validity.
The key thing is to keep each test as simple as possible so that if/when it fails its obvious why its failing – by having graph construction elsewhere (and separately validating it) you can have your serialization tests focussing on that and that alone.