Day 56 - A test, a plan, Panama?

In which we automate one trivial test, and plan how to attack the rest.

An easy one with a minor suprise

#

Before shifting gears a little, let’s finish up connect.feature with the one remaining scenario: “Disallow connection if server in ShuttingDown mode”.

28
29
30
31

Scenario: Disallow connection if server in ShuttingDown mode
Given the server is running
When a developer issues the shutdown command
Then I can not connect to the server via telnet

If we flesh this out a bit, we already have most of the pieces:

27
28
29
30
31
32
33
34

Scenario: Disallow connection if server in ShuttingDown mode
Given I use the "minimal" database as-is
When the server executable is started
And I allow time for the server to complete startup
When I log on using a developer account
And I enter the chat
And I issue the shutdown command and am immediately disconnected
Then I can not connect to the server via telnet

The “and am immediately disconnected” part came as a bit of a surprise. I wasn’t expecting it, but after seeing it happen I was led to consult the main game loop:

278
279
280
281
282
283
284
285
286

  while (DragonsSpineMain.ServerStatus <= DragonsSpineMain.ServerState.Locked)
  {
    this.CleanupLists();
    io.HandleNewConnections();
    io.GetInput();
    io.ProcessRealTimeCommands();
    io.SendOutput();
    System.Threading.Thread.Sleep(100);
  }

Since DragonsSpineMain.ServerState.Locked is 2 and DragonsSpineMain.ServerState.ShuttingDown is 3, we fall out of the loop and shut down as soon as the state is set. Just goes to show that my searching the source for ShuttingDown was not sufficient to reveal the effects.

9 scenarios (9 passed)
49 steps (49 passed)
3m21.522s

A Cunning Plan

#

I have two goals in the test-writing phase of this project:

1. Establish an exhaustive-enough set of tests to know when I’ve successfully recreated the behaviour of the existing code.
2. Learn enough about the existing code to effectively recreate its behaviour.

I’ve been uncertain how to tackle this. The initial tests came from poring through some of the server source files, but I don’t think that’s the best way to proceed. It’s clear that as the code evolved over time, it developed a lot of structure that’s pretty foreign to me. I can’t be confident that my reading of it will accurately capture all of the behaviour that I need to verify.

So I’m adopting something closer to a data-driven testing approach, although not purely so (the tests will still be more narrative than data). The flow of data through the server logic comes from a set of inputs:

1. Config XML
2. Database
3. Map files
4. Outside-of-game players
5. In-game players
6. Internal server state
7. Clock/calendar
8. Hardcoded values

… and goes to one or more of a set of outputs:

1. Database
2. Outside-of-game players
3. In-game players
4. Internal server state
5. Logs

… giving me thirteen major sections of tests. Breaking them down further can also be guided by which I/O pairs are in play.

It’ll all make sense once we really get started. Tomorrow.

Random nostalgia

#

I came across this old issue of Computer Gaming World from the summer of 1986 (bless you, textfiles.com) covering Island of Kesmai in their “Telecommunication Gaming” column. I’m pretty certain I had this magazine at some point.

Day 56 code - tests