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.

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.

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.

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

$WIREMOCK_URL/$TEAM_ID/$PROJECT_ID
R