Automated acceptance tests for terminal applications
summary
Automated acceptance tests exercise a terminal MUA called purebred by driving windows with tasty-tmux, taking periodic screenshot captures and asserting on terminal text. Tests expose timing flakiness: tmux control-sequence differences, races when sessions restart, terminal color and line-wrap variance, and fragile regex matching. Mitigations include a persistent keepalive session, running the suite in CI before merges, logging flaky failures with terminal dumps, and preferring richer parsed output over raw regexes.
AI-written summary · about
chapters (11)
- 0:00Intro
- 0:29Terminology Motivation • What is the Test Framework • Pitfalls
- 7:42ACCEPTANCE TESTING • Test whether the system/feature fullfills it's acceptance criteria • testing from the users point of view (e.g, user stories) can be any type (unit-, integration-, system tests)
- 8:48HOW IS THE TESTING CARRIED OUT? Manual vs Automated • Humans are very good at finding outliers or differences • automated is "infinitely" repeatable and fast
- 10:03ACCEPTANCE TESTING TERMINAL APPLICATIONS Selenium doesn't exist for terminal applications • support for command line interface apps, but less for text UIS
- 10:37UNIT TESTING THE TERMINAL APPLICATION UI usually straight forward for parts
- 14:47HOW DO WE USE TMUX FOR TESTING
- 29:28PREVENTATIVE MEASURES
- 30:42HAVE CI RUN ALL TESTS BEFORE MERGE
- 31:47TIME TO DEBUG FAILURES improves debugging skills of your engineers better ability to reason out a complex system
- 32:41CONFIDENCE THAT THE PULL REQUEST DOES NOT REGRESS THE APPLICATION BEHAVIOUR
