How We Test a Mac File Manager
What runs before a release reaches you, in plain words.
A file manager handles your files, so a bug in it costs more than a bug in a game. No program is free of bugs, and I do not promise that for Swift Salamander. What I can do is describe the checks that catch bugs early. Below is what runs, written for Mac users, with a few technical details.
Thousands of Tests
Counted in the source on 25 October 2026, the project holds 321 browser spec files, 140 end-to-end spec files, 974 unit test files and about 4,800 Rust tests. These are tests as declared in the files. A test generated from a table or a loop runs several times, so the number of runs is higher.
A unit test checks one small piece of logic, for example how a file size is written out. A browser test opens the interface in WebKit, the engine behind Safari, and uses it the way a person does: it opens a tab and drags a file to the other pane. An end-to-end test starts the whole app inside a virtual Mac, away from my own machine, so nothing left over on my desk can make a test pass by accident.
A Fix Starts With a Failing Test
When someone reports a bug, I write a test that reproduces it before I touch the code, and I run it to see it fail. Then I change the code and run the same test again, and it passes. A test written after the fix proves little, since it may never have been able to fail. The project rulebook requires this order, and the reviewer checks it against the commit history.
One Proof for Every Push
Every push of code runs all the unit, browser and Rust tests once, in a virtual Mac. Nobody chooses which tests to run, so a change in one corner cannot break another without a test noticing. New code joins the main line only after that run is green. A test that fails once and passes on a second try counts as a failure, because flaky tests hide real problems. Retries are switched off.
The run is held to about 12 minutes. If it takes longer on two days in a row, the project files a task to speed it up. The end-to-end tests run every night, after the merge.
File Operations
Anything that copies, moves, replaces or deletes files follows one rule. At every moment, a complete copy of each affected file exists at the source, at the destination or in the Trash. The tests read the folders on disk after each operation instead of trusting what the code reported, and they interrupt operations halfway on purpose to see that nothing is lost.
Planted Bugs
Tests can be weak without anyone noticing. For the code that deletes, moves or replaces files, a mutation tester changes the code in small ways, such as flipping a comparison or removing a check, and runs the tests again. If every test still passes, no test was looking at that spot, and I write one that does. A larger sweep runs every week.
Screenshots for Visual Changes
When a release changes how the app looks, the release build starts in the virtual Mac and a screenshot is taken of each screen the release changed. A reviewer who has seen neither the work nor the code compares every picture with the same screen in the previous release. A picture that looks worse blocks the release.
How Fast a Fix Ships
A fix is one push and one proof run, so it goes out with the next release. From 17 to 23 October 2026 there were 21 releases, an average of three a day.
What the Video Shows
Nobody touches the mouse in the clip. A script plays the user: it clicks, types, presses shortcuts and drags files, and the purple dot marks its pointer. The 64 tests come from 14 spec files and repeat what people do in a file manager every day. They open and close tabs with Cmd+T and Cmd+W, split the window into four panes, press Space for a preview, collapse a section of the sidebar and switch between light and dark mode.
Every test ends in checks. A drag of 1,218 files must hand all 1,218 to the transfer, and after a move, Cmd+Z must put the file back where it was. A test passes only if every one of its checks holds, and all 64 passed. The clip was recorded without a visible browser window and slowed down so you can follow it. The slice took 2 minutes 43 seconds with the slow motion on. These browser tests run against a stand-in for the Mac's file system, which keeps them fast. The end-to-end tests use the actual file system, and the rest of the suite covers what the clip does not show.
More Articles to Come
This is the first of an occasional series about how Swift Salamander gets built, covering the tools and the decisions behind it. New articles will appear here from time to time, and there is a feed for feed readers. If a part is unclear, or you want another part of the process explained, use the feedback links in the footer.
Maciej