Opened a ticket here https://issues.apache.org/jira/browse/GEODE-5363
On Thu, Jun 28, 2018 at 10:36 AM Galen O'Sullivan
wrote:
> +1 to the new test organization.
>
> And I agree with Patrick's explanation of which is the more stable test
> category.
>
> On Thu, Jun 28, 2018 at 9:47 AM, Patrick
+1 to the new test organization.
And I agree with Patrick's explanation of which is the more stable test
category.
On Thu, Jun 28, 2018 at 9:47 AM, Patrick Rhomberg
wrote:
> @Dale
> It seems to me that the Unit / Distributed / etc would be the more stable
> purpose, and as importantly, each l
@Dale
It seems to me that the Unit / Distributed / etc would be the more stable
purpose, and as importantly, each level is mutually-exclusive with any
other.
At least under our current categorization tags, the functional area
categories don't form a partition on our test set. For instance, the
Don't forget to add "acceptanceTest/"
On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett wrote:
> I'd like to suggest that we refactor our current test source set, which
> contains both unit, integration and distributed tests, into distinct source
> sets, test, integrationTest, distributedTest. Thes
The two main ways to organize tests are hierarchies (such as packages or file
folders) and tagging (such as tagging).
Each supports different purposes for selecting tests to run.
Hierarchies are good for stable, mutually exclusive purposes. Unit,
Distributed, Integration, and Acceptance seem li
what about "testUtilities" instead of "commonTest"?
On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett wrote:
> I'd like to suggest that we refactor our current test source set, which
> contains both unit, integration and distributed tests, into distinct source
> sets, test, integrationTest, distrib
> On Jun 26, 2018, at 4:13 PM, Bruce Schuchardt wrote:
>
> This seems like a good idea to me. I've never liked having the different
> types of tests all jumbled together. OTOH I like to be able to run all
> MembershipTests using the category mechanism. I would like to keep that
> ability
> On Jun 26, 2018, at 5:34 PM, Kirk Lund wrote:
>
> +1 although I'm not sure I like "commonTest"
The choice of name or the concept of some common classes? I’m not sold on
either myself but tossed it in there to quell issues that may arise from some
shared classes between the Test types.
> On Jun 26, 2018, at 4:34 PM, Patrick Rhomberg wrote:
>
> @Anthony, I'm pretty confident we'll need a commonTest. Off the top of my
> head, it'll need to host the startup rules, GfshRule, and the
> SimpleSecurityManager.
None of these examples would make sense in unit tests so probably not
+1 although I'm not sure I like "commonTest"
On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett wrote:
> I'd like to suggest that we refactor our current test source set, which
> contains both unit, integration and distributed tests, into distinct source
> sets, test, integrationTest, distributedTes
@Patrick Those all sound like great use cases to me
+1 to new structure. So far this seems like a change with no downsides.
On Tue, Jun 26, 2018 at 4:46 PM, Anilkumar Gingade
wrote:
> +1 for restructuring.
>
> -Anil.
>
> On Tue, Jun 26, 2018 at 4:34 PM, Patrick Rhomberg
> wrote:
>
> > I like t
+1 for restructuring.
-Anil.
On Tue, Jun 26, 2018 at 4:34 PM, Patrick Rhomberg
wrote:
> I like the idea of good structure around our test-complexity @Category
> layout.
>
> @Alexander, not to speak for Bruce, but to my mind things like SecurityTest
> / WanTest / etc are orthogonal to the UnitTe
I like the idea of good structure around our test-complexity @Category
layout.
@Alexander, not to speak for Bruce, but to my mind things like SecurityTest
/ WanTest / etc are orthogonal to the UnitTest / IntegrationTest /
DistributedTest / AcceptanceTest classification. I like adding better
runti
Sounds good, though I’m not entirely sure we need ‘commonTest/‘. I guess we’ll
find out :-)
Anthony
> On Jun 26, 2018, at 4:19 PM, Dan Smith wrote:
>
> +1 for the suggested structure.
>
> -Dan
>
> On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett wrote:
>
>> I'd like to suggest that we refa
+1 for the suggested structure.
-Dan
On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett wrote:
> I'd like to suggest that we refactor our current test source set, which
> contains both unit, integration and distributed tests, into distinct source
> sets, test, integrationTest, distributedTest. Thes
Bruce, what use case do you see for the category annotation going forward?
Could we bring it back after we identified that we do in fact need it?
On Tue, Jun 26, 2018 at 4:13 PM, Bruce Schuchardt
wrote:
> This seems like a good idea to me. I've never liked having the different
> types of tests
This seems like a good idea to me. I've never liked having the
different types of tests all jumbled together. OTOH I like to be able
to run all MembershipTests using the category mechanism. I would like
to keep that ability, so I don't think we should do a wholesale removal
of @Category. Yo
17 matches
Mail list logo
