More automated tests

[jspjutNV]

134 gives us the framework to test core FPSci functionality. This issue is here to discuss the kinds of tests that should be added to avoid regressions in functionality as we add features.

[bboudaoud-nv]

Testing the various configuration options from the startup config downward would be a great suite of tests to setup.

Specifically we could begin with testing the following from the startup config:

• developerMode flag works as intended
  • Additional menus are available (G3D developer windows and debug pane)
  • G3D Developer window, camera control window, and scene editor are visible by default
  • Debug window is visible and correctly located/sized
  • FPSci debugs windows (render, player, and weapon) are all accessible from the debug window
  • Extra key bindings are supported correctly (and can open the render, player, and weapon windows)
• Experiment config path can be redirected using the experimentConfigPath parameter
  • Default (empty string) value works as intended (directs to data-files/experimentconfig.Any)
• User config path can be redirected using the userConfigPath parameter
  • Default (empty string) value works as intended (directs to data-files/userconfig.Any)
• Full screen mode can be toggled using the fullscreen parameter
  • When not in full screen mode the windowSize parameter can be used to correctly resize the window
• waypointEditorMode flag works as intended
  • Enables additional waypoint editor window
  • Enabled additional waypoint editing features:
  • Drop waypoints with button/hot key
  • Edit/view waypoint lists

[bboudaoud-nv]

Another suggested test was the idea just barely leading/lagging a target (say by 1 frame of translation) and testing hit/miss conditions to ensure hit detection is performed synchronously to what is displayed to the user.

[jspjutNV]

Instead of moving this to each new release, I'm just going to leave this Issue open in case someone wants to discuss types of new test cases that should be added.