rails-devel

[Rails-devel] Automated testing

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

I have added the games that I have received to automated game testing.
Thanks to all contributing save files.
There is also a table of those in the wiki (under developer information).

In the next few days (as time permits) I will add the existing information on 
game testing (from older mails) to the wiki and I hope it will increase the 
usage of those tests.

Currently all tests fail as Erik has changed many things that impacted the 
Game Report (phase names and train obsolete messages).

Question to Erik: If you think all changes are merely phase name changes and 
adding/removing additional messages and you are sure that everything works ok, 
give me a nod and then the game reports can be updated to the current states 
and all tests will show green again.

Unfortunately my master still automatically merges on pull, I will setup the 
master fresh as soon as I have pushed all my current local branches.

Stefan

Re: [Rails-devel] Automated testing

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

It's a unfortunate that even small report format changes render test cases
invalid, and it makes this way of testing much less valuable for me.
I understand that this is the only simple way, but perhaps we should start
thinking about a somewhat more intelligent test evaluation method.

When I do my own regression testing with saved games, the main thing I'm
looking for is that the game runs to the end without throwing exceptions,
and that the end result looks reasonable.
An automated test would of course need to be a bit more thorough:
- are the player and companies turn sequences identical,
- are the cash amounts the same,
And perhaps a few more. 

Only checking the status overview at the end of each round would already do
a lot.  Now that overview only reports cash, and I'm wondering if it would
help to add other possessions,
to create a complete written status overview (like the zines publish about
the games they run), and check only that?

However, that is for the future.  For now, I can't guarantee anything.  I'm
myself occasionally wrestling with saved games that no longer load as a
result of some improvement.
For instance, removing redundant actions (where only 'Done' is possible) has
had that effect in some cases. I still occasionally have to remove 'Done'
actions from saved games to make these loadable again.  Fixing bugs has
equally well invalidated test cases in the past.  So did implementation of
the dynamic company operating order.

I can't tell if any such thing would apply to the current test set, which I
haven't studied. The more recent the file is, the larger the chance that it
is OK.

