I'm currently writing an object dumper (allowing different dumping strategies).
Of course, I would like to write unit tests to verify that what I will develop will match all the features that I expect.
However, I cannot imagine how I will perform the testing on this solution. I have thought about creating a set of objects which save the number of times that each of their properties have been accessed. It seems almost ok. But how can I verify that their public fields have been accessed?
Why would you explicitly care how many times the properties have been accessed etc? I'd just test that the output matched expectations. If there's some reason to have one particular strategy (e.g. fields instead of properties) then there's likely to be an easy way of testing that (e.g. make the property return a capitalized version).
I would focus on validating the output rather than verifying properties were accessed. I might read a property but not dump it correctly, right?
This is an example of testing the outcome rather than testing the implementation.
You just have to test the value dumped is the value that was assigned to the properties/public field. Just ensure to assign a different value to each property/field.