Scott has been writing a lot of automated tests at a bigger company than he's used to, mostly end-to-end and integration tests in Playwright (with past lives in Cypress and Selenium). His recurring theme: getting started takes three to four times the normal effort, especially on a product with heavy third-party permissions and multiple interacting applications where users may not have access to both. Playwright lowers the entry barrier, but rigorous permission-based flows are still intricate to set up.

Matt's counterpoint: the test harness matters more than the tool. Invest upfront in structure that makes flaky tests hard to write — e.g. preventing async operations from leaking between unit tests (a trick a former coworker used by tracking promises). Once the harness is solid, you can copy-paste-and-tweak tests quickly. He describes his own CLI's fixture-based end-to-end suite: run a command against a folder, assert the result against an expected schema.

Scott's team enforces page object models (POMs, or "palms") — a class per page with private methods to locate elements and public methods to drive reusable actions. He's not sold: it adds a layer of indirection, and when two people build POMs in parallel they clash and drift into abstract methods that just re-wrap Playwright.

Scott's crusade: smoke tests should gate code in the PR, not just run against staging after merge. He wrote ~200 smoke tests covering every page (including invalid routes) and hit friction from colleagues who argued "the end-to-end tests will catch it." His rebuttal: the e2e suite runs against staging, so a broken PR sits in master until an on-call engineer has to hunt it down and revert — killing a day's deploy. Smoke tests are cheap, fast, and fail loud before that happens.

Dillon's framing lands cleanly: every end-to-end test is a smoke test, but a smoke test is the lightweight version — a quick "is the page rendering, no crashes" check. Bigger e2e tests cost more to run and, per Dillon, flakiness scales with scope: the eight-minute single mega-test that fails in a new place every time you fix it. Keep flows small, parallelize, and balance value against breakage.

Scott's team considered editing a GraphQL query to bypass the real flow just to make a permission-heavy test easier to write. Matt flags this hard: don't build implementation pathways that exist only for tests. You diverge the test path from the user path, then catch a sev later and wonder why the test didn't fire — because it was testing something else entirely. Related: drift between spec and implementation (real-time updating dropped for a refresh button mid-project) is what QA ends up flagging, and unit tests, not e2e, are usually the right tool for those small correctness nitpicks.