• Problem: The GUI engine shares the same JS space as the simulation, which makes it far too easy to break synchronisation.
• Solution: Separate the GUI and simulation so that they can be loaded independently. Also the setup of the simulation should not be dependent upon the GUI (so that -quickstart works). (Ask Philip for help if any questions.)

• Problem: A common GUI need are tables or lists of buttons with similar properties, such as a construction queue, list of garrisoned unit portraits, or table of statistics. Creating,
• Solution: One solution is to be able to omit the XML and create a control instance entirely from script. A much safer solution, however, would be a "grid" control which acts as a container for an array of child objects of the same type with the same default properties from a given starting position. Only one grid would need to be declared and it would generate a specified number of child controls. It would automatically take care of lining up the buttons and fit to a specific spacing/rows/columns if specified. The child objects could then be individually accessed and their properties modified.

Background: using an existing Unit/self-test framework is deemed helpful (see 2006-05-27 meeting) Chiefly based on ​evaluation, we choose ​CxxTest as unit testing framework.

Basic usage:

• self-tests are separate Cpp files that contain only the test code. (splitting is necessary so that cxxtestgen doesn't have to parse the entire codebase)
• they are stored in a tests subdir of the source directory (simplifies finding the relevant test file for purposes of editing it)
• a workspace generated by premake enumerates all test files, uses custom build step to generate the actual test code, and then links it all into a separate program that runs all tests. Note: separating test code from the main PS executable has several advantages as ​documented
• only running certain tests will be possible (shortens iteration time when only editing one module).

TODO:

• add CxxTest to SVN
• generate workspace for the test program (via premake)
• move all existing tests over to that
• add squelchNextError feature, use it in string_s test
• make sure all tests run successfully
• filtering: modify(/replace/subclass) TestRunner and change its runWorld() so that it filters by the SuiteDescription.testName().