I'm actually fine with putting it in AcceptanceTest for now. Ideally I'd like to see something like JDBC connection strings that could be passed in as properties via the command-line, and if they're not present the relevant tests don't get run. That way the entity running the tests can decide the best way to enable those tests.
On Tue, Apr 3, 2018 at 4:11 PM, Jens Deppe <jde...@pivotal.io> wrote: > I'm in favor of using docker for test isolation. We already have an > 'AcceptanceTest' category which you might consider using instead of > creating yet another category. > > --Jens > > On Tue, Apr 3, 2018 at 2:02 PM, Nick Reich <nre...@pivotal.io> wrote: > > > Team, > > > > As part of validating the new JDBC connector for Geode, we have a need > for > > tests that involving connecting to specific databases (like MySQL and > > Postgres) to validate proper function with those databases. Since these > > tests require connecting to outside services, unlike existing Geode > tests, > > we are seeking suggestions on how to best incorporate such tests into > > Geode. The approach we have taken so far is to utilize Docker (and Docker > > Compose) to take care of spinning up our external services for the > duration > > of the tests. This, however requires that Docker and Docker Compose be > > installed on any machine that the tests are run on. Additionally, the > > Concourse pipeline for validating develop is incompatible with use of > > Docker for distributed tests, due to the way they are already being run > > within Docker containers of their own (it seems possible to make it work, > > but would add overhead to all tests and would be a challenge to > implement). > > > > To address these issues, we are considering having these tests run under > a > > new task, such as "serviceTest" (instead of IntegrationTest or > > distributedTest). That way, developers could run all other tests normally > > on their machines, only requiring Docker and Docker Compose if they wish > to > > run these specific tests. This would also allow them to be their own task > > in Concourse, eliminating the issues that plague integrating these tests > > there. > > > > Are there other ideas on how to manage these tests or concerns with the > > proposed approach? > > >
