[teiid-dev] Integration Testing

Van Halbert vhalbert at redhat.com
Mon Jul 13 17:11:46 EDT 2009


You are correct, no data source connection information will be in the  
open.    The product side will maintain its own data source  
information.   Part of the challenge to this new framework will be to  
enable a contributor to run their tests against only the data  
source(s) they have.    The contributor most likely will not have all  
the flavors.

Van

On Jul 13, 2009, at 2:57 PM, John Doyle wrote:

> 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

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







More information about the teiid-dev mailing list