How about ConcurrencyRule or ConcurrencyTestRule?
On Mon, Jul 30, 2018 at 2:56 PM, Galen O'Sullivan
wrote:
> I like this API. I think it saves a lot of boilerplate, and a lot of subtle
> possible mistakes. I think the new API would be a bit cleaner than the
> RegionVersionVectorTest.doesNotHangI
ExecutorServiceRule is much more useful in an integration test or
distributed test. RegionVersionVectorTest (unit test) is a terrible example.
The following are much better examples...
PartitionedRegionCreationDUnitTest which uses a CompletableFuture with it:
CompletableFuture createdAccesso
I like this API. I think it saves a lot of boilerplate, and a lot of subtle
possible mistakes. I think the new API would be a bit cleaner than the
RegionVersionVectorTest.doesNotHangIfOtherThreadChangedVersion that Kirk
mentions.
I would like to see generics, especially for `public void
runAndExp
I'd love to collaborate on improving ExecutorServiceRule. Let me know if
you or anyone else is interested.
Honestly, I can't remember why I had it default to one thread unless I was
favoring very explicit and tight control over what resources the tests use.
Unlimited sounds reasonable for this.
G
> See our ExecutorServiceRule which is in geode-junit. Is that similar to
> what you're trying to create? Maybe we need just to
> modify ExecutorServiceRule instead of introduce yet another Helper class. I
> don't see why we need to add another class that is so similar to both
> ExecutorServiceRule
I've actually been trying to remove most of the Util and Helper classes
used by tests. My reasons are two-fold: 1) these classes tend to be very
non-OOP, 2) they tend to introduce a new API to the test which then
obscures what it's actually doing. When I look at a test, I don't want
anything hidden
+1
Echo Dales suggestion for Duration over int for time.
-Jake
On Wed, Jul 18, 2018 at 12:58 PM Dan Smith wrote:
> Hi Helena,
>
> Looks great! I think this will make writing multithreaded tests a lot less
> error prone. A couple of minor comments below:
>
> I'm not sure we need runInSeries, s
Hi Helena,
Looks great! I think this will make writing multithreaded tests a lot less
error prone. A couple of minor comments below:
I'm not sure we need runInSeries, someone could do that without using this
test helper.
Could we make the default timeout something more like 5 minutes? See this
t
Hi Helena,
I like it!
A few suggestions:
- For the durations (repeatForDuration() and setTimeout()), consider using a
java.time.Duration rather than an int to express the duration. The Duration
class lets most of the code not have to keep track of the time units. The
caller creates the Durati
Hello All,
Below I have included a proposed API for a concurrency test helper. The
goal of this test helper is to make it easier for tests to use multiple
threads. I believe providing a helper for this will reduce the number of
tests that incorrectly use threads, and help make our DUnit tests more
10 matches
Mail list logo
