A few feature requests/documentation issues

Jan 21, 2011 at 9:12 AM
Edited Jan 21, 2011 at 9:17 AM

Hi all, neat project!

I've been playing with the thought of making something similar, and am very happy someone's already done so :-).  However, there are a few features that would be nice to see, and hopefully at least some of them sound interesting and doable to you too.

I'd like to test types without much regard for their structure.  There's two possible approaches here: AssemblyTester, and PropertyTester+ConstructorTester.  Using the former is a little too wide-scale for me, so I'm using the latter.  However, this makes some type-testing a hassle since PropertyTester requires an object, not a type:  that means you can't test types without manually constructing them - implying manually picking constructor values.  It'd be nice to be able to specify just a type, and have PropertyTester essentially work as ConstructorTester with the additional factor that it further tests properties on the constructed objects - not just "mapped" properties, but all of them.  This would enable testing on a per-type fashion without knowledge of the type internals.

Secondly, it's not documented what kind of properties are tested: in particular, are private properties or public properties with a private accessor tested?

Thirdly, as I understand it, the constructor-tester checks that parameters are correctly stored "in" the appropriate properties.  However, it doesn't check that all parameters actually correspond to properties; in particular, this means that a misspelled constructor parameter (or a refactored property that no longer corresponds to the constructor's parameter) isn't tested.  That's unfortunate; it'd be nice if either by default or optionally one could require that all constructor parameters must be matched to exactly one property - so that slightly mangled names don't silently cause incorrect initialization to be unnoticed.

Finally, I use simple immutable types frequently - and here it makes sense to have public readonly fields rather than properties (to communicate the fact that the field won't be changing).  In practice, even a mutable type - as long as it's not part of a stable binary API - can use public fields equivalently to public automatic properties, but with less code and faster execution.  For such types of course the property tester is unnecessary (fields "work" by definition) but the protection the ConstructorTester provides would still be useful.  So, it'd be nice if ConstructorTester verified that all parameters correspond to either a property or a public field and that that field is appropriately set.

I realize you're just maintaining this as a matter of fun, professional pride, or altriusm and probably don't have time to fullfil every feature request - thanks for the library as-is in any case!


Eamon Nerbonne