https://linen.dev logo
#general
Title
# general
n

Nicolas Homble

09/15/2023, 3:46 PM
Are there any strategies/patterns folks recommend for managing many mocks across different use cases and teams? For example, it’s getting difficult to remember what test case a mock was meant for.
t

Tom

09/15/2023, 4:01 PM
1. Create your stubs (or most of them at least) in the test cases themselves, then reset them each time. 2. Use the
metadata
element in the stub data to tag stubs with info relating them to specific test cases.
n

Nicolas Homble

09/15/2023, 5:43 PM
I’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 AM
For (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
or even
Copy code
$WIREMOCK_URL/$TEAM_ID/$PROJECT_ID
R
3) 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
4) I would also highly recommend disabling the modifying APIs after moving to configuration as code so that teams cannot break mocks of each other