[teiid-dev] Integration Testing

[Larry O'Leary]

On Tue, 2009-07-14 at 14:34 -0400, John Doyle wrote:
> ----- "Larry O'Leary" <loleary at redhat.com> wrote:
> 
> > On Mon, 2009-07-13 at 16:11 -0500, Van Halbert wrote:
> > > 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.
> > 
> > Which is why it is important for us to figure out the best way to
> > organize the tests within the test framework.  The idea would be that
> > I
> > can specify that I want the Salesforcce connector tests to be
> > executed
> > and by doing so, I must provide Salesforce credentials that can be
> > used
> > with the connector.  Furthermore, it would be very nice if the
> > schemas
> > used with the Salesforce connector could be the same as the ones used
> > with the other connectors so that a basic/common test case suite
> > would
> > apply.  For example, creating a script that could be responsible for
> > populating Salesforce with equivalent schema and data such as BQT so
> > that type testing can be executed in the same manner that it is
> > against
> > PostgreSQL.  This of course shouldn't be a requirement but a goal so
> > that new schemas don't have to be created and maintained across each
> > connector.
> > 
> 
> I agree with this as a goal, but I don't think it's going to be possible in this particular case.  To the best of my knowledge there is no way to programmatically modify the metadata of a Salesforce app.  Views built on top of the physical model of the default free developer Salesforce app are one possible way to to the common schema you're describing.  Then the contributor would be able to specify his credentials and that should be enough. 

It has been a few years since I have developed for Salesforce but back
in the day, I was able to perform a data export from a production
account and import it into a dev account.  This allowed me to replicate
a customer's Salesforce data and objects (schema) so that I could use it
in a dev environment.  However, I do recall an e-mail a couple ofyears
ago that may have mentioned that this option was being removed from Dev
accounts.  In any case, this may still be possible with an actual
Salesforce license that would at least allow user's that actually have
SF licenses to run the test suite.  

> Another limitation of this particular case that probably won't inform the larger framework, but I mention it anyway, is that modifications of the default Salesforce app were made to expose some of their non-standard types for testing that are not used in the default app.  So no community user would be able to run all of the Salesforce tests unless they made manual modifications to their default app. This limitation could be clearly specified in the failure messages of the tests depending upon the modification, and it's not a wrinkle that I think we should be spending time on.
> 
If such a limitation is there, these tests should be organized as such.
A group of test cases for all Salesforce default users and then a set of
tests to the "modified" version.  That way, one or both tests could be
executed depending on the developers environment.

> But like I said at the top, I agree with the goal you propose.



-- 
Larry O'Leary <loleary at redhat.com>
Red Hat, Inc.