By private mail I'm sending you some files of the kind that I regularly use
to check if things still work, and that cover some interesting aspects, in
particular in relation to train trading. 
But in general I think recently completed games are more valuable (trusting
that the players haven't missed any errors!).

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, August 01, 2011 7:27 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: [Rails-devel] Automated testing
> 
> I have added the games that I have received to automated game testing.
> Thanks to all contributing save files.
> There is also a table of those in the wiki (under developer information).
> 
> In the next few days (as time permits) I will add the existing information
on
> game testing (from older mails) to the wiki and I hope it will increase
the
> usage of those tests.
> 
> Currently all tests fail as Erik has changed many things that impacted the
> Game Report (phase names and train obsolete messages).
> 
> Question to Erik: If you think all changes are merely phase name changes
and
> adding/removing additional messages and you are sure that everything
> works ok, give me a nod and then the game reports can be updated to the
> current states and all tests will show green again.
> 
> Unfortunately my master still automatically merges on pull, I will setup
the
> master fresh as soon as I have pushed all my current local branches.
> 
> Stefan
> 
> 
> 
>
----------------------------------------------------------------------------
--
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated testing

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

Erik:
the myth that "small report format changes render test cases invalid" is not 
getting true by repetition. It only shows that either I was not able to 
explain the workflow of the tests better or that you are not trying to get a 
better understanding. Maybe both.

See a better explanation below. I will add this to the wiki too.

In general everyone can decide to use the tests or to simply ignore them.
I work with them all the time I simply reset the tests if you have broken 
them. However it always worries me if I realize that tests fail after a code 
change of yours as it is very tedious for me to find out if this was an 
intentional change of the report or a bug (or maybe both). And more important  
it is not my task to quality check your changes.

Thus if you prefer not to use them it does not effect me going on using the 
tests for my own coding. However I would love to increase the quality of the 
whole package Rails by convincing that it is better to test instead of fixing 
bugs after the community reports about broken games.

Sorry for insisting on that but I consider this as a major time saver for all 
of us,
Stefan 


Automated Game Tests:

*** What the test does:

* The test compares a stored game report (which is considered valid) with a 
game report created with current compiled version of Rails. Any difference is 
marked as a failed test.

* If the game throws a Java error, this test is marked as an error.

* As the game report contains all items you refer to below, the test includes 
all required functionality you define below.

* There is no such thing as "the test case is invalid". See below for a 
workflow and further remarks. Either you did a valid change to the game report 
(it was your intention to change it) then you reset the base game report 
(claim the new report as valid), or there has been a code change that broke 
any of the test games.

*** Based on this the workflow for using the test is:

=> You  have a code change that did not change the game report of the test 
games:

* Run the tests. (In package test look for TestGameBuilder and RunAs => JUnit 
Test). A graphical UI shows which test games pass, fail or raise an error.

* If all tests pass, you are happy.

* If a test reports an error, load that game and check what kind of error is 
reported. Fix code and rerun tests.

* If a test reports a failed, click on the first row in FailureTrace and the 
first line where the current report and the expected report differ.
Either think about your premise (no change of game report) or fix code and 
rerun tests.

=> You have a code change that did change the game report of the test games:

* Run tests, all games that are effected by your change of the game report 
will fail. Potentially this can be all tests.

* Reset the tests. (In package test look for TestGameBuilder and RunAs => 
Application). The UI allows you to select either single games or whole folders 
to reset the tests to the now current code base.

* If you now run the tests again, all tests will pass.

*** Further Remarks:
- Running the tests is a matter of seconds. Thus one is able to test often. 
This makes identifying the reason of tests failing easier.

- Due to this workflow try to isolate report changes from other code changes. 

- If test games cannot replayed at a specific point, because the action is 
considered invalid by Rails, this shows as failed. However if it makes sense, 
the games can be truncated and the report reset.

- The game report of the test uses a special language setting (TE_ST), which 
ignores the entries in LocalisedText (have a look at one of the reports in 
test/data). Thus changing the entries in LocalisedText only will not have 
tests fail.




On Monday, August 01, 2011 09:46:16 pm Erik Vos wrote:
> It's a unfortunate that even small report format changes render test cases
> invalid, and it makes this way of testing much less valuable for me.
> I understand that this is the only simple way, but perhaps we should start
> thinking about a somewhat more intelligent test evaluation method.
> 
> When I do my own regression testing with saved games, the main thing I'm
> looking for is that the game runs to the end without throwing exceptions,
> and that the end result looks reasonable.
> An automated test would of course need to be a bit more thorough:
> - are the player and companies turn sequences identical,
> - are the cash amounts the same,
> And perhaps a few more.
> 
> Only checking the status overview at the end of each round would already do
> a lot.  Now that overview only reports cash, and I'm wondering if it would
> help to add other possessions,
> to create a complete written status overview (like the zines publish about
> the games they run), and check only that?
> 
> However, that is for the future.  For now, I can't guarantee anything.  I'm
> myself occasionally wrestling with saved games that no longer load as a
> result of some improvement.
> For instance, removing redundant actions (where only 'Done' is possible)
> has had that effect in some cases. I still occasionally have to remove
> 'Done' actions from saved games to make these loadable again.  Fixing bugs
> has equally well invalidated test cases in the past.  So did
> implementation of the dynamic company operating order.
> 
> I can't tell if any such thing would apply to the current test set, which I
> haven't studied. The more recent the file is, the larger the chance that it
> is OK.
> 
> By private mail I'm sending you some files of the kind that I regularly use
> to check if things still work, and that cover some interesting aspects, in
> particular in relation to train trading.
> But in general I think recently completed games are more valuable (trusting
> that the players haven't missed any errors!).
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday, August 01, 2011 7:27 AM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: [Rails-devel] Automated testing
> > 
> > I have added the games that I have received to automated game testing.
> > Thanks to all contributing save files.
> > There is also a table of those in the wiki (under developer information).
> > 
> > In the next few days (as time permits) I will add the existing
> > information
> 
> on
> 
> > game testing (from older mails) to the wiki and I hope it will increase
> 
> the
> 
> > usage of those tests.
> > 
> > Currently all tests fail as Erik has changed many things that impacted
> > the Game Report (phase names and train obsolete messages).
> > 
> > Question to Erik: If you think all changes are merely phase name changes
> 
> and
> 
> > adding/removing additional messages and you are sure that everything
> > works ok, give me a nod and then the game reports can be updated to the
> > current states and all tests will show green again.
> > 
> > Unfortunately my master still automatically merges on pull, I will setup
> 
> the
> 
> > master fresh as soon as I have pushed all my current local branches.
> > 
> > Stefan
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Got Input?   Slashdot Needs You.
> > Take our quick survey online.  Come on, we don't ask for help often.
> > Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > http://p.sf.net/sfu/slashdot-survey
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated testing

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

Stefan,

Thanks for writing it all up again.  I have printed it and will try to keep
it handy and use it.
Maybe one day it will settle into my brains...

Erik.


> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, August 02, 2011 7:17 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Automated testing
> 
> Erik:
> the myth that "small report format changes render test cases invalid" is
not
> getting true by repetition. It only shows that either I was not able to
explain
> the workflow of the tests better or that you are not trying to get a
better
> understanding. Maybe both.
> 
> See a better explanation below. I will add this to the wiki too.
> 
> In general everyone can decide to use the tests or to simply ignore them.
> I work with them all the time I simply reset the tests if you have broken
> them. However it always worries me if I realize that tests fail after a
code
> change of yours as it is very tedious for me to find out if this was an
> intentional change of the report or a bug (or maybe both). And more
> important it is not my task to quality check your changes.
> 
> Thus if you prefer not to use them it does not effect me going on using
the
> tests for my own coding. However I would love to increase the quality of
the
> whole package Rails by convincing that it is better to test instead of
fixing
> bugs after the community reports about broken games.
> 
> Sorry for insisting on that but I consider this as a major time saver for
all of us,
> Stefan
> 
> 
> Automated Game Tests:
> 
> *** What the test does:
> 
> * The test compares a stored game report (which is considered valid) with
a
> game report created with current compiled version of Rails. Any difference
is
> marked as a failed test.
> 
> * If the game throws a Java error, this test is marked as an error.
> 
> * As the game report contains all items you refer to below, the test
includes
> all required functionality you define below.
> 
> * There is no such thing as "the test case is invalid". See below for a
> workflow and further remarks. Either you did a valid change to the game
> report
> (it was your intention to change it) then you reset the base game report
> (claim the new report as valid), or there has been a code change that
broke
> any of the test games.
> 
> *** Based on this the workflow for using the test is:
> 
> => You  have a code change that did not change the game report of the test
> games:
> 
> * Run the tests. (In package test look for TestGameBuilder and RunAs =>
> JUnit
> Test). A graphical UI shows which test games pass, fail or raise an error.
> 
> * If all tests pass, you are happy.
> 
> * If a test reports an error, load that game and check what kind of error
is
> reported. Fix code and rerun tests.
> 
> * If a test reports a failed, click on the first row in FailureTrace and
the
> first line where the current report and the expected report differ.
> Either think about your premise (no change of game report) or fix code and
> rerun tests.
> 
> => You have a code change that did change the game report of the test
> games:
> 
> * Run tests, all games that are effected by your change of the game report
> will fail. Potentially this can be all tests.
> 
> * Reset the tests. (In package test look for TestGameBuilder and RunAs =>
> Application). The UI allows you to select either single games or whole
folders
> to reset the tests to the now current code base.
> 
> * If you now run the tests again, all tests will pass.
> 
> *** Further Remarks:
> - Running the tests is a matter of seconds. Thus one is able to test
often.
> This makes identifying the reason of tests failing easier.
> 
> - Due to this workflow try to isolate report changes from other code
changes.
> 
> - If test games cannot replayed at a specific point, because the action is
> considered invalid by Rails, this shows as failed. However if it makes
sense,
> the games can be truncated and the report reset.
> 
> - The game report of the test uses a special language setting (TE_ST),
which
> ignores the entries in LocalisedText (have a look at one of the reports in
> test/data). Thus changing the entries in LocalisedText only will not have
> tests fail.
> 
> 
> 
> 
> On Monday, August 01, 2011 09:46:16 pm Erik Vos wrote:
> > It's a unfortunate that even small report format changes render test
cases
> > invalid, and it makes this way of testing much less valuable for me.
> > I understand that this is the only simple way, but perhaps we should
start
> > thinking about a somewhat more intelligent test evaluation method.
> >
> > When I do my own regression testing with saved games, the main thing I'm
> > looking for is that the game runs to the end without throwing
exceptions,
> > and that the end result looks reasonable.
> > An automated test would of course need to be a bit more thorough:
> > - are the player and companies turn sequences identical,
> > - are the cash amounts the same,
> > And perhaps a few more.
> >
> > Only checking the status overview at the end of each round would already
> do
> > a lot.  Now that overview only reports cash, and I'm wondering if it
would
> > help to add other possessions,
> > to create a complete written status overview (like the zines publish
about
> > the games they run), and check only that?
> >
> > However, that is for the future.  For now, I can't guarantee anything.
I'm
> > myself occasionally wrestling with saved games that no longer load as a
> > result of some improvement.
> > For instance, removing redundant actions (where only 'Done' is possible)
> > has had that effect in some cases. I still occasionally have to remove
> > 'Done' actions from saved games to make these loadable again.  Fixing
bugs
> > has equally well invalidated test cases in the past.  So did
> > implementation of the dynamic company operating order.
> >
> > I can't tell if any such thing would apply to the current test set,
which I
> > haven't studied. The more recent the file is, the larger the chance that
it
> > is OK.
> >
> > By private mail I'm sending you some files of the kind that I regularly
use
> > to check if things still work, and that cover some interesting aspects,
in
> > particular in relation to train trading.
> > But in general I think recently completed games are more valuable
(trusting
> > that the players haven't missed any errors!).
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Monday, August 01, 2011 7:27 AM
> > > To: 'Development list for Rails: an 18xx game'
> > > Subject: [Rails-devel] Automated testing
> > >
> > > I have added the games that I have received to automated game testing.
> > > Thanks to all contributing save files.
> > > There is also a table of those in the wiki (under developer
information).
> > >
> > > In the next few days (as time permits) I will add the existing
> > > information
> >
> > on
> >
> > > game testing (from older mails) to the wiki and I hope it will
increase
> >
> > the
> >
> > > usage of those tests.
> > >
> > > Currently all tests fail as Erik has changed many things that impacted
> > > the Game Report (phase names and train obsolete messages).
> > >
> > > Question to Erik: If you think all changes are merely phase name
changes
> >
> > and
> >
> > > adding/removing additional messages and you are sure that everything
> > > works ok, give me a nod and then the game reports can be updated to
> the
> > > current states and all tests will show green again.
> > >
> > > Unfortunately my master still automatically merges on pull, I will
setup
> >
> > the
> >
> > > master fresh as soon as I have pushed all my current local branches.
> > >
> > > Stefan
> >
> >
---------------------------------------------------------------------------
> > - --
> >
> > > Got Input?   Slashdot Needs You.
> > > Take our quick survey online.  Come on, we don't ask for help often.
> > > Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > > http://p.sf.net/sfu/slashdot-survey
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
---------------------------------------------------------------------------
> > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > The must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated testing

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

Erik,
thanks for having a look at automated testing.

I consider it is not as difficult.But as usual suggestions for improvement are 
very welcome.

Regarding the failed tests from your phase changes they show that
A) Phase names in 1856 changed

B) All messages "train obsolete" were removed from 1830_A (C&R variant).

C) All messages "train rusted" were removed from both games 1889 and 18AL_A.

