<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ci on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/ci/</link><description>Recent content in Ci on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 22 Aug 2026 06:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/ci/index.xml" rel="self" type="application/rss+xml"/><item><title>Why our CLI does everything the GUI does</title><link>https://www.visorcraft.com/news/2026/08/why-our-cli-does-everything-the-gui-does/</link><pubDate>Sat, 22 Aug 2026 06:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/why-our-cli-does-everything-the-gui-does/</guid><description>&lt;p&gt;Every team that ships a desktop app eventually learns that the GUI is the worst possible place to test the product, because a Qt window needs a display server, a compositor, a font stack, and a small miracle to run in CI, and the test that clicks a button headlessly is the test that flakes at 2 AM the night before a release. The way out is not a better GUI-testing framework but a rule about where features live: the feature lands in a shared core library, the GUI is one consumer of that library, and the CLI is the other, and once the rule actually holds, the &amp;ldquo;how do we test the app&amp;rdquo; problem collapses into &amp;ldquo;test a library and a command,&amp;rdquo; both of which a CI runner does in its sleep.&lt;/p&gt;</description></item></channel></rss>