<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Testing on Sohil Ladhani Blog</title><link>https://sohilladhani.com/blog/tags/testing/</link><description>Recent content in Testing on Sohil Ladhani Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 26 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://sohilladhani.com/blog/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>Testing Eventually Consistent Systems: When Assertions Need Patience</title><link>https://sohilladhani.com/blog/post/2026-03-26-testing-eventually-consistent-systems/</link><pubDate>Thu, 26 Mar 2026 00:00:00 +0000</pubDate><guid>https://sohilladhani.com/blog/post/2026-03-26-testing-eventually-consistent-systems/</guid><description>Write to primary. Read from replica. Assert. Fails intermittently. The classic flaky test in distributed systems. It&amp;rsquo;s not a bug in your code. It&amp;rsquo;s a bug in your test: you&amp;rsquo;re testing an eventually consistent system with strong-consistency assertions.
This confused me for longer than I&amp;rsquo;d like to admit.
The Polling Pattern The simplest fix: poll until the assertion passes or a timeout expires.
@Test void userUpdateEventuallyPropagates() { // Write to primary userService.</description></item><item><title>Contract Testing: Verifying Service Interactions Without E2E Tests</title><link>https://sohilladhani.com/blog/post/2026-03-25-contract-testing-in-microservices/</link><pubDate>Wed, 25 Mar 2026 00:00:00 +0000</pubDate><guid>https://sohilladhani.com/blog/post/2026-03-25-contract-testing-in-microservices/</guid><description>Service A returns a user object. Service B expects that object to have a name field. Team A renames it to fullName. Their tests pass. Team B&amp;rsquo;s tests pass (they mock Service A&amp;rsquo;s response). In production, Service B crashes with a null pointer because name doesn&amp;rsquo;t exist anymore.
End-to-end tests should catch this, right? Maybe, if they&amp;rsquo;re up to date, if they cover this path, if they run in a shared environment.</description></item><item><title>Chaos Engineering: Breaking Things on Purpose</title><link>https://sohilladhani.com/blog/post/2026-03-24-chaos-engineering-and-fault-injection/</link><pubDate>Tue, 24 Mar 2026 00:00:00 +0000</pubDate><guid>https://sohilladhani.com/blog/post/2026-03-24-chaos-engineering-and-fault-injection/</guid><description>All tests pass. 100% of health checks green. Monitoring looks beautiful. Then a single Redis node goes down, and your checkout flow returns 500s for 20 minutes. Your circuit breaker was configured but never actually triggered in production. It had a bug. You never knew because you never broke Redis on purpose.
Chaos engineering is the practice of deliberately injecting failures to find these gaps before your users do.
The Steady-State Hypothesis Before breaking anything, define what &amp;ldquo;normal&amp;rdquo; looks like.</description></item></channel></rss>