D) 18EU_A surprisingly kept the train rusted messages, but lost the message 
"TrainsAvailable,P".

It seems that A) was an intended change, for B) to D) I am not so sure.
Maybe you should check this.

Stefan


On Tuesday, August 02, 2011 09:02:59 pm Erik Vos wrote:
> Stefan,
> 
> Thanks for writing it all up again.  I have printed it and will try to keep
> it handy and use it.
> Maybe one day it will settle into my brains...
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Tuesday, August 02, 2011 7:17 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Automated testing
> > 
> > Erik:
> > the myth that "small report format changes render test cases invalid" is
> 
> not
> 
> > getting true by repetition. It only shows that either I was not able to
> 
> explain
> 
> > the workflow of the tests better or that you are not trying to get a
> 
> better
> 
> > understanding. Maybe both.
> > 
> > See a better explanation below. I will add this to the wiki too.
> > 
> > In general everyone can decide to use the tests or to simply ignore them.
> > I work with them all the time I simply reset the tests if you have broken
> > them. However it always worries me if I realize that tests fail after a
> 
> code
> 
> > change of yours as it is very tedious for me to find out if this was an
> > intentional change of the report or a bug (or maybe both). And more
> > important it is not my task to quality check your changes.
> > 
> > Thus if you prefer not to use them it does not effect me going on using
> 
> the
> 
> > tests for my own coding. However I would love to increase the quality of
> 
> the
> 
> > whole package Rails by convincing that it is better to test instead of
> 
> fixing
> 
> > bugs after the community reports about broken games.
> > 
> > Sorry for insisting on that but I consider this as a major time saver for
> 
> all of us,
> 
> > Stefan
> > 
> > 
> > Automated Game Tests:
> > 
> > *** What the test does:
> > 
> > * The test compares a stored game report (which is considered valid) with
> 
> a
> 
> > game report created with current compiled version of Rails. Any
> > difference
> 
> is
> 
> > marked as a failed test.
> > 
> > * If the game throws a Java error, this test is marked as an error.
> > 
> > * As the game report contains all items you refer to below, the test
> 
> includes
> 
> > all required functionality you define below.
> > 
> > * There is no such thing as "the test case is invalid". See below for a
> > workflow and further remarks. Either you did a valid change to the game
> > report
> > (it was your intention to change it) then you reset the base game report
> > (claim the new report as valid), or there has been a code change that
> 
> broke
> 
> > any of the test games.
> > 
> > *** Based on this the workflow for using the test is:
> > 
> > => You  have a code change that did not change the game report of the
> > test games:
> > 
> > * Run the tests. (In package test look for TestGameBuilder and RunAs =>
> > JUnit
> > Test). A graphical UI shows which test games pass, fail or raise an
> > error.
> > 
> > * If all tests pass, you are happy.
> > 
> > * If a test reports an error, load that game and check what kind of error
> 
> is
> 
> > reported. Fix code and rerun tests.
> > 
> > * If a test reports a failed, click on the first row in FailureTrace and
> 
> the
> 
> > first line where the current report and the expected report differ.
> > Either think about your premise (no change of game report) or fix code
> > and rerun tests.
> > 
> > => You have a code change that did change the game report of the test
> > games:
> > 
> > * Run tests, all games that are effected by your change of the game
> > report will fail. Potentially this can be all tests.
> > 
> > * Reset the tests. (In package test look for TestGameBuilder and RunAs =>
> > Application). The UI allows you to select either single games or whole
> 
> folders
> 
> > to reset the tests to the now current code base.
> > 
> > * If you now run the tests again, all tests will pass.
> > 
> > *** Further Remarks:
> > - Running the tests is a matter of seconds. Thus one is able to test
> 
> often.
> 
> > This makes identifying the reason of tests failing easier.
> > 
> > - Due to this workflow try to isolate report changes from other code
> 
> changes.
> 
> > - If test games cannot replayed at a specific point, because the action
> > is considered invalid by Rails, this shows as failed. However if it
> > makes
> 
> sense,
> 
> > the games can be truncated and the report reset.
> > 
> > - The game report of the test uses a special language setting (TE_ST),
> 
> which
> 
> > ignores the entries in LocalisedText (have a look at one of the reports
> > in test/data). Thus changing the entries in LocalisedText only will not
> > have tests fail.
> > 
> > On Monday, August 01, 2011 09:46:16 pm Erik Vos wrote:
> > > It's a unfortunate that even small report format changes render test
> 
> cases
> 
> > > invalid, and it makes this way of testing much less valuable for me.
> > > I understand that this is the only simple way, but perhaps we should
> 
> start
> 
> > > thinking about a somewhat more intelligent test evaluation method.
> > > 
> > > When I do my own regression testing with saved games, the main thing
> > > I'm looking for is that the game runs to the end without throwing
> 
> exceptions,
> 
> > > and that the end result looks reasonable.
> > > An automated test would of course need to be a bit more thorough:
> > > - are the player and companies turn sequences identical,
> > > - are the cash amounts the same,
> > > And perhaps a few more.
> > > 
> > > Only checking the status overview at the end of each round would
> > > already
> > 
> > do
> > 
> > > a lot.  Now that overview only reports cash, and I'm wondering if it
> 
> would
> 
> > > help to add other possessions,
> > > to create a complete written status overview (like the zines publish
> 
> about
> 
> > > the games they run), and check only that?
> > > 
> > > However, that is for the future.  For now, I can't guarantee anything.
> 
> I'm
> 
> > > myself occasionally wrestling with saved games that no longer load as a
> > > result of some improvement.
> > > For instance, removing redundant actions (where only 'Done' is
> > > possible) has had that effect in some cases. I still occasionally have
> > > to remove 'Done' actions from saved games to make these loadable
> > > again.  Fixing
> 
> bugs
> 
> > > has equally well invalidated test cases in the past.  So did
> > > implementation of the dynamic company operating order.
> > > 
> > > I can't tell if any such thing would apply to the current test set,
> 
> which I
> 
> > > haven't studied. The more recent the file is, the larger the chance
> > > that
> 
> it
> 
> > > is OK.
> > > 
> > > By private mail I'm sending you some files of the kind that I regularly
> 
> use
> 
> > > to check if things still work, and that cover some interesting aspects,
> 
> in
> 
> > > particular in relation to train trading.
> > > But in general I think recently completed games are more valuable
> 
> (trusting
> 
> > > that the players haven't missed any errors!).
> > > 
> > > Erik.
> > > 
> > > > -----Original Message-----
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > Sent: Monday, August 01, 2011 7:27 AM
> > > > To: 'Development list for Rails: an 18xx game'
> > > > Subject: [Rails-devel] Automated testing
> > > > 
> > > > I have added the games that I have received to automated game
> > > > testing. Thanks to all contributing save files.
> > > > There is also a table of those in the wiki (under developer
> 
> information).
> 
> > > > In the next few days (as time permits) I will add the existing
> > > > information
> > > 
> > > on
> > > 
> > > > game testing (from older mails) to the wiki and I hope it will
> 
> increase
> 
> > > the
> > > 
> > > > usage of those tests.
> > > > 
> > > > Currently all tests fail as Erik has changed many things that
> > > > impacted the Game Report (phase names and train obsolete messages).
> > > > 
> > > > Question to Erik: If you think all changes are merely phase name
> 
> changes
> 
> > > and
> > > 
> > > > adding/removing additional messages and you are sure that everything
> > > > works ok, give me a nod and then the game reports can be updated to
> > 
> > the
> > 
> > > > current states and all tests will show green again.
> > > > 
> > > > Unfortunately my master still automatically merges on pull, I will
> 
> setup
> 
> > > the
> > > 
> > > > master fresh as soon as I have pushed all my current local branches.
> > > > 
> > > > Stefan
> 
> ---------------------------------------------------------------------------
> 
> > > - --
> > > 
> > > > Got Input?   Slashdot Needs You.
> > > > Take our quick survey online.  Come on, we don't ask for help often.
> > > > Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > > > http://p.sf.net/sfu/slashdot-survey
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> 
> > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > The must-attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > The must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated testing

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

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
 
> Regarding the failed tests from your phase changes they show that
> A) Phase names in 1856 changed

