Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: It is feature freeze time
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: It is feature freeze time
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 29 Apr 2002 16:00:48 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Apr 29, 2002 at 12:38:53PM +0200, 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!");
> 
> 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.

So the test contains the FC_TEST stuff and the savegame. Where is the
FC_TEST stuff? In the normal code? I'm against this since these
FC_TESTs are useless without the savegame. Also we have asserts for
the general cases. Another way would be to have the FC_TESTs as a
patch (which is together with the savegame is included in the CVS
tree). But this is required some kind of scripts to patch the tree,
apply the patch and test the savegame.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  One nuclear bomb can ruin your whole day.


[Prev in Thread] Current Thread [Next in Thread]