<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>tomato blog</title><link>https://tomatool.github.io/blog/</link><description>Notes on testing services from the outside, with tomato.</description><language>en-us</language><lastBuildDate>Thu, 22 Oct 2026 23:30:00 +0200</lastBuildDate><atom:link href="https://tomatool.github.io/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Presets: Redis the way ElastiCache runs it</title><link>https://tomatool.github.io/blog/posts/presets-redis-elasticache/</link><pubDate>Thu, 22 Oct 2026 23:30:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/presets-redis-elasticache/</guid><description>A service on ElastiCache with cluster mode and TLS has one Redis client, and a plain Redis container can&amp;rsquo;t answer it. A tomato preset is a container tomato knows how to run: one line in tomato.yml, and tomato does the parts a container definition can&amp;rsquo;t, while it starts the run. The redis preset now runs a TLS cluster.</description></item><item><title>Testing what your service does when the network fails</title><link>https://tomatool.github.io/blog/posts/breaking-the-network/</link><pubDate>Thu, 22 Oct 2026 01:00:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/breaking-the-network/</guid><description>Databases fail over, caches hang, brokers restart. A test suite on localhost never sees any of it, so the timeouts, retries and fallbacks written for those moments never run until production. tomato&amp;rsquo;s network resource puts a proxy between your service and its dependencies and breaks the link on purpose, one scenario at a time.</description></item><item><title>How tomato tests a web UI</title><link>https://tomatool.github.io/blog/posts/testing-web-uis/</link><pubDate>Thu, 22 Oct 2026 00:30:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/testing-web-uis/</guid><description>tomato&amp;rsquo;s browser resource drives a real Chromium the way a person does: it finds fields and buttons by the names people read, waits for the page instead of sleeping, and starts every scenario signed out. Here is what happens on each step, from the click to the database row it wrote.</description></item><item><title>Databases in a tomato suite: migrations, resets and clean state</title><link>https://tomatool.github.io/blog/posts/databases/</link><pubDate>Wed, 21 Oct 2026 06:20:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/databases/</guid><description>tomato empties your databases before every scenario, and there is no switch to turn that off. Why that is the cure for flaky suites, how it fits with migrations, how to keep a table when you must, and how it works for Postgres, ScyllaDB, Redis and the databases tomato has no resource for.</description></item><item><title>Testing a Kafka service that signs in to MSK with IAM</title><link>https://tomatool.github.io/blog/posts/testing-msk-iam/</link><pubDate>Wed, 21 Oct 2026 06:15:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/testing-msk-iam/</guid><description>A service that produces to Amazon MSK with IAM has no Kafka password: it trades a web identity token for a role session at STS and signs the handshake with it. Tests usually switch all of that off. tomato runs it: its aws resource serves STS and its kafka preset speaks AWS_MSK_IAM, so the service&amp;rsquo;s own auth code runs, and fails, the way it does on AWS.</description></item><item><title>Driving your service: HTTP, gRPC, a browser and a shell</title><link>https://tomatool.github.io/blog/posts/driving-your-service/</link><pubDate>Wed, 21 Oct 2026 06:00:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/driving-your-service/</guid><description>Clients are how a tomato scenario uses your service: through its HTTP API, its gRPC API, its web page in a real browser, or its command line. One idea, four doors.</description></item><item><title>Mocking third-party dependencies</title><link>https://tomatool.github.io/blog/posts/mocking-third-party-dependencies/</link><pubDate>Wed, 21 Oct 2026 05:30:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/mocking-third-party-dependencies/</guid><description>A stub stands in for a service you don&amp;rsquo;t run: it answers the way you tell it to, fails when you ask it to, and remembers what your service sent. How tomato&amp;rsquo;s HTTP, gRPC and WebSocket stubs work, in one picture.</description></item><item><title>Testing code that writes to object storage, whichever one you use</title><link>https://tomatool.github.io/blog/posts/testing-object-storage/</link><pubDate>Wed, 21 Oct 2026 05:00:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/testing-object-storage/</guid><description>S3, Cloudflare R2, DigitalOcean Spaces, Backblaze B2 and Google Cloud Storage all speak the S3 API. So one MinIO container can stand in for any of them in a tomato run, and the service&amp;rsquo;s code doesn&amp;rsquo;t change, only four environment variables.</description></item><item><title>Code coverage for black-box tests, in any language</title><link>https://tomatool.github.io/blog/posts/code-coverage-for-black-box-tests/</link><pubDate>Wed, 21 Oct 2026 03:00:00 +0200</pubDate><guid>https://tomatool.github.io/blog/posts/code-coverage-for-black-box-tests/</guid><description>tomato tests a service from the outside, so it cannot see the code it exercised. The service can: every mainstream language can measure a running process and write the result when it exits. How the approach works, what the number does and doesn&amp;rsquo;t tell you, and a page per language.</description></item></channel></rss>