Create account / Log in

Wannabe VASSAL developer has setup question

Discussion area for the development team.

Moderators: uckelman, Tim M

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

Postby uckelman » September 25th, 2010, 9:25 am

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.
User avatar
uckelman
Site Admin
 
Posts: 9224
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Wannabe VASSAL developer has setup question

Postby pgeerkens » September 25th, 2010, 3:20 pm

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.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

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

Postby uckelman » October 6th, 2010, 11:04 am

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.
User avatar
uckelman
Site Admin
 
Posts: 9224
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Wannabe VASSAL developer has setup question

Postby pgeerkens » November 1st, 2010, 12:51 am

I have now registered at SourceForge, as "pgeerkens".

P.
Pieter
-----------------------------------------
"Even on the attack, I found the spade [to be] the equal of the rifle."
Erwin Rommel, Infantry Attacks
User avatar
pgeerkens
 
Posts: 228
Joined: September 12th, 2010, 4:33 am
Location: Hamilton, Ontario, Canada

Previous

Return to Developers

Who is online

Users browsing this forum: No registered users and 2 guests