+1 to using AcceptanceTest category for the end-to-end JDBC connector service tests
On Wed, Apr 4, 2018 at 8:41 AM, Nick Reich <nre...@pivotal.io> wrote: > Using AcceptanceTest category seems like a good solution at the moment to > me. > > On Tue, Apr 3, 2018 at 4:29 PM, Sean Goller <sgol...@pivotal.io> wrote: > > > 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? > > > > > > > > > >
