Could you please elaborate?

 

Sorry, I don't know what is the "main test call parameter"

How should the individual test behave?

• If I mock the server (shared resource), I will not be testing concurrency.
• If I share the server, the test will probably fail: their asserts will not withstand concurrency conditions.

 

Thanks

 

Juan

--- In agile-testing@yahoogroups.com, "love" <lkafle@...> wrote:
>
> To use concurrent testing with Junit alone, please pass the test
> classes multiple times like class1,class2 in main test call
> parameter, and then use thereads to start each of these.
>
> --- In agile-testing@yahoogroups.com, "Carfield Yim" carfield@
> wrote:
> >
> > On Tue, Nov 11, 2008 at 9:23 PM, Juan Gabardini jgabardini@
> wrote:
> > > Thanks Yim and Mark!
> > >
> > > I'm searched on TDD messages and found something in line with
> Yim suggestion
> > > (by Rick Mugridge).
> > >
> > > I will do that. It is just a little annoying, because the bugs
> that I'm
> > > chasing seem to be related to concurrency. But it is common-
> sense, I must
> > > first be sure of the "sequential" behavior.
> > >
> >
> > In fact I face same situation that there is a racing condition
> among a
> > groups of legacy applications, might be we are able to create test
> > case to simulate and proof the fix is working. However due to
> various
> > constraints we actually not fix the issue but instead apply
> workaround
> > after racing condition offer. May be you can think in this area...
> Of
> > course this should not be good answer for most cases.
> >
>