One major roadblock that I frequently think about with this project is the need to "playtest".
What does "playtesting" achieve? Basically, that stuff isn't broken (by trying to break it intentionally with more or less success)
We'll boot up a session and think "hey, we should check for the 205th time that Sauvagerie works properly".
Of course, we wouldn't be playing so many factory games if we didn't like automation. So you probably already know what I'm thinking:
It would be very convenient for development to establish card testing.
A few of my thoughts:
Cards and their effects should be the main focus of those tests at first;
The approach of those tests should be "given a game state before playing the card, after using the card, we expect a game state AFTER playing the card";
This implies using predefined game states. This could be in a separate mongo collection or something else;
I would also think that "unit testing" is not the right word, because I would like to make API calls to the backend instead. Not sure what you would call those tests...
The expected result would be to guarantee that all of our 58 cards work nicely, both to foster v2's release and to help later releases / even other game implementations. This is mostly applied to complex game state interactions that Héron Realms has. (Not sure this'll apply to Concept much)
Feel free to discuss this idea below.
My proposal for next steps is:
Find an elegant way to work with "temporary" test case gamestates
Get started with a few simple cards, and delegate the rest of the testing to ppl who want to learn
One major roadblock that I frequently think about with this project is the need to "playtest".
What does "playtesting" achieve? Basically, that stuff isn't broken (by trying to break it intentionally with more or less success)
We'll boot up a session and think "hey, we should check for the 205th time that Sauvagerie works properly".
Of course, we wouldn't be playing so many factory games if we didn't like automation. So you probably already know what I'm thinking:
It would be very convenient for development to establish card testing.
A few of my thoughts:
- Cards and their effects should be the main focus of those tests at first;
- The approach of those tests should be "given a game state before playing the card, after using the card, we expect a game state AFTER playing the card";
- This implies using predefined game states. This could be in a separate mongo collection or something else;
- I would also think that "unit testing" is not the right word, because I would like to make API calls to the backend instead. Not sure what you would call those tests...
The expected result would be to guarantee that all of our 58 cards work nicely, both to foster v2's release and to help later releases / even other game implementations. This is mostly applied to complex game state interactions that Héron Realms has. (Not sure this'll apply to Concept much)
Feel free to discuss this idea below.
My proposal for next steps is:
- Find an elegant way to work with "temporary" test case gamestates
- Get started with a few simple cards, and delegate the rest of the testing to ppl who want to learn
@legonzaur @Fhuris
Something interesting I found: A way to instanciate mongoDB in memory for each test.
We could imagine a setup for each card case where a prebuilt game state is given.
This would also require disabling auth for those test cases, I would assume
Something interesting I found: A way to instanciate mongoDB in memory for each test.
We could imagine a setup for each card case where a prebuilt game state is given.
This would also require disabling auth for those test cases, I would assume
https://stackoverflow.com/questions/13607732/in-memory-mongodb-for-test
Considering Mongo has ideally to be ditched some time later I assume it would be pointless to search for mongo-specific quirks and focus on the matter instead
Considering Mongo has ideally to be ditched some time later I assume it would be pointless to search for mongo-specific quirks and focus on the matter instead
Kinda reminds me of how Minecraft or Factorio Unit tests work
I think those can still be called Unit tests even if you bootup an entire runtime around it. Ultimately, it's only one behaviour that is going to be tested.
Kinda reminds me of how Minecraft or Factorio Unit tests work
I think those can still be called Unit tests even if you bootup an entire runtime around it. Ultimately, it's only one behaviour that is going to be tested.
Considering Mongo has ideally to be ditched some time later I assume it would be pointless to search for mongo-specific quirks and focus on the matter instead
right, I forgot about this. Testing in the way I described it seems pretty dependent on how we store gamestate
> Considering Mongo has ideally to be ditched some time later I assume it would be pointless to search for mongo-specific quirks and focus on the matter instead
right, I forgot about this. Testing in the way I described it seems pretty dependent on how we store gamestate
Looking at the code again, I think the main area where we want our first tests are the tokens, definetly. The other cards effects are simple additions.
Whenever we get to this, I believe this function will be the most interesting to cover and will provide the most gains:
Looking at the code again, I think the main area where we want our first tests are the tokens, definetly. The other cards effects are simple additions.
Whenever we get to this, I believe this function will be the most interesting to cover and will provide the most gains:
https://git.legonzaur.fr/heronfief/back-ts/src/commit/546909f4a6ba0a689ac16140bf23652fd2f97510/src/games/services/turn.service.ts#L322
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
One major roadblock that I frequently think about with this project is the need to "playtest".
What does "playtesting" achieve? Basically, that stuff isn't broken (by trying to break it intentionally with more or less success)
We'll boot up a session and think "hey, we should check for the 205th time that Sauvagerie works properly".
Of course, we wouldn't be playing so many factory games if we didn't like automation. So you probably already know what I'm thinking:
It would be very convenient for development to establish card testing.
A few of my thoughts:
The expected result would be to guarantee that all of our 58 cards work nicely, both to foster v2's release and to help later releases / even other game implementations. This is mostly applied to complex game state interactions that Héron Realms has. (Not sure this'll apply to Concept much)
Feel free to discuss this idea below.
My proposal for next steps is:
@legonzaur @Fhuris
Something interesting I found: A way to instanciate mongoDB in memory for each test.
We could imagine a setup for each card case where a prebuilt game state is given.
This would also require disabling auth for those test cases, I would assume
https://stackoverflow.com/questions/13607732/in-memory-mongodb-for-test
Considering Mongo has ideally to be ditched some time later I assume it would be pointless to search for mongo-specific quirks and focus on the matter instead
Kinda reminds me of how Minecraft or Factorio Unit tests work
I think those can still be called Unit tests even if you bootup an entire runtime around it. Ultimately, it's only one behaviour that is going to be tested.
right, I forgot about this. Testing in the way I described it seems pretty dependent on how we store gamestate
Looking at the code again, I think the main area where we want our first tests are the tokens, definetly. The other cards effects are simple additions.
Whenever we get to this, I believe this function will be the most interesting to cover and will provide the most gains: