This time I focussed a lot on contract testing which I don’t really see benefit of when you use OpenAPI spec correctly
“FSF Announces Librephone Project,” n.d. https://www.fsf.org/news/librephone-project
FSF will put efforts to replace proprietary code in currwnt OpenSource android diatributions. Thats really good news since Android and Apple devices took the whole market of phones.
I would love to have a phone without any Google code which is not opwn source. Especially after their recent commitements to replace search with AI slop.
I would love to have a phone without any Google code which is not opwn source. Especially after their recent commitements to replace search with AI slop.
“Measuring Cache Performance + Perf,” n.d. https://josephmuia.ca/2018-09-04-measuring-cache-performance-perf/#l1-cache
Blog post which covers how to use perf tool to measure cache misses. It’s interesting to see how theory of how it should work get visible in graphs.
“7 Best Practices for End-to-End (E2E) Testing,” n.d. https://www.ibm.com/think/insights/end-to-end-testing-best-practices
IBM blog post on best practices regarding E2E testing. Good quote: The more team members that can be at least tangentially involved, the better for the overall health of the testing process.
“The Practical Test Pyramid,” n.d. https://martinfowler.com/articles/practical-test-pyramid.html
Quotes:
"Repetitive is boring, boring leads to mistakes and makes you look for a different job by the end of the week."
"Write integration tests for all pieces of code where you either serialize or deserialize data. This happens more often than you might think. Think about:"
"If there’s no way to run a third-party service locally you should opt for running a dedicated test instance and point at this test instance when running your integration tests."
On Pact testing: "The more recent buzz around microservices focuses on exactly that."
"Repetitive is boring, boring leads to mistakes and makes you look for a different job by the end of the week."
"Write integration tests for all pieces of code where you either serialize or deserialize data. This happens more often than you might think. Think about:"
"If there’s no way to run a third-party service locally you should opt for running a dedicated test instance and point at this test instance when running your integration tests."
On Pact testing: "The more recent buzz around microservices focuses on exactly that."
“…But I Use Swagger/OpenAPI?,” n.d. https://docs.pact.io/faq/convinceme#but-i-use-swaggeropenapi
The company I work for recently started to promote the idea of Pact testing as a solution to compatibility changes between APIs.
This made me invest some time in reading about what Pact testing is and what all this buzz is about.
The more I read about it, the more apparent it becomes that Pact testing seems to contradict the YAGNI and DRY principles. First of all, it duplicates unit tests with mocked code and breaks YAGNI by shifting responsibility from one team to another, even though they might not need such integration.
For me, the biggest issue with Pact testing is its claim regarding the OpenAPI specification. I believe what is written on their website shows that they don’t use the OpenAPI specification correctly. If you generate clients and servers from the OpenAPI specification, Pact testing is just an overhead that will add maintenance work for your teams.
The beauty of OpenAPI lies not only in the straightforward definition of your API but also in all the tooling surrounding it.
There is literally one requirement you need to follow to make your teams’ collaboration with OpenAPI specifications production-ready and bulletproof. Ready?
Just generate your clients with OpenAPI specifications that match the version your API providers run in production.
Is it time-consuming to update your client APIs when they publish a new version? Yes. Will it prevent you from deploying incompatible APIs that break things? Yes. Do you need another layer of abstraction over your test pyramid that adds even more mundane work for your teams with Pact testing? In my opinion, no.
This made me invest some time in reading about what Pact testing is and what all this buzz is about.
The more I read about it, the more apparent it becomes that Pact testing seems to contradict the YAGNI and DRY principles. First of all, it duplicates unit tests with mocked code and breaks YAGNI by shifting responsibility from one team to another, even though they might not need such integration.
For me, the biggest issue with Pact testing is its claim regarding the OpenAPI specification. I believe what is written on their website shows that they don’t use the OpenAPI specification correctly. If you generate clients and servers from the OpenAPI specification, Pact testing is just an overhead that will add maintenance work for your teams.
The beauty of OpenAPI lies not only in the straightforward definition of your API but also in all the tooling surrounding it.
There is literally one requirement you need to follow to make your teams’ collaboration with OpenAPI specifications production-ready and bulletproof. Ready?
Just generate your clients with OpenAPI specifications that match the version your API providers run in production.
Is it time-consuming to update your client APIs when they publish a new version? Yes. Will it prevent you from deploying incompatible APIs that break things? Yes. Do you need another layer of abstraction over your test pyramid that adds even more mundane work for your teams with Pact testing? In my opinion, no.