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(a)redhat.com&gt; 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(a)redhat.com > > > > > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev