Using AcceptanceTest category seems like a good solution at the moment to
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
> > > 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
> > > 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
> > a
> > > new task, such as "serviceTest" (instead of IntegrationTest or
> > > distributedTest). That way, developers could run all other tests
> > > on their machines, only requiring Docker and Docker Compose if they
> > to
> > > run these specific tests. This would also allow them to be their own
> > > in Concourse, eliminating the issues that plague integrating these
> > > there.
> > >
> > > Are there other ideas on how to manage these tests or concerns with the
> > > proposed approach?
> > >