Page 2 of 2

Re: [messages] Edit: [Developers] Re: Wannabe VASSAL develop

PostPosted: September 25th, 2010, 9:25 am
by uckelman
Thus spake Michael Kiefte:
>
> I should also point out that the trunk is not really guaranteed to compile.
> Try checking out branches/3.1 and see if you can get that to compile first.
>

Ken complains at me rather quickly when it doesn't compile, so it's almost
always in a state where it compiles. There's no guarantee that it *works*.

--
J.

Re: Wannabe VASSAL developer has setup question

PostPosted: September 25th, 2010, 3:20 pm
by pgeerkens
This comment got me thininking about a complex reporting and analysis application that I was lead developer on back in the '90's. Using the macro facility we built the means to automatically run every test case which had been submitted as a previous bug. This was launched every night upon completion of a complete build of FDA (the reporting/analysis product), with it's output going to individually named files for each test case. The UNIX diff facility ran comparison of each test case against the preserved standard output for each test case, and all non-zero comparisons were emailed to me at 8:00 in the morning, waiting for me when I arrived at 8:30.

This process allowed us to catch every regression of a previously reported defect in TEST. For over three years the team continued to enhance this product without ever regressing a previously reported defect into PRODUCTION.

By adhering to a discipline where we built everything from the bottom up, almost always in small steps which could be checked-in each evening, any regressions found in TEST were invariably simple to cure because of always being the result of the previous days work.

So my thought of the day is - Are there any portions of VASSAL that would be amenable to this treatment? The key features of the process are:
- a means to automate the performance of user tasks with the software; and
- a means (XML?) to output the results of that in a text format which can be diff''ed against a previously captured correct output.

Re: [messages] [Developers] Re: Wannabe VASSAL developer has

PostPosted: October 6th, 2010, 11:04 am
by uckelman
Thus spake pgeerkens:
> This comment got me thininking about a complex reporting and analysis
> application that I was lead developer on back in the '90's. Using the
> macro facility we built the means to automatically run every test case
> which had been submitted as a previous bug. This was launched every
> night upon completion of a complete build of FDA (the reporting/analysis
> product), with it's output going to individually named files for each
> test case. The UNIX _diff[i] facility ran comparison of each test case
> against the preserved [i]standard_ output for each test case, and all
> non-zero comparisons were emailed to me at 8:00 in the morning, waiting
> for me when I arrived at 8:30.
>
> This process allowed us to catch every regression of a previously
> reported defect in TEST. For over three years the team continued to
> enhance this product without ever regressing a previously reported
> defect into PRODUCTION.
>
> By adhering to a discipline where we __built__ everything from the
> bottom up, almost always in small steps which could be checked-in each
> evening, any regressions found in TEST were invariably simple to cure
> because of always being the result of the previous days work.
>
> So my thought of the day is - Are there any portions of VASSAL that
> would be amenable to this treatment? The key features of the process
> are:
> - a means to automate the performance of user tasks with the software;
> and
> - a means (XML?) to output the results of that in a text format which
> can be diff''ed against a previously captured _correct_ output.
>

Basically what you're talking about is a unit testing and continuous
integration framework. VASSAL is using JUnit for unit testing, but we're
right at the beginning of writing tests. We're writing tests for all new
code, but we have heaps of old code which is in desperate need of tests.
If you'd like to help us write tests, that would be quite welcome.

If you look at the trunk, our tests are under the test/ directory. Right
now, Ken Stevens is heading up writing tests for old code. Hopefully this
will get his attention, and he'll comment on where you might start.

(BTW, have you registered at SF yet? I can't add you as a developer until
you do that.)

--
J.

Re: Wannabe VASSAL developer has setup question

PostPosted: November 1st, 2010, 12:51 am
by pgeerkens
I have now registered at SourceForge, as "pgeerkens".

P.