All about What is GEB
If we really look at the functional testing audiences, we can see the major stakeholders top-level Management. Managers Development TeamQA Team itself Automation Team With the first development model like agile, it is always seen that the QA team takes additional responsibilities and automates few flows.
Again developers do xUnit testing to test their features. Now there is one more sub-group of QA or development named Automation Test Engineers, they do automate, flows given by QA.
With the traditional Waterfall model, it is ok to have an N number of developers, M number of Test engineers. But in the agile model, it is always good to have N+M testers.
What I mean is it is not a good idea to duplicate efforts. Rather It is best to have a common platform for developers and QA engineers to share the testing tool, language so that assets and efforts are not duplicated.
Now coming back to the test audiences, the very first level like Top level management, they hardly get
- Time to read the test code
- Go through Individual test
- Chance to dig into detailed statistics
- Latest update
Again the Second level –Managers hardly get
- Chance to look into individual test cases
- Go through the test code
They mostly want to get information about Milestone, Dates, Pending, Backlogs, Reports and a bit detailed statistics.
Next comes the developers, They always look for the tests available around them. [Mostly automated].
They try to run the automatic test code against their build and checks the hygiene of the build. Most interested to learn the test failures[When, Why, How, Which environment].
For them, tests should be unit and self-explanatory. If tests are not available they try to create XUnit tests for their feature and test.
QA Team is most likely to drill down the failed test cases after developers have delivered the feature. In most cases, QA creates test data, learns the system, tries to crack the code in different environments.
Now comes the automation team, they are here to support QA, They create tests that are reproducible. They make sure that tests run smoothly in an unattained mode in a neutral system.
For that, they try to find out the perfect tool. It can be free or licensed. They create small code that has come unique goal with setup and Teardown method. Update the test case periodically.
With so many activities going on in all these areas, We need a common system that can reduce effort duplication. Here is the answer to such issues.
GEB is a perfect browser automation tool written in the Groovy language. Due to its expressiveness and dynamic nature, test developers need to code less.
It follows Write less and get more approach. Since It is easily pluggable with a web driver, It supports the Cross Browser testing.
- InBuilt DSLs are pretty simple keywords
- Supports the box Page Object pattern
- Easy integration with Spock, JUnit or Test NG framework
- Wait for Clause for Search Pattern
- Easy Integration with Gradel or Maven like build tool
- Under laying language is Groovy so less code to develop test case.
- Since the test is built on Java and Groovy, we will have complete command of it.
- With Webdriver, it supports cross-browser Testing.
- JQuery Like APIs and supports data parameterization
- Easy Search Pattern
- Simple Four-Phase test architecture
- supports Mocking and stubbing
Browsers and Platform Supported:
- Internet Explorer.
- Phantom JS(ghost Driver)
Further visit: How To Handle Popup Issues in Selenium? – 5 Important Points
- The best solution for browsers
- Very active development
- Stable APIs
- Clean Test code
- Smaller in nature
- Easy configuration.
- No proper IDE
- Mostly trial and error method for CSS locator selector
- Need extensive debugging and evaluation of an expression.
- Mostly verbose
- Not a complete test solution.