This adds in the concept of registering drivers and also allows different drivers to be used in a test suite. The end goal is to allow for an in-memory driver alternative to be used as the default and any that need it can be set to use headless chrome.
This is a breaking change:
Several settings were removed that were counter to this new process
LuckyFlow::Server was deleted as it didn't serve well in this model
LuckyFlow::Spec.setup must be used to correctly configure LuckyFlow for use in specs
LuckyFlow::Drivers::HeadlessChrome was deleted as it is now just a chrome driver with slightly different config
There are also bugs in the underlying Selenium library that I found when trying to run specs with headless and non-headless chrome. This are not blocking from the default path of using this library (single driver for all specs).
With the goal of allowing for an in-memory driver alternative, the next step is to remove all direct access to the underlying selenium library since the new driver won't be provided through selenium.
Fixes #132
This adds in the concept of registering drivers and also allows different drivers to be used in a test suite. The end goal is to allow for an in-memory driver alternative to be used as the default and any that need it can be set to use headless chrome.
This is a breaking change:
LuckyFlow::Serverwas deleted as it didn't serve well in this modelLuckyFlow::Spec.setupmust be used to correctly configure LuckyFlow for use in specsLuckyFlow::Drivers::HeadlessChromewas deleted as it is now just a chrome driver with slightly different configThere are also bugs in the underlying Selenium library that I found when trying to run specs with headless and non-headless chrome. This are not blocking from the default path of using this library (single driver for all specs).
With the goal of allowing for an in-memory driver alternative, the next step is to remove all direct access to the underlying selenium library since the new driver won't be provided through selenium.