Ah yes, I should have reported that. With my latest commit I have also
renamed all (distinct) phases after the last bought train, where that wasn't
the case, deferring the "real" (but not always usable) phase names to the
new "realName" attribute that I have added recently (and is now shown in
square brackets in the UI).  I think I now did 1856 and 1870, 1835 had been
done before (and 1880 by Martin). Not done 1825.
 
> B) All messages "train obsolete" were removed from 1830_A (C&R variant).
> 
> C) All messages "train rusted" were removed from both games 1889 and
> 18AL_A.
> 
> D) 18EU_A surprisingly kept the train rusted messages, but lost the
message
> "TrainsAvailable,P".
> 
> It seems that A) was an intended change, for B) to D) I am not so sure.
> Maybe you should check this.

Nothing was intentional, I had just forgotten to put these report lines into
the new code.
The message "All X-trains are sold out, Y-trains now available" wasn't even
localised, and had to be split into two lines, because the second half is
now displayed on a separate line in *all* cases where a new type becomes
available. So I have added a new "TrainsSoldOut" entry.

To check any differences, I would like to be able to compare the old and new
TE_ST reports line by line in a tool like WinMerge.  Are the new reports
saved anywhere?  If not, wouldn't that be a useful addition, or have you
already made that possible in another way?

Erik

Re: [Rails-devel] Automated testing (7e4acf)

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

Erik:
fixed the failing tests. The issue was that I did not clear NDC.key after each 
test so it still contained a reference due to the previous game(manager) and 
thus confused the mechanism of the initial queue of the report buffer.

I do not save the test reports currently, but that was on my wishlist anyhow.
Do you prefer simply a copy of the test report or a diff-output to the 
expected report which would be easy to create using a java diff library?

Stefan

On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> See below.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > 
> > Regarding the failed tests from your phase changes they show that
> > A) Phase names in 1856 changed
> 
> Ah yes, I should have reported that. With my latest commit I have also
> renamed all (distinct) phases after the last bought train, where that
> wasn't the case, deferring the "real" (but not always usable) phase names
> to the new "realName" attribute that I have added recently (and is now
> shown in square brackets in the UI).  I think I now did 1856 and 1870,
> 1835 had been done before (and 1880 by Martin). Not done 1825.
> 
> > B) All messages "train obsolete" were removed from 1830_A (C&R variant).
> > 
> > C) All messages "train rusted" were removed from both games 1889 and
> > 18AL_A.
> > 
> > D) 18EU_A surprisingly kept the train rusted messages, but lost the
> 
> message
> 
> > "TrainsAvailable,P".
> > 
> > It seems that A) was an intended change, for B) to D) I am not so sure.
> > Maybe you should check this.
> 
> Nothing was intentional, I had just forgotten to put these report lines
> into the new code.
> The message "All X-trains are sold out, Y-trains now available" wasn't even
> localised, and had to be split into two lines, because the second half is
> now displayed on a separate line in *all* cases where a new type becomes
> available. So I have added a new "TrainsSoldOut" entry.
> 
> To check any differences, I would like to be able to compare the old and
> new TE_ST reports line by line in a tool like WinMerge.  Are the new
> reports saved anywhere?  If not, wouldn't that be a useful addition, or
> have you already made that possible in another way?
> 
> Erik
> 
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated testing (7e4acf)

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

Stefan,

