Re: [Rails-devel] Train management & dual trains

[Erik V. <eri...@xs...>]

Stefan,

Wasn't it the case that all or most of the old tests did no longer work?  Or
have you fixed that in the meantime?

Obviously, the value of regression testing hinges upon the correctness and
reach of the test set, and I didn't have a high opinion of our original set
on both accounts. 
If I remember correctly, soon after you created this test set, I found it
starting to fall apart, and I apologize for not having spent any effort to
fix it while you were away. To me, JUnit testing was new, and I'm still not
used to it. 

However, I agree that it's a good thing to have and use such a test set, so
I'll have another look at it. A good and complete Wiki page would definitely
help a lot.

As to the test set, I think this should be a mix of complete games and
specially constructed test cases.  I only can provide the latter, as I don't
use Rails for playing myself. 
Scott Petersen has recently (22 June) reported that he had successfully run
a series of complete games of various kinds after I had done the Train
management changes.  Perhaps Scott could be persuaded to make his files
available for regression testing?  

I will try to familiarize myself again with this stuff, and then try to
select some useful test cases for addition to the set. The name of such
specially constructed saved files should somehow indicate their purpose.

Erik.
  
> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: dinsdag 5 juli 2011 7:47
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management & dual trains
> 
> Erik:
> sorry I forgot to reply to your question on automated tests recently:
> The test cases are dependent on the game report, but the can be
> reinitialized easily by a few mouse clicks (see the document before).
> So the short answer: No the test cases do not depend on minor detail
> changes, as long as the use case is followed. And they can easily be
> reinitialized again, but all bugs that got in in the mean time will stay
> undetected.
> 
> Thus the use case for changes in the game report is:
> A) Check that all test cases report green.
> B) Make the code change that alters the game report.
> {C) All test cases will report red.}
> D) Reinitialize all test cases by selecting the root test directory.
> {E) All test cases will report green.}
> 
> This is not required if you change only the text in LocalizedProperties,
as the
> test is language independent.
> 
> However after you ignored the test cases for so long (and I did not run
the
> tests myself), that I wanted to figure out first, why the did not run at
all.
> And it can always be related to changes in the game report or due to
> undetected bugs.
> 
> But as the report changed the undetected bugs (if there are any left) will
stay
> undetected, as I will simply reinitialize the test cases and all will show
green
> again.
> 
> I still hope I could convince you to use the tests, as they are the only
chance
> to capture bugs especially for those games which are not implemented by
> yourself (as in the 1889 example before).
> 
> Stefan
> 
> 
> >
> > I can't remember any such change, so I can't give a specific reason,
> > but it's well possible that I have done that at some point.
> > However, if our test cases are dependent on such details, I'm not very
> > happy about that.
> > Improvements must remain possible. Very recently I added a report line
> > about President's cash contributed in  emergency train buying - this
> > was completely unreported so far.
> >
> > I suspect that by now many old test cases will appear to be out of
> > date for other reasons too.  Almost all of my 18EU cases are invalid
> > and must be edited because one redundant Skip action had been removed
> > at some point.  I suppose we should revisit that whole test set.
> > That's a separate subproject in its own right...
> >
> > I attach two test cases that I have used intensively to test the train
> > management changes against. These two cases cover a lot of ground.
> > Unfortunately, the 18EU map is wrong because it still originates from
> > the time before I rotated tile #4, so all these tiles are shown
> > oriented wrongly. Again, this applies to most of my 18EU test cases. I
> > suppose I will have to write a special conversion program to fix that...
> >
> > > There is one (non-official) test however, that already stops with a
> >
> > null-point
> >
> > > exception on buying a train. Save file is attached.
> >
> > That's caused by a bug in the 1830 Pere Marquette configuration. The
> > 6-train releases a 7-train, which is not defined for that variant.
> > This bug must have crept in while recently adding many other variants.
> > I don't have the PM rules, but from your original commit I conclude,
> > that PM has no 7-train, so I have fixed it accordingly.  I have also
> > added checks to catch such misfits during XML parsing.
> >
> > Erik.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel