[Freeciv-Dev] Re: It is feature freeze time

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 29 Apr 2002, Per I. Mathisen wrote:

> On Mon, 29 Apr 2002, Raimar Falke wrote:
> > Either I misunderstood it or it doesn't make sense. If we:
> >  1) construct a savegame
> >  2) let a pseudo-server load the savegame and test various parts
> > there no way the constructed savegame can be modified.
> 
> It is not primarily intended to be modified. This is unit testing, not
> behaviour testing.
> 
> > Problem here is that in 2) you can't restrict the server (say only do
> > diplomacy actions or do only fiddle with your tech tree). So while you
> > may fiddle with the diplomacy code (and add a test code for this) the
> > city calculation is changed (say by the generalized improvement stuff)
> 
> The clue is to not actually do any changes. (Or if we do changes, keep
> them localized or last in the test run.)
> 
> Here an example. In the ports attack patch, we want to add tests for subs
> attacking cities. So we add a sub to the savegame map, and three adjacent
> cities. Each has a warrior. The second also has a trireme. The third has a
> trireme and a coastal. Now we run get_defender and can_attack_tile etc,
> and check if we get the right results.
> 
> Various tests we can add:
> 
> FC_TEST(!get_defender(punit, x1, y1), "Warrior chosen as defender "\
>                                     "against sub");
> FC_TEST(get_defender(punit, x2, y2), "Trireme not chosen as "\
>                                    "defender against sub");
> FC_TEST(!get_defender(punit, x3, y3), "Sub able to attack despite "\
>                                     "presence of coastal");
> FC_TEST(!can_unit_attack_tile(punit, x1, y1), "Sub could attack...");
> FC_TEST(can_unit_attack_tile(punit, x2, y2), "Sub could not attack...");
> FC_TEST(!can_unit_attack_tile(punit, x3, y3), "Sub could attack...");
> FC_TEST(unit_behind_coastal(get_defender(punit, x3, y3)),
>       "Unit not behind coastal after all!");
> 

I doubt this can achieve much.  The tests listed here are what any
responcible author already does before submission (occassionally an
author forgets, but occasionally an author would forget this too).  The
significant part of testing is making sure that *unnexpected* things don't
mess up.  The server doesn't crash if the city is guarded by a
helicopter.  Partisans don't respect ZOC. etc. etc.

Any bug which can be practically included in an automated tester of this
sort is too easy to test to make this worthwhile.

Of course, I'd love to be prooved wrong!

--Daniel Speyer
If you *don't* consider sharing information to be morally equivalent to 
kidnapping and murder on the high seas, you probably shouldn't use the
phrase "software piracy."

> The right thing to do is to add these tests _before_ you write the patch,
> that way you can more easily see what needs to be changed and where you
> are getting it wrong. Adding such tests to a patch also helps prove the
> patch is working as intended, making life easier for maintainers.
> 
> > and now the AI will choose different diplomacy actions. Or to say it
> > another way: we currently have only the server AI which will stimulate
> > various regions of code (and not even all, network for example).
> 
> Network is harder. But we might fork a psedu-client which stimulates the
> pseudo-server with network input, as long as we are done testing global
> stuff and don't care about global side-effects anymore. Then we can test
> changing production to an illegal value, moving a unit onto a full
> transport, etc, from the pseudo-client and check if the result is good
> with FC_TEST() afterwards just like above.
> 
> Yours,
> Per
> 
> Ask not what you can do for your country
> Ask what your country did to you
>  -- KMFDM, Dogma
> 
> 
>