sycaf-thirteen — a leaner UI test framework
a .NET UI test-automation framework built to give teams the power of a mammoth enterprise framework without the years of internal maintenance that usually comes with one.
every automation team i’ve worked with eventually builds the same thing: a framework. usually by accident. someone adds a page object pattern, someone else bolts on a retry wrapper, six months later there’s an internal library nobody fully understands, and onboarding a new tester means reading through undocumented conventions instead of writing tests.
i’ve built that framework, unofficially, more than once. sycaf-thirteen is the attempt to build it on purpose, once, and stop reinventing it per team.
the actual idea
the thing that breaks most often in ui automation is a selector, and re-running a build just to fix a css class is a waste of everyone’s afternoon — so that’s the first thing i moved out of the code entirely.
the driver was the second. selenium, playwright, or whatever shows up next, swappable without rewriting a single test — because a test should describe what a user does, not which browser automation library happens to be running underneath it that week.
actors, not page objects
tests read as sentences on purpose. that’s not a new idea — screenplay-pattern automation has existed for a while — but most implementations i’d used before were either too rigid or too undocumented to actually onboard someone onto quickly. plain nunit underneath, so nothing about running the tests is exotic, just the writing of them.
the part that took longer than the framework
a project template, so a new test project shows up with exactly the driver code you asked for and nothing else. getting that to work cleanly — no leftover conditionals for the driver you didn’t pick, no orphaned references — turned into its own small research project. ate more time than the actor pattern did, which is not what i expected going in.
where it stands
not published anywhere yet — still building against a local feed while it settles on more than one real project. the goal was never to out-build the enterprise frameworks i’ve used. it was to get most of the value without the years of accumulated internal complexity that usually comes bundled with them. still checking that box.
repo’s private for now — full breakdown’s on the project page.