One huge problem I've found in web testing is the speed of the tests, or rather slowness. This is compounded by the practice of setting up and tearing down the browser before and after each test so as to ensure cross-test interference is eliminated. Because of this, some people prefer to (1) leave out browser setup and teardown for every test, providing one has other evidence that cross-test interference can not happen, and (2) use virtual or headless browsers. I personally prefer to do both of the above. To test the UI as quickly as possible. Naturally, before website publication I should also like to test the UI fully too. Certainly by testing against a real browser.
What does Jonathan think of my shortcuts? In case, he's not enthusiastic: I say better fast tests than no tests at all!
I don't think anyone disagrees with: "I say better fast tests than no tests at all! "
But one problem with UI tests, as you mentioned, is there are slow. Super slow.
They are like the most expensive kind of test we can write in terms of speed.
So we don't want to write UI tests for everything. We wan to save them the the real important stuff. Like when we need to go end to end.
So what's the alternative? What kinds of less expensive tests can we write that aren't so slow? Yet still enable us to have confidence in our systems in a good way?
We spend a lot of time covering this in the book, because the question you ask is such a good one.
How do we deal with slow running UI tests.