I would prefer just a copy of the (new) report, preferably saved in a
separate directory somewhere in the test tree (for instance
test/data/newreports). Name should be identical to the 'old' report name.
This way I can load these directories as a whole into a graphical tool such
as WinMerge that gives a quick overview of the (non-)identity of all
reports, and allows a side-by-side comparison of the two versions of the
each report.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, August 04, 2011 7:52 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Automated testing (7e4acf)
> 
> Erik:
> fixed the failing tests. The issue was that I did not clear NDC.key after
each
> test so it still contained a reference due to the previous game(manager)
and
> thus confused the mechanism of the initial queue of the report buffer.
> 
> I do not save the test reports currently, but that was on my wishlist
anyhow.
> Do you prefer simply a copy of the test report or a diff-output to the
> expected report which would be easy to create using a java diff library?
> 
> Stefan
> 
> On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > See below.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > >
> > > Regarding the failed tests from your phase changes they show that
> > > A) Phase names in 1856 changed
> >
> > Ah yes, I should have reported that. With my latest commit I have also
> > renamed all (distinct) phases after the last bought train, where that
> > wasn't the case, deferring the "real" (but not always usable) phase
> > names to the new "realName" attribute that I have added recently (and
> > is now shown in square brackets in the UI).  I think I now did 1856
> > and 1870,
> > 1835 had been done before (and 1880 by Martin). Not done 1825.
> >
> > > B) All messages "train obsolete" were removed from 1830_A (C&R
> variant).
> > >
> > > C) All messages "train rusted" were removed from both games 1889 and
> > > 18AL_A.
> > >
> > > D) 18EU_A surprisingly kept the train rusted messages, but lost the
> >
> > message
> >
> > > "TrainsAvailable,P".
> > >
> > > It seems that A) was an intended change, for B) to D) I am not so
sure.
> > > Maybe you should check this.
> >
> > Nothing was intentional, I had just forgotten to put these report
> > lines into the new code.
> > The message "All X-trains are sold out, Y-trains now available" wasn't
> > even localised, and had to be split into two lines, because the second
> > half is now displayed on a separate line in *all* cases where a new
> > type becomes available. So I have added a new "TrainsSoldOut" entry.
> >
> > To check any differences, I would like to be able to compare the old
> > and new TE_ST reports line by line in a tool like WinMerge.  Are the
> > new reports saved anywhere?  If not, wouldn't that be a useful
> > addition, or have you already made that possible in another way?
> >
> > Erik
> >
> >
> > ----------------------------------------------------------------------
> > -----
> > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Output of failed tests (a3aed4)

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

Erik,
I have added the function.

I took the freedom to change the details a little to my favored approach. 

If a test fails the failed report is created in the same directory put with a 
different extension (.failed).
If a test runs correctly again, the failed report is automatically deleted.

The reason for the change is that it is easier to fire up the diff tool (at 
least for me) and it avoids creating new directories which are usually empty.

Stefan


On Thursday, August 04, 2011 04:19:12 pm Erik Vos wrote:
> Stefan,
> 
> I would prefer just a copy of the (new) report, preferably saved in a
> separate directory somewhere in the test tree (for instance
> test/data/newreports). Name should be identical to the 'old' report name.
> This way I can load these directories as a whole into a graphical tool such
> as WinMerge that gives a quick overview of the (non-)identity of all
> reports, and allows a side-by-side comparison of the two versions of the
> each report.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Thursday, August 04, 2011 7:52 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Automated testing (7e4acf)
> > 
> > Erik:
> > fixed the failing tests. The issue was that I did not clear NDC.key after
> 
> each
> 
> > test so it still contained a reference due to the previous game(manager)
> 
> and
> 
> > thus confused the mechanism of the initial queue of the report buffer.
> > 
> > I do not save the test reports currently, but that was on my wishlist
> 
> anyhow.
> 
> > Do you prefer simply a copy of the test report or a diff-output to the
> > expected report which would be easy to create using a java diff library?
> > 
> > Stefan
> > 
> > On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > > See below.
> > > 
> > > > -----Original Message-----
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > 
> > > > Regarding the failed tests from your phase changes they show that
> > > > A) Phase names in 1856 changed
> > > 
> > > Ah yes, I should have reported that. With my latest commit I have also
> > > renamed all (distinct) phases after the last bought train, where that
> > > wasn't the case, deferring the "real" (but not always usable) phase
> > > names to the new "realName" attribute that I have added recently (and
> > > is now shown in square brackets in the UI).  I think I now did 1856
> > > and 1870,
> > > 1835 had been done before (and 1880 by Martin). Not done 1825.
> > > 
> > > > B) All messages "train obsolete" were removed from 1830_A (C&R
> > 
> > variant).
> > 
> > > > C) All messages "train rusted" were removed from both games 1889 and
> > > > 18AL_A.
> > > > 
> > > > D) 18EU_A surprisingly kept the train rusted messages, but lost the
> > > 
> > > message
> > > 
> > > > "TrainsAvailable,P".
> > > > 
> > > > It seems that A) was an intended change, for B) to D) I am not so
> 
> sure.
> 
> > > > Maybe you should check this.
> > > 
> > > Nothing was intentional, I had just forgotten to put these report
> > > lines into the new code.
> > > The message "All X-trains are sold out, Y-trains now available" wasn't
> > > even localised, and had to be split into two lines, because the second
> > > half is now displayed on a separate line in *all* cases where a new
> > > type becomes available. So I have added a new "TrainsSoldOut" entry.
> > > 
> > > To check any differences, I would like to be able to compare the old
> > > and new TE_ST reports line by line in a tool like WinMerge.  Are the
> > > new reports saved anywhere?  If not, wouldn't that be a useful
> > > addition, or have you already made that possible in another way?
> > > 
> > > Erik
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > must-attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> > attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, August 06, 2011 8:01 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Output of failed tests (a3aed4)
> 
> Erik,
> I have added the function.
> 
> I took the freedom to change the details a little to my favored approach.
> 
> If a test fails the failed report is created in the same directory put
with a
> different extension (.failed).
> If a test runs correctly again, the failed report is automatically
deleted.
> 
> The reason for the change is that it is easier to fire up the diff tool
(at least for
> me) and it avoids creating new directories which are usually empty.

However, it thwarts my intended usage, because I now have to move and rename
the failed files. Well, I guess I can create  my own version.

Erik.
 
> Stefan
> 
> 
> On Thursday, August 04, 2011 04:19:12 pm Erik Vos wrote:
> > Stefan,
> >
> > I would prefer just a copy of the (new) report, preferably saved in a
> > separate directory somewhere in the test tree (for instance
> > test/data/newreports). Name should be identical to the 'old' report
name.
> > This way I can load these directories as a whole into a graphical tool
> > such as WinMerge that gives a quick overview of the (non-)identity of
> > all reports, and allows a side-by-side comparison of the two versions
> > of the each report.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Thursday, August 04, 2011 7:52 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Automated testing (7e4acf)
> > >
> > > Erik:
> > > fixed the failing tests. The issue was that I did not clear NDC.key
> > > after
> >
> > each
> >
> > > test so it still contained a reference due to the previous
> > > game(manager)
> >
> > and
> >
> > > thus confused the mechanism of the initial queue of the report buffer.
> > >
> > > I do not save the test reports currently, but that was on my
> > > wishlist
> >
> > anyhow.
> >
> > > Do you prefer simply a copy of the test report or a diff-output to
> > > the expected report which would be easy to create using a java diff
> library?
> > >
> > > Stefan
> > >
> > > On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > > > See below.
> > > >
> > > > > -----Original Message-----
> > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > >
> > > > > Regarding the failed tests from your phase changes they show
> > > > > that
> > > > > A) Phase names in 1856 changed
> > > >
> > > > Ah yes, I should have reported that. With my latest commit I have
> > > > also renamed all (distinct) phases after the last bought train,
> > > > where that wasn't the case, deferring the "real" (but not always
> > > > usable) phase names to the new "realName" attribute that I have
> > > > added recently (and is now shown in square brackets in the UI).  I
> > > > think I now did 1856 and 1870,
> > > > 1835 had been done before (and 1880 by Martin). Not done 1825.
> > > >
> > > > > B) All messages "train obsolete" were removed from 1830_A (C&R
> > >
> > > variant).
> > >
> > > > > C) All messages "train rusted" were removed from both games 1889
> > > > > and 18AL_A.
> > > > >
> > > > > D) 18EU_A surprisingly kept the train rusted messages, but lost
> > > > > the
> > > >
> > > > message
> > > >
> > > > > "TrainsAvailable,P".
> > > > >
> > > > > It seems that A) was an intended change, for B) to D) I am not
> > > > > so
> >
> > sure.
> >
> > > > > Maybe you should check this.
> > > >
> > > > Nothing was intentional, I had just forgotten to put these report
> > > > lines into the new code.
> > > > The message "All X-trains are sold out, Y-trains now available"
> > > > wasn't even localised, and had to be split into two lines, because
> > > > the second half is now displayed on a separate line in *all* cases
> > > > where a new type becomes available. So I have added a new
> "TrainsSoldOut" entry.
> > > >
> > > > To check any differences, I would like to be able to compare the
> > > > old and new TE_ST reports line by line in a tool like WinMerge.
> > > > Are the new reports saved anywhere?  If not, wouldn't that be a
> > > > useful addition, or have you already made that possible in another
> way?
> > > >
> > > > Erik
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > The must-attend event for mobile developers. Connect with experts.
> > > > Get tools for creating Super Apps. See the latest technologies.
> > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > must- attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

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

Erik:
sure you could:

However you should be aware that I plan to update the
test code to the JUnit 4 series soon, as I prefer to write unit tests in JUnit 
4 instead of JUnit 3 for my new states implementation.

So you should not simply copy&paste the code, but please add a new entry in 
the configuration files for a failed report directory and use that in the 
existing code. Then you can apply the new settings in test.profile of your 
own.

Still wondering: I do not know the diff viewer you are using, but does it 
really only allow to compare two files with identical names in two different 
directories? 
In my case it as it easy to compare two files with different names in the same 
directory?

Stefan


On Saturday, August 06, 2011 09:36:46 am Erik Vos wrote:
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Saturday, August 06, 2011 8:01 AM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Output of failed tests (a3aed4)
> > 
> > Erik,
> > I have added the function.
> > 
> > I took the freedom to change the details a little to my favored approach.
> > 
> > If a test fails the failed report is created in the same directory put
> 
> with a
> 
> > different extension (.failed).
> > If a test runs correctly again, the failed report is automatically
> 
> deleted.
> 
> > The reason for the change is that it is easier to fire up the diff tool
> 
> (at least for
> 
> > me) and it avoids creating new directories which are usually empty.
> 
> However, it thwarts my intended usage, because I now have to move and
> rename the failed files. Well, I guess I can create  my own version.
> 
> Erik.
> 
> > Stefan
> > 
> > On Thursday, August 04, 2011 04:19:12 pm Erik Vos wrote:
> > > Stefan,
> > > 
> > > I would prefer just a copy of the (new) report, preferably saved in a
> > > separate directory somewhere in the test tree (for instance
> > > test/data/newreports). Name should be identical to the 'old' report
> 
> name.
> 
> > > This way I can load these directories as a whole into a graphical tool
> > > such as WinMerge that gives a quick overview of the (non-)identity of
> > > all reports, and allows a side-by-side comparison of the two versions
> > > of the each report.
> > > 
> > > Erik.
> > > 
> > > > -----Original Message-----
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > Sent: Thursday, August 04, 2011 7:52 AM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] Automated testing (7e4acf)
> > > > 
> > > > Erik:
> > > > fixed the failing tests. The issue was that I did not clear NDC.key
> > > > after
> > > 
> > > each
> > > 
> > > > test so it still contained a reference due to the previous
> > > > game(manager)
> > > 
> > > and
> > > 
> > > > thus confused the mechanism of the initial queue of the report
> > > > buffer.
> > > > 
> > > > I do not save the test reports currently, but that was on my
> > > > wishlist
> > > 
> > > anyhow.
> > > 
> > > > Do you prefer simply a copy of the test report or a diff-output to
> > > > the expected report which would be easy to create using a java diff
> > 
> > library?
> > 
> > > > Stefan
> > > > 
> > > > On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > > > > See below.
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > > > 
> > > > > > Regarding the failed tests from your phase changes they show
> > > > > > that
> > > > > > A) Phase names in 1856 changed
> > > > > 
> > > > > Ah yes, I should have reported that. With my latest commit I have
> > > > > also renamed all (distinct) phases after the last bought train,
> > > > > where that wasn't the case, deferring the "real" (but not always
> > > > > usable) phase names to the new "realName" attribute that I have
> > > > > added recently (and is now shown in square brackets in the UI).  I
> > > > > think I now did 1856 and 1870,
> > > > > 1835 had been done before (and 1880 by Martin). Not done 1825.
> > > > > 
> > > > > > B) All messages "train obsolete" were removed from 1830_A (C&R
> > > > 
> > > > variant).
> > > > 
> > > > > > C) All messages "train rusted" were removed from both games 1889
> > > > > > and 18AL_A.
> > > > > > 
> > > > > > D) 18EU_A surprisingly kept the train rusted messages, but lost
> > > > > > the
> > > > > 
> > > > > message
> > > > > 
> > > > > > "TrainsAvailable,P".
> > > > > > 
> > > > > > It seems that A) was an intended change, for B) to D) I am not
> > > > > > so
> > > 
> > > sure.
> > > 
> > > > > > Maybe you should check this.
> > > > > 
> > > > > Nothing was intentional, I had just forgotten to put these report
> > > > > lines into the new code.
> > > > > The message "All X-trains are sold out, Y-trains now available"
> > > > > wasn't even localised, and had to be split into two lines, because
> > > > > the second half is now displayed on a separate line in *all* cases
> > > > > where a new type becomes available. So I have added a new
> > 
> > "TrainsSoldOut" entry.
> > 
> > > > > To check any differences, I would like to be able to compare the
> > > > > old and new TE_ST reports line by line in a tool like WinMerge.
> > > > > Are the new reports saved anywhere?  If not, wouldn't that be a
> > > > > useful addition, or have you already made that possible in another
> > 
> > way?
> > 
> > > > > Erik
> > > > > 
> > > > > 
> > > > > ------------------------------------------------------------------
> > > > > ----
> > > > > -----
> > > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > > The must-attend event for mobile developers. Connect with experts.
> > > > > Get tools for creating Super Apps. See the latest technologies.
> > > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > - --
> > > 
> > > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > > must- attend event for mobile developers. Connect with experts.
> > > > Get tools for creating Super Apps. See the latest technologies.
> > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > must-attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> > attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

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

The nice thing about tools like WinMerge is that you can compare whole
directory trees, making it show (for instance) the different files only,
which obviously must the have the same name to make this work.  I have been
using that often to compare different versions of some tree, and have done
so with Rails in the past.

