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

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

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.