WireMock

Some tests are really hard to create…so we don’t, because we don’t have time. This is particularly true in heavily integrated systems - when your test depends on a bunch of external services each of those must have the right data available and respond predictably in the way you need them to. For example: → When you need a particularly large data set to be returned you’re stuck trying to figure out a way to insert hundreds of records into someone else’s database. → When you need the API to return a particular error case, and it won’t happen without you actually breaking part of the system. These tests that end up being too expensive to be worth it… unless you simulate the APIs. A key benefit of API simulation tools is that it doesn’t matter how you want that external API to respond, the effort of setting it up will be basically the same. And this means and we can focus on the testing that’s most valuable, rather than merely the easiest.

One more MCP video - this time using an agent to turn a mock API from stateless to stateful. Stateful mocking is one of the more powerful and popular features in WireMock Cloud, but it’s also one that users often find tricky. The AI handled it like a star. In the video I also explain how we use a “RAG lite” solution to “teach” the Cursor agent how to use this type of advanced WireMock functionality by pulling specific documentation into the context before doing the work. Abridged version below, will post the full version in the comments! #ai #mcp #apis

 Excited to introduce our new self-paced training for WireMock Cloud! ✅ Get up-to-date on API simulation basics 🤓 Learn how to use advanced functionality including stateful mocking, chaos features, and AI 🔜 Coming soon: Prove your WireMock skills with a certificate you can share with your professional network Sign up now, share it with your team, and come build your WireMock muscles - at your own pace. 💪💪💪 Start here → https://lnkd.in/e7K2T9KV

It’s not controversial to say that slow builds are a source of lost engineering productivity. But the build time -> lost time relationship is more complicated than it seems… Straightforwardly, you might say that a 10 minute build, run on average 6 times per day per engineer costs you an hour of wait time per engineer. But as times increase, engineer behaviour starts to change in ways that produce far less linear outcomes. If the build only takes 30 seconds to run the engineer won’t context switch while it’s happening - they’ll stay in flow, resuming the work when the build completes without missing a beat. With a 30 *minute* build, they’ll find something else to do - work on another problem, browse the web, make coffee - all of which will break their flow state and reallocate their working memory to something else. Rebuilding the mental model and re-entering that flow state (once we’ve noticed the build is finished) takes significant time. All this is to say that if you want your team to move fast, invest in faster builds. Don’t just aim for “n hours wait time saved per week”, but for those magic thresholds below which your engineers stay in flow, continuously check their work and ship in small batches.

Our CEO Uri Maoz spoke with The New Stack about APIs, microservices, MCP servers - and how WireMock Cloud is helping companies overcome challenges in integration-heavy environments. 👀 Read it here: https://lnkd.in/gfB6xkEA

There’s a certain primal joy in typing a simple prompt into an AI tool and having it generate complex code or data from nothing, but this approach often results in something that *looks* right but is full of subtle errors. Instead, we’re seeing a lot more value in combining AI agents with non-AI tools (via MCP or otherwise) to reduce the chance of the AI going rogue. Taking our recently-added API exploration capability as an example ↘️ What we’re trying to achieve: go from API sandbox + initial info → mock API + OpenAPI description. 🤖 The ‘pure AI’ way of doing this (which we didn’t use): Point an AI agent (with an MCP tool for making HTTP requests) at the endpoint, ask it to make a load of requests and then emit an OpenAPI description based on what was returned. This will probably work around 50-70% of the time, but go wrong in weird and infuriating ways the other 30%. It may also fail outright if the OpenAPI description ends up exceeding the tool’s token limit. ⚡ What we used instead: a hybrid AI / non-AI approach: The agent drives the exploration (crawling) of the API, then uses WireMock’s existing record feature to turn the set of request/response pairs into a mock API and an OpenAPI description. 👉 There are a few advantages to this. - LLMs are good at repeatedly guessing how to call an API, refining and iterating until they succeed. - They’ll happily churn away for hours doing this while you work on something more interesting. - Success/failure when calling an API is unambiguous so it’s straightforward to select the samples we want to keep vs. throw away. - Feeding these into a deterministic conversion process is fast, highly reliable relative to an LLM’s approach and less likely to blow up due to the size of the API. The result is that we’ve saved a lot of effort while producing accurate results. It’s not as flashy as some of the vibe coding demos you see around here, but it gets the job done reliably enough that we can offer it to our enterprise customers.

Join us next week to see the latest WireMock Cloud features, live! Sign up here: https://lnkd.in/eXMYtjS3 👉 Autonomous API discovery: Point WireMock AI to an endpoint and let it crawl, record, document, and create a simulated version of that API. 👉 New CLI capabilities: Record multiple APIs simultaneously, easier pushing/pulling between your locally stored spec and your mock APIs. 👉 MCP tools: Documentation lookup, start and stop recording, and embedded http requests. See you there!

Is trunk-based development (TBD) better than branches + PRs? Not necessarily… What’s often missing from the trunk vs. PRs debate is that it’s not about what branching strategy you’re using, but how often code is integrated. When teams lack true continuous integration habits, the  “feature branch” just becomes a bunch of uncommitted changes on a developer’s laptop for weeks on end. This is objectively worse than a long-running PR that’s at least visible to other team members. The WireMock Cloud team takes continuous integration very seriously, but we still use PRs, usually set to auto-merge once all the automated checks are green. Why? - Run pre-merge builds in the CI runner rather than developer laptop - PRs are a better change document than just a list of commit messages (SOC 2 auditors like this) - Can choose not to auto-merge and request a peer review for something tricky/risky. YMMV of course. For us this offers the essential benefits of TBD (e.g., faster merges), but also lets us benefit from the tools available in platforms like GitHub.