This is a preliminary hack for a browser based Geb IDE.
Note that all of the dependencies are way out of date, since I started with a local build.gradle that I knew works in my environment.
./gradlew gebIde
(note: this has proven to be somewhat Firefox version dependent- I'm running FF 11.0, and we've had luck with other versions after that, but it may fail depending on what version of Firefox you're running. It has been suggested we look into a Firefox Portable integration to ensure that the right version is bundled with the tool)
Once Firefox loads, the Geb IDE panel should be open. Some fun commands to try:
to GrailsDocsPage
# after you're there:
header
logo
$('span')
searchToggle
searchToggle.click()
toc
tocItems
tocItems[0..3]
tocItems[0].find('a')
tocItems[0].find('a').click()
Geb is a powerful tool for writing browser based functional tests. This power comes at a cost, however- the development effort for writing and maintaining functional tests can be enormous. The most salient culprit in this regard is the delay between writing Geb code and seeing the results of executing that code in the browser. Adding to that issue is the inability to easily identify problems in the Geb code as they crop up; something as simple as a typo in a selector can result in large amounts of wasted time trying to track down what has broken. The standard functional test development/debugging process looks something like this:
- Write your Page class
- Write your test code
- Compile your project
- Run your test
- Wait for the test to spin up
- Wait for the browser to open
- Wait for the your page(s) to load
- Wait for the test to execute
- See an error in your selector/test/application code
- Fix your page object/test code/application code
- Go to 3
Depending on the nature of your project and tests, there may be additional steps as well; restarting your application, for instance. This whole process can mean that, at best, you've got a 10-15 second delay every time you want to test something as simple as whether or not you've got the right selector for a given piece of content. At worst, it could be minutes of turn around time!
The Geb IDE is an attempt to fix that. It allows you to spin up a browser with an IDE that lets you drive your Geb code (which then drives the browser :P) without any delays. You can check the value of your page content immediately, and play around with selectors and what have you without needing to wait on anything. The goal is to make it very easy to develop Page objects and evaluate Geb expressions as you write your code, with as little turn around time as possible.
The IDE in its current form is pretty rudimentary; it executes Geb expressions and highlights any DOM elements they return in the page, with the option to inspect each in Firebug. There is a lot of potential to improve upon this; not just to make it easy to test selectors, but to actually make it easier and faster to understand and iterate on your code. From a UI perspective, we're already used to having this power during development: that's exactly what things like Firebug and Chrome developer tools are for! You don't have to recompile your code and launch a new browser to just to test out a new CSS rule; you can just tweak it in Firebug until you're happy with it. Writing Geb tests shouldn't be any different.
With these goals in mind, here is a possible feature roadmap that has come about from discussions I have had with Geb developers of various levels of experience both inside and outside of my company.
- Expanded inspector for expressions that do not return page content (eg, regular groovy objects, exceptions, etc)
- View project Page and Module classes in GebIDE, with UI interactivity. Examples:
- Double click a Page to execute "to MyPage"
- Double click on a content definition to highlight it in current page
- Visual indicator whether the "at" closure returns true
- Syntax Highlighting
- Page content 'tree'* perhaps with counts/tags indicating how many matching elements are present
- Page object "Legend"
- Select each piece of Page content on the current page with color coding to visually identify all parts of the page object
- Provide insight into what a given page object actually maps to, so that developers who did not write the Page class can better understand what is being mapped where
- Classpath scanning for all Page/Module classes in the project, expose to IDE to avoid the need to import
- Need a strategy to handle name collisions
- Hot reloading of Page/Modules
- Modify source in GebIDE and recompile immediately?
- Load and run unit tests from within the GebIDE, and/or expose hooks to an external debugger
- Even just running tests externally that can use the existing browser/WebDriver from the GebIDE would speed things up tremendously, especially with the ability to pause the test and use the IDE to debug any issues
- Save 'Geb blocks' on the fly (re-runnable series of commands; basically components that might make up a test)
- Example: (block that fills out a form)
showFormButton.click() waitFor{myForm.content.displayed} myForm.content << 'some text' myForm.submitButton.click()
- Example: (block that fills out a form)