Testing

[Manu343726]

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:

1. 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.
2. 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.

[Manu343726]

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.