Sequences of API events to store for testing

[A-UNDERSCORE-D]

See the testing card for more information

The intent here is to be read left to right, entering indents, each additional indent is a step in a sequence

Supercruise

• Normal space
• Jump systems
• Interdict a player
• Interdict an NPC
• Be interdicted by an NPC
• Be interdicted by a player
• Run discovery scanner
• Scan a body with FSS
• DSS a planet
• DSS a ring system
• Enter the SOI of a body (orbital cruise?)
• Exit the SOI of a body
• Scan low wake

Docked at stations

• Open shipyard
  • Switch ships
  • Purchase ship
  • Sell ship
• Open outfitting
  • Close outfitting
  • Open livery
  • Change ship reg
  • Change ship ID
  • Exchange a module
  • Open shared module storage
  • Sell a module
  • Store a module
• Open market
  • Buy commodities
  • Sell commodities
• Open contacts
  • Trade materials
  • Claim bounties
  • Use interstellar factor to pay fines
  • Pay fines
• Open mission list
  • Accept mission
  • Collect materials from mission
  • Deliver materials to a mission
  • Completely fill required items
  • Dont completely fill
  • Complete a mission
  • Item reward
  • Credits reward
  • Influence reward
  • Reputation reward
  • Abandon mission
  • With cargo now "stolen"
• Open resupply
  • Buy limpets
  • Resupply
• Repair

Engineers

• Unlock new engineer
• Unlock new level of upgrade
• Get invite
• Modify module

Synthesis

• Synthesize anything
  • FSD booster
  • Ammo
  • SRV repair
  • Life support recharge

Normal space

• Supercruise
• Jump systems
• Be destroyed by an NPC
  • NPC in wing
  • NPC out of wing
• Be destroyed by a player
  • In wing
  • Out of wing
• Destroy an NPC
  • NPC in a wing
  • NPC out of wing
• Destroy a player
  • In wing
  • Out of wing
• Collect items
• Normal space (planetary)
  • Enter SRV
  • Collect items
  • Be destroyed
• Scan a wake
  • High
  • Low
• Cargo scan NPC
• Scan data point
• Dock with station
• Dock with fleet carrier
• Dock with surface installation
• Tresspass around surface site

Fleet Carriers

• Create a fleet carrier
• Donate to tritium supply
• Market buy/sell

Mining

• Use prospector limpet
• Fire scanner
• Use mining laser
• Use Subsurface Drill
• Use cargo limpets
• Lower cargo scoop

[Athanasius]

Engineers, effects on materials, not to mention modules after blueprints applied/upgraded. Edit: added to sequence above

[Athanasius]

Synthesis: Affect on materials, jump range, possibly ammo (do we track that?). Edit: added to sequence above

[Athanasius]

Fleet Carriers: Donate to tritium supply, possibly other events. Edit: added to sequence above

[Athanasius]

Mining (materials and cargo in, limpets out). Edit: added to sequence above

[A-UNDERSCORE-D]

we get the info, I dont think we specifically track it though

[Athanasius]

we get the info, I dont think we specifically track it though

Out of paranoia we should ensure it's included in the inputs then, so as to ensure it doesn't affect state/outputs.

[A-UNDERSCORE-D]

Oh yeah thats very much needed, Ive been trying to figure out how best to go about it, Im sitting on just copying lines out of the file as I/we do stuff, probably using chat messages as markers

[Athanasius]

Maybe this already occurred to you.

We could have test(s) driven by changing the configured journal directory and then copying/writing to files in the custom location to simply drive all the normal data code paths. Then inspect the internal state to see if it's as expected. This should definitely work for testing monitor.py as an import from it exposes everything. I'm less sure about how well it will work for the internal plugins due to how they're loaded.

Yes, I know this isn't how tests are meant to work, but right now we need to get something hooked up so we can test any refactored code for regressions. Then we can do the refactor to have small-as-possible functions that can be tested properly.

[A-UNDERSCORE-D]

I did not consider that particular method, though we could do that. Was thinking more just replacing monitor with a mocked version to avoid having to deal with threads and such (not to mention adding the complexity of the file watcher stuff), and calling the journal event callback directly.

Both work, Im not sure what would be easier/cleaner

[Athanasius]

I might have a play with it next week latest.

Indeed it would entail an extra module for import in EDMarketConnector.py and a thread in that extra module.

I'd probably make the loading and use of it depend on a command-line argument passed in, which could also be utilised to tell the testing module which test to run.

Easiest there is for it to be the name of a directory with standard file(s) that define the testing. Whether that's one standard input filename and one standard "state should be this line by line" file or something else yet to be determined.