building with iframes: testing, talk video, send questions!
Last week, I gave a talk at Fintech Devcon on how to build web products using iframes.
A special thanks to those who sent me questions and feedback on my Fintech Devcon talk. In this first issue, I've got some advice on testing embedded iframe UIs. But first, some announcements and housekeeping.
Quick updates
The recording of my talk at Fintech Devcon, "iframe-able finance", is now out! You can also grab the slides or email me with questions.
I've started working on an "iframes 201" talk, with tips on handling iframe focus, activation, autofill, and styling APIs. What other topics would you want to see?
Testing iframes
Several people wrote in to ask for advice on testing embedded UIs with iframes.
Let's start with a simple setup, thinking of this like any other end-to-end UI testing:
We start a server that hosts our content (both our iframes and the sample integration pages that embed our iframes).
We start a test session with our tool of choice (Selenium, Cypress, etc.)
Our tests sometimes injects test-specific JavaScript into the page to
There are, however, usually a few issues with this:
End-to-end UI tests are flaky, time-consuming, and expensive to run. At every turn, you have trade-offs between realism and reliability or cost. Often, you end up with multiple tests just turned off because they take too long or fail often enough that they slow down development too much.
To test things inside the frames, you have to manually use DOM APIs to find the right frame, grab its
contentWindow, etc. And if you're using bare browser APIs, you won't be able to do this across different origins. (You do test with the inner and outer pages on different origins, right?) Most test tools have a way to turn off the cross-origin controls so you can test iframes, but then that turns them off for your real code, too. So now your tests might pass with cross-origin controls off and the code breaks for real when they're on.Your test code is hard to write because chunks of it get injected as raw strings into the browser session, so you have to write browser-executable JavaScript instead of using your compiler/bundler toolchain and having access to TypeScript or other goodies.
I've been writing and testing browser UIs for fifteen years. In all that time, people have been promising that some new tool will make these things better. I've gone through Selenium, Karma, and Cypress; headless, on-prem, and cloud-hosted browser sessions; various vendors for cloud sessions; and just about every other variation. The switch from Selenium to Cypress made things slightly better, but otherwise I got burned out on the promise of new tooling.
I mentally filed browser e2e testing as just necessarily flaky, difficult, and not going to get better. I gave up.
Then a weird thing happened.
I started hearing about Playwright. And not just from random people, but from people I trust, who build complex SPAs or widely-used third-party JavaScript libraries, and who are picky in what they recommend.
It makes working with iframes easy, with helpers for finding out when frames load or navigate and support for injecting code into frames programmatically, while leaving the browser's cross-origin controls on.
It works with your tooling so you can write tests in TypeScript or some other dialect and have them transpired at the correct time before being run in the browser.
It lets you test against realistic Safari and Mobile Safari versions, which has always been hard to set up with other tools.
Now, no tool will solve the problem of needing to think clearly about end-to-end tests. You have to write them correctly, check they don't have timing flakiness, and ensure they won't break as you change the code.
But if you know how to write good tests, Playwright will keep up its end of the bargain and run them with fewer operational problems.
Overall, I highly recommend it.
Until next time
Best,
Adam