But of course it can also load single pairs of files to compare.  Don't
worry, the Rails test set is still small enough to make the one-by-one
comparisons easy to do, in particular if only the failed files are saved.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, August 06, 2011 9:58 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Output of failed tests (a3aed4)
> 
> Erik:
> sure you could:
> 
> However you should be aware that I plan to update the test code to the
> JUnit 4 series soon, as I prefer to write unit tests in JUnit
> 4 instead of JUnit 3 for my new states implementation.
> 
> So you should not simply copy&paste the code, but please add a new entry
> in the configuration files for a failed report directory and use that in
the
> existing code. Then you can apply the new settings in test.profile of your
> own.
> 
> Still wondering: I do not know the diff viewer you are using, but does it
really
> only allow to compare two files with identical names in two different
> directories?
> In my case it as it easy to compare two files with different names in the
same
> directory?
> 
> Stefan
> 
> 
> On Saturday, August 06, 2011 09:36:46 am Erik Vos wrote:
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Saturday, August 06, 2011 8:01 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: [Rails-devel] Output of failed tests (a3aed4)
> > >
> > > Erik,
> > > I have added the function.
> > >
> > > I took the freedom to change the details a little to my favored
approach.
> > >
> > > If a test fails the failed report is created in the same directory
> > > put
> >
> > with a
> >
> > > different extension (.failed).
> > > If a test runs correctly again, the failed report is automatically
> >
> > deleted.
> >
> > > The reason for the change is that it is easier to fire up the diff
> > > tool
> >
> > (at least for
> >
> > > me) and it avoids creating new directories which are usually empty.
> >
> > However, it thwarts my intended usage, because I now have to move and
> > rename the failed files. Well, I guess I can create  my own version.
> >
> > Erik.
> >
> > > Stefan
> > >
> > > On Thursday, August 04, 2011 04:19:12 pm Erik Vos wrote:
> > > > Stefan,
> > > >
> > > > I would prefer just a copy of the (new) report, preferably saved
> > > > in a separate directory somewhere in the test tree (for instance
> > > > test/data/newreports). Name should be identical to the 'old'
> > > > report
> >
> > name.
> >
> > > > This way I can load these directories as a whole into a graphical
> > > > tool such as WinMerge that gives a quick overview of the
> > > > (non-)identity of all reports, and allows a side-by-side
> > > > comparison of the two versions of the each report.
> > > >
> > > > Erik.
> > > >
> > > > > -----Original Message-----
> > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > > Sent: Thursday, August 04, 2011 7:52 AM
> > > > > To: Development list for Rails: an 18xx game
> > > > > Subject: Re: [Rails-devel] Automated testing (7e4acf)
> > > > >
> > > > > Erik:
> > > > > fixed the failing tests. The issue was that I did not clear
> > > > > NDC.key after
> > > >
> > > > each
> > > >
> > > > > test so it still contained a reference due to the previous
> > > > > game(manager)
> > > >
> > > > and
> > > >
> > > > > thus confused the mechanism of the initial queue of the report
> > > > > buffer.
> > > > >
> > > > > I do not save the test reports currently, but that was on my
> > > > > wishlist
> > > >
> > > > anyhow.
> > > >
> > > > > Do you prefer simply a copy of the test report or a diff-output
> > > > > to the expected report which would be easy to create using a
> > > > > java diff
> > >
> > > library?
> > >
> > > > > Stefan
> > > > >
> > > > > On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > > > > > See below.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > > > >
> > > > > > > Regarding the failed tests from your phase changes they show
> > > > > > > that
> > > > > > > A) Phase names in 1856 changed
> > > > > >
> > > > > > Ah yes, I should have reported that. With my latest commit I
> > > > > > have also renamed all (distinct) phases after the last bought
> > > > > > train, where that wasn't the case, deferring the "real" (but
> > > > > > not always
> > > > > > usable) phase names to the new "realName" attribute that I
> > > > > > have added recently (and is now shown in square brackets in
> > > > > > the UI).  I think I now did 1856 and 1870,
> > > > > > 1835 had been done before (and 1880 by Martin). Not done 1825.
> > > > > >
> > > > > > > B) All messages "train obsolete" were removed from 1830_A
> > > > > > > (C&R
> > > > >
> > > > > variant).
> > > > >
> > > > > > > C) All messages "train rusted" were removed from both games
> > > > > > > 1889 and 18AL_A.
> > > > > > >
> > > > > > > D) 18EU_A surprisingly kept the train rusted messages, but
> > > > > > > lost the
> > > > > >
> > > > > > message
> > > > > >
> > > > > > > "TrainsAvailable,P".
> > > > > > >
> > > > > > > It seems that A) was an intended change, for B) to D) I am
> > > > > > > not so
> > > >
> > > > sure.
> > > >
> > > > > > > Maybe you should check this.
> > > > > >
> > > > > > Nothing was intentional, I had just forgotten to put these
> > > > > > report lines into the new code.
> > > > > > The message "All X-trains are sold out, Y-trains now available"
> > > > > > wasn't even localised, and had to be split into two lines,
> > > > > > because the second half is now displayed on a separate line in
> > > > > > *all* cases where a new type becomes available. So I have
> > > > > > added a new
> > >
> > > "TrainsSoldOut" entry.
> > >
> > > > > > To check any differences, I would like to be able to compare
> > > > > > the old and new TE_ST reports line by line in a tool like
WinMerge.
> > > > > > Are the new reports saved anywhere?  If not, wouldn't that be
> > > > > > a useful addition, or have you already made that possible in
> > > > > > another
> > >
> > > way?
> > >
> > > > > > Erik
> > > > > >
> > > > > >
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > -----
> > > > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San
> > > > > > Francisco, CA The must-attend event for mobile developers.
> Connect with experts.
> > > > > > Get tools for creating Super Apps. See the latest technologies.
> > > > > > Sessions, hands-on labs, demos & much more. Register early &
> save!
> > > > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > > > _______________________________________________
> > > > > > Rails-devel mailing list
> > > > > > Rai...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > - --
> > > >
> > > > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > > The
> > > > > must- attend event for mobile developers. Connect with experts.
> > > > > Get tools for creating Super Apps. See the latest technologies.
> > > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > The must-attend event for mobile developers. Connect with experts.
> > > > Get tools for creating Super Apps. See the latest technologies.
> > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > must- attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

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

Stefan,

Not sure what has changed, but on another attempt to run the JUnit tests I'm
getting massive differences, all related to one specific special character
being differently encoded. 
Error messages are like:

real\1889_A(test.TestGame)
junit.framework.ComparisonFailure: Reports differ in line 5
expected:<PlayerCash,[Â]¥420> but was:<PlayerCash,[]¥420>

and 

real\18EU_A(test.TestGame)
junit.framework.ComparisonFailure: Reports differ in line 611
expected:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B> but
was:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B>

Only 1889 (on the ¥) and 18EU (on the Ö) fail this way.  No more failures
with other games.
My best guess for a cause is that Unicode characters in the .report files
are no longer recognised as such.  Can the formats in the repository have
changed?

Erik.


> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Saturday, August 06, 2011 11:48 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Output of failed tests (a3aed4)
> 
> The nice thing about tools like WinMerge is that you can compare whole
> directory trees, making it show (for instance) the different files only,
which
> obviously must the have the same name to make this work.  I have been
> using that often to compare different versions of some tree, and have done
> so with Rails in the past.
> 
> But of course it can also load single pairs of files to compare.  Don't
worry, the
> Rails test set is still small enough to make the one-by-one comparisons
easy
> to do, in particular if only the failed files are saved.
> 
> Erik.

Re: [Rails-devel] Output of failed tests (a3aed4)

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

Erik,
The encoding (at least accoding to my editor) of the report files is still 
UTF-8 and they open up in the editor correctly.
All tests report passed as well.
However to avoid those issues I suggest to remove the currency indicator from 
the report files used for testing.
I can do the code change tomorrow.
Stefan



On Tuesday, August 09, 2011 03:44:12 pm Erik Vos wrote:
> Stefan,
> 
> Not sure what has changed, but on another attempt to run the JUnit tests
> I'm getting massive differences, all related to one specific special
> character being differently encoded.
> Error messages are like:
> 
> real\1889_A(test.TestGame)
> junit.framework.ComparisonFailure: Reports differ in line 5
> expected:<PlayerCash,[Â]¥420> but was:<PlayerCash,[]¥420>
> 
> and
> 
> real\18EU_A(test.TestGame)
> junit.framework.ComparisonFailure: Reports differ in line 611
> expected:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B> but
> was:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B>
> 
> Only 1889 (on the ¥) and 18EU (on the Ö) fail this way.  No more failures
> with other games.
> My best guess for a cause is that Unicode characters in the .report files
> are no longer recognised as such.  Can the formats in the repository have
> changed?
> 
> Erik.
> 
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Saturday, August 06, 2011 11:48 AM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Output of failed tests (a3aed4)
> > 
> > The nice thing about tools like WinMerge is that you can compare whole
> > directory trees, making it show (for instance) the different files only,
> 
> which
> 
> > obviously must the have the same name to make this work.  I have been
> > using that often to compare different versions of some tree, and have
> > done so with Rails in the past.
> > 
> > But of course it can also load single pairs of files to compare.  Don't
> 
> worry, the
> 
> > Rails test set is still small enough to make the one-by-one comparisons
> 
> easy
> 
> > to do, in particular if only the failed files are saved.
> > 
> > Erik.
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

[John A. T. <ja...@ja...>]

On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:

> The encoding (at least accoding to my editor) of the report files is still
> UTF-8 and they open up in the editor correctly.
> All tests report passed as well.
> However to avoid those issues I suggest to remove the currency indicator
> from
> the report files used for testing.
> I can do the code change tomorrow.
>

It won't be just currency characters -- you would have to avoid all names in
the game as well.

Better to make sure everything is always stored as UTF8 and interpreted as
UTF8 and be done with it.

-- 
John A. Tamplin

[Rails-devel] Automated test reports without currency identifier (19de64)

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

I agree that it is the better solution to have UTF-8 working all the time 
(maybe Brett could check the setup of the git repo?)
However it was easy to adjust the test.profile such that the reports do not 
contain the problematic yen and euro currency characters.


On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
> On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:
> > The encoding (at least accoding to my editor) of the report files is
> > still UTF-8 and they open up in the editor correctly.
> > All tests report passed as well.
> > However to avoid those issues I suggest to remove the currency indicator
> > from
> > the report files used for testing.
> > I can do the code change tomorrow.
> 
> It won't be just currency characters -- you would have to avoid all names
> in the game as well.
> 
> Better to make sure everything is always stored as UTF8 and interpreted as
> UTF8 and be done with it.

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

[brett l. <bre...@gm...>]

On Thu, Aug 11, 2011 at 9:11 AM, Stefan Frey <ste...@we...> wrote:
> I agree that it is the better solution to have UTF-8 working all the time
> (maybe Brett could check the setup of the git repo?)
> However it was easy to adjust the test.profile such that the reports do not
> contain the problematic yen and euro currency characters.
>

I'll check out what settings are available for that. I might just need
to write up a commit hook to auto-convert incoming changesets.

For the next month, I'm going to be crazy busy, but I'll try to
squeeze this in as soon as I can.

---Brett.

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

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

But that doesn't fix the same problem with KKÖB in 18EU.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, August 11, 2011 6:12 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Automated test reports without currency identifier
> (19de64)
> 
> I agree that it is the better solution to have UTF-8 working all the time
> (maybe Brett could check the setup of the git repo?) However it was easy
to
> adjust the test.profile such that the reports do not contain the
problematic
> yen and euro currency characters.
> 
> 
> On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
> > On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...>
> wrote:
> > > The encoding (at least accoding to my editor) of the report files is
> > > still UTF-8 and they open up in the editor correctly.
> > > All tests report passed as well.
> > > However to avoid those issues I suggest to remove the currency
> > > indicator from the report files used for testing.
> > > I can do the code change tomorrow.
> >
> > It won't be just currency characters -- you would have to avoid all
> > names in the game as well.
> >
> > Better to make sure everything is always stored as UTF8 and
> > interpreted as
> > UTF8 and be done with it.
> 
>
----------------------------------------------------------------------------
--
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out
of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

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

no, it does not. So either we have to make sure that UTF-8 is working 
everywhere (git-repo and all developers clones) or pipe the report output 
at the test run through a conversion to an ISO-8859-1 charset as in HTML.

On Thursday, August 11, 2011 06:14:25 pm Erik Vos wrote:
> But that doesn't fix the same problem with KKÖB in 18EU.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Thursday, August 11, 2011 6:12 PM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Automated test reports without currency identifier
> > (19de64)
> > 
> > I agree that it is the better solution to have UTF-8 working all the time
> > (maybe Brett could check the setup of the git repo?) However it was easy
> 
> to
> 
> > adjust the test.profile such that the reports do not contain the
> 
> problematic
> 
> > yen and euro currency characters.
> > 
> > On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
> > > On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...>
> > 
> > wrote:
> > > > The encoding (at least accoding to my editor) of the report files is
> > > > still UTF-8 and they open up in the editor correctly.
> > > > All tests report passed as well.
> > > > However to avoid those issues I suggest to remove the currency
> > > > indicator from the report files used for testing.
> > > > I can do the code change tomorrow.
> > > 
> > > It won't be just currency characters -- you would have to avoid all
> > > names in the game as well.
> > > 
> > > Better to make sure everything is always stored as UTF8 and
> > > interpreted as
> > > UTF8 and be done with it.
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> > administration capabilities and model configuration. Take the hassle out
> 
> of
> 
> > deploying and managing Subversion and the tools developers use with it.
> > http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

[John A. T. <ja...@ja...>]

On Thu, Aug 11, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:

> no, it does not. So either we have to make sure that UTF-8 is working
> everywhere (git-repo and all developers clones) or pipe the report output
> at the test run through a conversion to an ISO-8859-1 charset as in HTML.


There is no guarantee that every character is representable in Latin1.
Time to stop living in the 80s and just use Unicode.

-- 
John A. Tamplin