WireMock VS orchid-orm-benchmarks

This article reveals how to integrate WireMock into Fastify with ease, enabling developers to effortlessly generate mock responses for external services. Join us as we explore the straightforward process of seamlessly integrating and optimizing Fastify applications using WireMock for enhanced testing capabilities.

https://github.com/wiremock/wiremock is one such tool.

Check out https://wiremock.org/

Me and my company use WireMock a lot, it's nice tool but didn't find any nice ways to integrate with PHPUnit. What is WireMock you may ask - it's tool for mocking http requests/responses, like 3-rd apis https://wiremock.org. Wanted to use our tool which was under private repository in other projects I work in, so decided to release our own in-house WireMock integration with PHPUnit as library so it can be used by other people - https://packagist.org/packages/cobiro/wiremock, features are pretty simple:

A nightmare indeed! Try wiremock

Yes I agree, mocking is a bit of an overloaded term, and the libraries we used for stubbing like gRPC Mock and WireMock also have `mock` in their name, even though they are real servers with stubbing

Here are my tests for an example project. The logic is quite straightforward: create db records, make a request, check the response, and if it was a mutating request check how it affected the database.

And if you like to see a random example project here is mine, but my point is that a random project won't really help because each project has a unique set of frameworks/libs/practices and it changes almost everything.

Or you can clone this examples repo and play with the Blog API code.

I have an example app, and have written documentation based on it, and I'd appreciate it if you could look and give some feedback. Yes, the doc is about ORM, but imagine the ORM is just an implementation detail and instead look at how validations, controllers, repos, and especially tests are done. Source code, and long boring tutorial about it. Really, check the tests here, they are special. It doesn't have "service" because the app is too simple, but I usually have a service layer as a files with exported functions. Error handling is in app.ts.

I keep all routes in a separate file: routes.ts, in case of multiple API versions it could be "routes.v1.ts", "routes.v2.ts" and so on. v1 and v2 can reuse the same controllers.

I wrote some tests for sample app as well, maybe could be interesting for you to check it out: here, criticism is welcome, just as I like to criticize