[teiid-dev] Integration Testing

[John Doyle]

Just to make sure I understand this proposal, are we creating and opening a test framework, or a framework + tests?

I ask because I am thinking of how we can test some of the SAS services that I have been working with, SalesForce for now, but Google, Amazon, and Yahoo as well.  All of these present similar concerns:  we can't mock up the source, we don't want to share the credentials, they can be very slow (due to latency, API limitations, etc).


~jd

----- "Van Halbert" <vhalbert at redhat.com> wrote:

> 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
> 
> 
> 
> 
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev