[fdo-internals] FDO provider conformance test

[Haris Kurtagic]

Hi ,

For some time I am playing with idea for providers conformance tests.
Whenever I work with FDO it comes out more and more.

We have situations in which providers are not written correctly, they
doesn't follow FDO specification or FDO spec is not so clear.
Anyhow that happens, and then often major fdo clients are written in
such way that they are using around routes to get results.
I think that could be one of major issues for fdo in general and of
course very important thing to get fdo more widely adopted.

For example, I just today had two such cases.
1. King.Oracle provider has bug and is returning null pointer for
class capabilities.
    And what happened with clients, Map 2010 will allow that class to
be edited, while Map 2011 will not allow it.
    This could be prevented by having test which will say that
provider has to return non-null pointer.

2. Second example comes from sdf and sqlite providers. They use
ExtendedSelect and ordering differently.
    SQLite will use ordering option for regular select as well, while
sdf will not.
    This will end up with different behavior for fdo applications
using those two providers.

Recently we also had issues about what is computed class, what means
capability supportsordering , etc.


I know that conformance tests means, lot of resources to be invested
but very often I think that is investment which could pay itself long
term.
I would like to hear what others think about it and ways we could
achieve that providers have expected specified behavior.

First solution which comes to my mind is using modified current unit tests.
I haven't looked at provider unittest but perhaps some of those could
be modified into general fdo tests.

It is also continuous work, we don't need to do it all at once. It is
something we add as we found errors, or with new RFCs etc..

Also, some of tests could be done .net if there are more developers
willing to be included in it.

Thank you,
Haris