Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Use speedup shortcuts?

Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!

PS: The book preface is available at the publisher's website.
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mark. Good points.

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.

Good luck! Jonathan

Good luck!
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic