<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Felix blog: testing</title>
    <link>https://getfelix.dev/topics/testing/</link>
    <description>Felix blog posts about testing.</description>
    <language>en</language>
    <atom:link href="https://getfelix.dev/topics/testing/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Five weeks, 562 commits: Felix from 0.5.0 to 0.6.0</title>
      <link>https://getfelix.dev/blog/felix-0-5-to-0-6.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/felix-0-5-to-0-6.html</guid>
      <pubDate>Sat, 24 Oct 2026 00:00:00 +0000</pubDate>
      <description>What we found, fixed and added between Felix 0.5.0 and 0.6.0: the bugs that shared one shape, the ways we found them, the features that apps asked for and why, and what building it taught us.</description>
    </item>
    <item>
      <title>Before you loosen the timeout, run the old commit</title>
      <link>https://getfelix.dev/blog/before-you-loosen-the-timeout.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/before-you-loosen-the-timeout.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Intermittent failures in Felix&#39;s cluster tests kept turning out to be real bugs in the broker, so before loosening a timeout I now run the test against a commit from before the suspect change; three cases show what that finds.</description>
    </item>
    <item>
      <title>Acknowledged, then forgotten: a crash under periodic fsync</title>
      <link>https://getfelix.dev/blog/acknowledged-then-forgotten.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/acknowledged-then-forgotten.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Under Felix&#39;s default periodic fsync, a crashed broker could come back missing records it had acknowledged while the cluster still counted it as caught up; this is how review and the TLA+ model found it on the follower and leader sides, and what the fix costs.</description>
    </item>
    <item>
      <title>How we catch a 1% regression</title>
      <link>https://getfelix.dev/blog/catching-a-one-percent-regression.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/catching-a-one-percent-regression.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix&#39;s rule is that a release must not be measurably slower than the one before it; this is how same-runner A/B runs, a Welch&#39;s t-test and throwaway bisect PRs in GitHub Actions find a 1-2% loss, and why a single benchmark run can&#39;t.</description>
    </item>
    <item>
      <title>Our model said everything passed. It was checking nothing.</title>
      <link>https://getfelix.dev/blog/checking-nothing.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/checking-nothing.html</guid>
      <pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix checks 107 TLA+ configurations in CI; this is about three times a passing check meant nothing, and the twin configurations, reachability checks and spec pairing we use to catch it.</description>
    </item>
  </channel>
</rss>
