[teiid-dev] Integration Testing

[Van Halbert]

A new integration testing project will be created to house the teiid  
integration tests.       I'm starting this thread to open this topic  
up for discussion so that this process can begin to move forward.

The following are some initial goals  of this new project:

-	A new test integration project is going to be created, so that we  
start fresh, create a manageable project that is organized in a manner  
that we can make some sense what coverage we have.  The goal of this  
new project is that it will be pushed to open source.
-	The new project will use the existing junit testing framework used  
on the product side.     This framework enables the developers to  
create their own complex junit test (i.e., complex transaction test),  
but at the same time, allow bulk test sets to be run.
-	The new testing process will support the create/drop of database  
schemas and data refresh.   So if a contributor can supply a database  
user with the right admin rights, the process will create a schema and  
all appropriate tables in order to run the test.    Note:  1 schema  
will be created that will hold all necessary tables (i.e., bqt,  
mmfinancials, etc) required to support the tests.
-	To facilitate data loading/refreshing before a test, an extension to  
junit, DBUnit, will be used.
-	The existing test on the product side will be brought over, but in  
an organized fashion.   This includes  bulk test sets (mainly  
validating select type statements) and existing product junit tests.


Additional Discussion points:
-	how best to organize tests so that we have some notion of what  
coverage we have
-	managing the project, ensuring additions by contributors, GSS,  
developers, etc. are done in a manner that ensures consistency
-	reducing the number of data source schemas we support (i..e, books,  
partssupplier, mmfinancials, bqt, and there are others).  There's no  
reason to have that many different schemas to manage across all our  
different database types.
-	In order for the vdb artifacts to be usable in the open, the  
connector properties need to be cleaned out.    The adminapi will be  
used to update the connector properties before the tests are run.    
This will require some manner of mapping the connector bindings to a  
specific datasource.

--------------------------------------------------

Here's the order of the tasks:

-	implement framework, have it ready for developers to start adding  
their junit tests
-	add the bulk set tests (baseline validation)
-	move over the existing junit tests, reworking those were the schema  
is no longer supported,

As for any timeline on this project, your guess is as good as mine.     
This is one of those projects that doesn't get high priority, but it's  
really needed.   And you go as fast as you can when you have the time.


Please respond with your comments or suggestions.

Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert at redhat.com