persistent_selenium/README.md

87 lines
2.8 KiB
Markdown
Raw Normal View History

# Persistent Selenium
2012-11-26 19:10:00 +00:00
Now you can keep that precious browser window open when doing continuous integration testing.
Save seconds, and sanity, with every test re-run!
2012-11-26 16:36:43 +00:00
2012-11-26 19:11:53 +00:00
Also, the browser stays open at its last state so you can inspect it and more easily
fix your tests and/or code.
2012-11-26 16:36:43 +00:00
2012-11-26 19:10:00 +00:00
Start an instance:
2012-11-26 16:36:43 +00:00
2012-11-26 19:10:00 +00:00
``` bash
persistent_selenium [ --port 9854 ] [ --browser firefox ] [ --chrome-extensions <file.crx> ... ]
2012-11-26 19:10:00 +00:00
```
2012-11-26 16:36:43 +00:00
2012-11-26 19:10:00 +00:00
Tell Capybara to use it:
2012-11-26 16:36:43 +00:00
2012-11-26 19:10:00 +00:00
```
# features/support/env.rb
2012-11-26 16:36:43 +00:00
2012-11-26 19:10:00 +00:00
require 'persistent_selenium/driver'
Capybara.default_driver = :persistent_selenium
```
2012-11-26 16:36:43 +00:00
If you're using Cucumber, you can also install that hook:
``` bash
persistent_selenium install
```
2012-11-26 19:10:00 +00:00
Should work just the same as if you used the standard Capybara Selenium driver, except for
these two differences:
2012-11-26 16:36:43 +00:00
2013-01-25 15:21:17 +00:00
* The browser starts up first thing and sticks around, so you don't pay the startup/shutdown
penalty with each test run.
* The last page you were on before your tests passed/failed stays there, so you can inspect it
and adjust your tests.
2012-11-26 16:36:43 +00:00
2013-01-28 15:00:25 +00:00
The browser's cache is disabled, and cookies are reset before the next test runs, so you still get the state
2012-11-26 19:10:00 +00:00
cleared out before your next set of tests.
2012-11-26 16:36:43 +00:00
### .persistent_selenium
Configure everything in your app with a `.persistent_selenium` file:
``` ruby
# .persistent_selenium
PersistentSelenium.configure do |c|
c.browser = :chrome
c.chrome_extensions = %w{AngularJS-Batarang.crx}
end
```
### Chrome Extensions
If, for example, you do a lot with AngularJS and want to use [Batarang](https://chrome.google.com/webstore/detail/angularjs-batarang/ighdmehidhipcmcojjgiloacoafjmpfk?hl=en),
download the extension, put it in your project's folder somewhere, and call `persistent_selenium` with the path
to the extension:
``` bash
persistent_selenium --browser chrome --chrome-extensions AngularJS-Batarang.crx
```
## Best practice
Use it with Foreman and Guard. Start up your test suite via Guard, configure your test suite to
use persistent_selenium, and run persistent_selenium alongside it:
``` yaml
guard: guard -g wip
ps: persistent_selenium
```
It's an integral part of my [integration testing setup](http://github.com/johnbintz/bintz-integration_testing_setup).
## Under the hood
2012-11-26 16:36:43 +00:00
2013-01-28 15:00:25 +00:00
It's DRb, which mostly Just Works (tm), and has a little reshuffling of the default Capybara Selenium driver's code.
2012-11-26 16:36:43 +00:00
### When DRb doesn't Just Work (tm)
2013-01-25 15:21:17 +00:00
2013-04-09 15:29:44 +00:00
You're most likely using `all` and invoking an action on one of the nodes within, I'd wager. If you need to find a node
to perform an action on, it's best to stick with `find`, since it's less likely that node will go out of
ObjectSpace that quickly. If you need to examine the document for particular properties, and `all` seems like
the best way to do it, instead try parsing the document body with Nokogiri and using its finders.
That way, all your node searching will be done on the client end.
2013-01-25 15:21:17 +00:00