[Rails-devel] 1835 automated game testing (was: Release Rails 1.6.3 available)

[Stefan F. <ste...@we...>]

Erik:
the issue for the automated game testing is easy to find.

You define the two (state) variables turn and startRoundNumber as static 
variables in StartRound_1835.

Keep in mind that all Junit tests run in sequence in the same JVM: So 
static variables carry over between games and the never get 
re-intialized between test games. In consequence for variants that 
adjust StartRound behavior will behave weird during testruns.

So question is what was your reason to use static (class) variables 
instead of standard (object) variables? I could only guess that the 
StartRound object is not undo-safe, thus you used the static variables 
as a workaround. I do not want submit this a fix, as long as I do not 
know your motivation there.

If I remove the static qualifier the games seem to run correctly, 
however some 1835 tests will be reported as failed, however this is most 
likely to the fact that the stored report is wrong and the newly 
generated one is correct.

I took the opportunity to copy the text of the e-mail that gave some 
detailed instructions on the automated game text into the wiki.
See 
http://sourceforge.net/apps/mediawiki/rails/index.php?title=Automated_game_testing

Stefan

A final remark:
I do not understand is why the Rails engine does not reject the
saved game file if the ordering of players in the save file is different 
to the one in the game engine, but I have not debugged
the whole process yet, as I expect to work everything correctly as soon 
as the static variables are removed.



On 02/14/2012 09:21 PM, Erik Vos wrote:
>>> However the existing 1835 and a new test case I have added
>>> fail now. This is most likely related to the Clemens variant change of
>>> player priority and rerunning several 1835 in one instance, however
>>> this usually indicates some probability that it is not undo-proof.
>>>
>>> So let us wait for you coming back to solve this jointly.
>>
>> I haven't looked at the non-standard 1835 variants for a long time, so
> it's
>> good to have a test case now.
>> I only see 1835_NatDoubleShare failing, all other cases are OK.  Do you
> have
>> more failures?
>
> I don't understand why JUnit does things different from normal running.
>
> The report expects:
>
> BuysItemFor,T3,M5,80
> FloatsWithCash,M5,80
> BuysItemFor,T2,M1,80<===
> FloatsWithCash,M1,80
> BuysItemFor,T1,M3,80
> FloatsWithCash,M3,80
>
> and that is exactly what happens in a normal run (extract from log):
>
> 2012-02-14 21:08:25 INFO   T3 buys M5 for 80M  (ReportBuffer addMessage 186)
>
> 2012-02-14 21:08:25 INFO   M5 floats and receives 80M  (ReportBuffer
> addMessage 186)
> 2012-02-14 21:08:25 INFO   T2 buys M1 for 80M  (ReportBuffer addMessage 186)
> <===
> 2012-02-14 21:08:25 INFO   M1 floats and receives 80M  (ReportBuffer
> addMessage 186)
> 2012-02-14 21:08:25 INFO   T1 buys M3 for 80M  (ReportBuffer addMessage 186)
>
> 2012-02-14 21:08:25 INFO   M3 floats and receives 80M  (ReportBuffer
> addMessage 186)
>
> so I'm amazed that the JUnit report says that>>T1<<  has bought M3 in its
> test run.
>
> junit.framework.ComparisonFailure: Reports differ in line 13
> expected:<BuysItemFor,T[2],M1,80>  but was:<BuysItemFor,T[1],M1,80>
>
> where line 13 corresponds to the lines where I added arrows.
>
> I'm lost.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel