I would be hesitant to start categorizing tests by name (again) as we'd be
introducing a different (non consistent) qualifier which is only relevant
to one class of tests.
All AcceptanceTests should already be grouped in the geode-assembly module
so running them with geode-assembly:acceptanceTest
How about a sub module that only contains acceptance tests?
> On Apr 4, 2018, at 4:42 PM, Kirk Lund wrote:
>
> Nick made the changes necessary to open up AcceptanceTest to other Geode
> submodules and it takes too long. The cause is what Jared mentioned.
> Basically, Gradle forks a new JVM for e
Nick made the changes necessary to open up AcceptanceTest to other Geode
submodules and it takes too long. The cause is what Jared mentioned.
Basically, Gradle forks a new JVM for every *Test in our code base and then
executes JUnit which queries the test class for Category and either runs or
doesn
Just FYI, the reason that :acceptanceTest is currently only a target of
precheckin is https://issues.apache.org/jira/browse/GEODE-3296
For the full details, see this thread on the Gradle Forums:
https://discuss.gradle.org/t/test-task-with-forkevery-1-and-includecategories-performs-poorly/23401
O
+1. AcceptanceTest seems fittings, although...
That test category was created with the focus on tests that run gfsh
scripts via the GfshRule. Because the GfshRule uses the built jar and
actually launches gfsh to run its tests, all current AcceptanceTests exist
in geode-assembly. Perhaps as an o
+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 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 wrote:
>
> > I'm actually fine
Using AcceptanceTest category seems like a good solution at the moment to
me.
On Tue, Apr 3, 2018 at 4:29 PM, Sean Goller 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 properti
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
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 wrote:
> Team,
>
> As part of validating the new JDBC connector for Geode, we
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,
10 matches
Mail list logo
