301 Days (redux)

Another metric leap year of gamedev experiments and such

Jun 20, 2016 - OldDays seitan-spin

Day 57 - APP_VERSION

The Giving Codebase

In which we dip a toe into some low-hanging fruit.

The low-hanging fruit

The most finite set of inputs is probably the config XML file, so let’s hit that. The default config XML looks like this:

DragonsSpine/App.config GitLab 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<appSettings>
		<add key="APP_VERSION" value="2.0.99.9" />
		<add key="CLIENT_VERSION" value="0.0.1" />
		<add key="APP_NAME" value="Drag Spin Exp" />
		<add key="NEWS" value="^8/1/2015^Fork - This experimental version is a fork of verion 2.0.16.5 of Dragon's Spine^^" />
		<add key="APP_PROTOCOL" value="Kesmai" />
		<add key="ClearStores" value="False"/>
		<add key="RestockStores" value="True"/>
		<add key="ColorLog" value="True"/>
		<add key="RequireMakeRecallReagent" value="False"/>
		<add key="DisplayCombatDamage" value="True"/>
		<add key="UnderworldEnabled" value="False"/>
		<add key="NPCSkillGain" value="False"/>
    <add key="SQL_CONNECTION" value="User ID='db_user';Password='db_password';Initial Catalog='drag-spin-exp';Data Source='localhost\SQLEXPRESS';Connect Timeout=15"/>
	</appSettings>
  <runtime>
    <gcServer enabled="True"/>
    <disableCachingBindingFailures enabled="1"/>
  </runtime>
</configuration>

APP_VERSION, huh? Shows up in the log, in the welcome message for new connections, and various menus. It also gets sent over in a “world information” block if the client is using the specified APP_PROTOCOL, but we’ll set that aside for now.

features/config_file.feature GitLab 
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

Scenario: APP_VERSION reflected in the log
	Given I use the "minimal" database
	And I set "APP_VERSION" in the config file to "12.34.567"
	When the server executable is started
	And I allow time for the server to complete startup
	Then the log shows the application version as "12.34.567"

Scenario: APP_VERSION reflected in the welcome message
	Given I use the "minimal" database as-is
	And I set "APP_VERSION" in the config file to "34.56.789"
	And the server executable is started
	And I allow time for the server to complete startup
	When a telnet connection
	Then I see a welcome message with version "34.56.789"

Scenario: APP_VERSION reflected in the main menu
	Given I use the "minimal" database as-is
	And I set "APP_VERSION" in the config file to "45.56.789"
	And the server executable is started
	And I allow time for the server to complete startup
	When I log on using a standard account
	Then I saw a main menu with version "45.56.789"

Scenario: APP_VERSION reflected in the account menu
	Given I use the "minimal" database as-is
	And I set "APP_VERSION" in the config file to "56.56.789"
	And the server executable is started
	And I allow time for the server to complete startup
	When I log on using a standard account
	And I go to the account menu from the main menu
	Then I saw an account menu with version "56.56.789"

Scenario: APP_VERSION reflected in the character menu
	Given I use the "minimal" database as-is
	And I set "APP_VERSION" in the config file to "66.56.789"
	And the server executable is started
	And I allow time for the server to complete startup
	When I log on using a standard account
	And I go to the character menu from the main menu
	Then I saw a character menu with version "66.56.789"

And the test code grows and morphs some more. The highlights: abstracted out a general set_value_in_configfile method, added a @last_resp instance variable so we can check what was seen in response to the last command in a subsequent test step, and found out that the Character Menu doesn’t end with a command prompt for some reason.

14 scenarios (14 passed)
80 steps (80 passed)
2m47.588s

APP_NAME should now be pretty trivial. Tomorrow.

Useful Stuff

More to come

Day 57 code - tests