The library needs in depth testing for being relyable
and "serious" enough to be published. The following is a list of
priorities, of modules that should be covered by tests:
Static reflection API:
Function, Field, Class, Enum. Most of this classes are just
bridges to the generated code, so it's hard to add tests there. At least
Enum has some functionality (fromString()/toString()) that needs to be
tested.
At least black-box test the API for occurrencesof types, members, missing fields,
etc. Check that the API gives right data from a given source.
Dynamic reflection runtime:
Unit test Type: Registration, data, etc.
Unit test Object.
Unit test Object manipulation: Function invocation, assignment, etc.
Unit test Object pool. Consider a more relyable pool implementation (Ahem @foonathan).
Unit test automatic data registration: By default runtime dynamic reflection data should match
that collected by static reflection API.
And more, and more, and moooooooore things need testing. I should be doing like a true TDD fan, writing tests first. Meanwhile, yes, having features not covered by tests is considered a bug. One of the worst bugs.
The library needs in depth testing for being relyable and "serious" enough to be published. The following is a list of priorities, of modules that should be covered by tests:
Function
,Field
,Class
,Enum
. Most of this classes are just bridges to the generated code, so it's hard to add tests there. At leastEnum
has some functionality (fromString()/toString()
) that needs to be tested.Type
: Registration, data, etc.Object
.Object
manipulation: Function invocation, assignment, etc.Object
pool. Consider a more relyable pool implementation (Ahem @foonathan).