Webless

[matthewmcgarvey]

New Webless Driver

Purpose

This is a new driver. The special thing about this new driver is that it doesn't use selenium or talk to a different process. There's no GUI, and it doesn't apply any CSS or run JS. You might ask yourself, "Why would I want that?" Well the answer is quite simple... the benefit you get is speed 🚀. In developing this, I had access to a suite of just over 100 specs and the majority were flow specs. Running the suite with headless chrome as the default driver results in the suite finishing in 63 seconds. With this new driver used for all specs that could be switched it brought the suite down to 23 seconds. That's a savings of 40 seconds, or 63% faster!! If you can completely avoid using the selenium drivers you should see even better spec times.

Implementation

If you come from Ruby on Rails, you should be very familiar with the inspiration for this driver. Capybara is the LuckyFlow of Rails apps and it has multiple drivers as well. It has headless-chrome if you need to run tests that use JS, but if you don't you can use the rack-test driver. It runs the Rails app in memory and passes requests directly to it and parses the resulting HTML. Well, that's exactly the setup with this driver. I'm calling it the "webless" driver because I wrote the webless shard specifically to be our own version of rack-test and the name encapsulates it's purpose - testing web apps without the "web" part.

For HTML parsing and interaction, the rack-test driver in Capybara uses nokogiri. For our implementation, I am using crystal-html5.

Tradeoffs

I mentioned tradeoffs above, but I will elaborate more here.

Flows using this driver lose the ability to:

• Validate CSS properties applied to HTML elements (did the CSS hide the element?)
• Engage with and validate javascript
• Handle (accept/dismiss) alerts
• Take screenshots
• View the UI
• Interact with the window
• Hover over elements

Flows using this driver gain:

• Huge speed boost
• Less flaky specs (no javascript, css, or browser lag)

Risks

There is something to point out other than the tradeoffs, both to users of the library, and maintainers. Because this is basically implementing a "browser" that you can't see but can interact with, there's plenty of opportunities for this to work incorrectly, in unexpected ways, or to be missing expected functionality. I had a suite of dozens of flow specs and was able to find many little bugs as I went and tried to add specs to LuckyFlow in order to avoid regressions, but there is surely functionality that I did not use in my specs that other people might be. What I'm trying to say is, I expect many bug reports and feature requests on this driver for a while as people start trying it out. That's important to keep in mind.