This message was deleted.
# generals
Slackbot
09/15/2023, 3:46 PMThis message was deleted.
t
Tom
09/15/2023, 4:01 PM1. Create your stubs (or most of them at least) in the test cases themselves, then reset them each time.
2. Use the
metadatan
Nicolas Homble
09/15/2023, 5:43 PMI’ll check this metadata element, this might help a lot for self documentation.
For (1) I should have mentioned we are running wiremock standalone to support integration tests across our nonprod env. In this env, we don’t use the state machine feature either.
o
Oleg Nenashev
09/16/2023, 8:21 AMFor (1), I agree with Tom, but for standalone instances there are a few more best practices:
1) Use configuration-as-code and store your definitions in a repository. You can have a hierarchical structure of Mappings and Files to specify teams
2) Introduce "subprojects" by having each app/team to use
$WIREMOCK_URL/$PROJECT_ID Copy code
$WIREMOCK_URL/$TEAM_ID/$PROJECT_ID
ROleg Nenashev
09/16/2023, 8:23 AM3) Do performance monitoring for your instance, because a single shared WireMock instance can be overloaded if multiple teams do performance/stress tests. If the workload is exceeded, you can split instances or consider WireMock Cloud which is scalable
Oleg Nenashev
09/16/2023, 8:25 AM4) I would also highly recommend disabling the modifying APIs after moving to configuration as code so that teams cannot break mocks of each other
2 Views