Right now the Zetawar tests are primarily organized around features. A typical test creates a game DB from a starter scenario and then executes transactions against the DB to get it into the desired state. While this accomplishes the goal of testing the relevant functionality, it makes the tests hard to follow since you have to mentally simulate the transactions to understand the game state being tested. I think a better way to organize the tests would be around larger example scenarios described by a combination of a starter scenario and a game state state data structure. Devcards could be used to visualize the scenarios to further reduce mental overhead. The downside of testing this way is that related functionality tests may not be grouped together. However, this seems like a relatively small price to pay for the increase in comprehensibility.
Right now the Zetawar tests are primarily organized around features. A typical test creates a game DB from a starter scenario and then executes transactions against the DB to get it into the desired state. While this accomplishes the goal of testing the relevant functionality, it makes the tests hard to follow since you have to mentally simulate the transactions to understand the game state being tested. I think a better way to organize the tests would be around larger example scenarios described by a combination of a starter scenario and a game state state data structure. Devcards could be used to visualize the scenarios to further reduce mental overhead. The downside of testing this way is that related functionality tests may not be grouped together. However, this seems like a relatively small price to pay for the increase in comprehensibility.