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: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: It is feature freeze time
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Mon, 29 Apr 2002 12:38:53 +0200 (MEST)

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.

> 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



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