Phoenix: Test smarter, not harder

Have these thoughts crossed your mind?

“Feature tests are just too much work.” “Oh no! Converting this dead view into a live view means I’ll have to delete or rewrite all the tests.” “From a UX perspective, this should be implemented with Javascript. But then I would have to rewrite all my tests. Nah, I’ll do a full handle_event roundtrip instead.”

If so, this talk is for you! We will:

explore the current testing landscape for Phoenix compare it to other ecosystems (Ruby, Javascript, Java) discuss what could be improved (for Phoenix) give a quick intro to phoenix_test, the new kid on the block see how to test Javascript-reliant views, without having to rewrite the tests

Key Takeaways:

comparison of end to end testing alternatives: Wallaby and playwright (used by phoenix_live_view) LiveView testing is already pretty good compared to other ecosystems (batteries included to write performant and expressive tests) there’s a gap between the test API’s depending on view implementation: 1. dead views, 2. live views and 3. Javascript-reliant views when switching the view implementation, tests have to be rewritten this could be solved by writing all tests as browser based tests (Wallaby) but that’s not ideal: long execution duration (cost in CI, developer experience) phoenix_test bridges the testing gap between dead and live views a browser-based plug-and-play driver for phoenix_test (e.g. Wallaby) allows you to keep your tests when switching view implementation phoenix_test provides a descriptive API for writing feature tests

Target Audience:

Web developers (all experience levels)