I am referring to John's Serenity bdd book # https://serenity-bdd.github.io/theserenitybook/latest/step-libraries.html. Very in the beginning, John seem to be enclosing a set of #given #when #then step definitions inside a method, which is annotated with a tag #Test.
#Test
public void members_should_start_with_Bronze_status() {
// GIVEN
tracy.joins_the_frequent_flyer_program();
// THEN
tracy.should_have_a_status_of(Bronze);
}
1.How would you choose the name of the method ? From the step line describing Scenario:keyword?
2.Would this be possible only when you use #RunWith(SerenityRunner.class) annotation just before declaration of StepDefinition class?
3.How about if you were using #RunWith(CucumberWithSerenity.class) instead?
What is the best place of declaring this annotation ? In the TestRunner.java file or as you have shown in side the stepdefinition class file ?
4.What is the role of serenity.properties at the root of the project Vs. TestRunner.java file ? Can we use exclusively one instead of both ?
SORRY FOR THESE MANY QUESTIONS. On behalf of JUnit-Cucumber-Serenity Test Developers,
I am saying this
"We are struggling, not having a definitive documentation".
I know it is in the nature of the beast. Because Serenity can be used in conjunction with all the above
technologies and a single, simple answer would be difficult.
BTW, I looked at the John's starter project for Serenity-junit-starter-master project(Serenity-junit-starter) which to most extent illustrates his book, I could not locate the feature file anywhere. Connecting dots between feature file and the Steps document would have given much insight.
“// GIVEN” etc are just comments; they are unrelated to Cucumber. You can run Serenity with JUnit, Cucumber or JBehave, but most of the book (currently) focuses on pure JUnit implementations.
Related
Going off the documentation here are Modules and other Geb DSL not expected to be recognized within a Spock Spec with IntelliJ? This makes using Geb with IntelliJ a bit cumbersome with no DSL reference. I noticed from this question that the asker did some custom work to get IntelliJ to wrap and notice the Geb DSL.
My questions is am I doing something wrong or is this expected and has there been any progress on getting the Geb DSL recognized by IntelliJ?
If not does anyone have a workaround for this issue/limitation and or another IDE that does recognized the Geb DSL?
IntelliJ has support for Geb DSL, I've been using it for years and there are even tests in IntelliJ's codebase that confirm it's there.
If you could share how your code looks like and what exactly does not work for you then maybe we can find a problem with your setup or expectations. It would also be good to know whether you are using community edition or professional edition.
Please note that the issue discussed in the question you linked to has been fixed by me in this PR and is no longer present since IntelliJ 2018.2.
EDIT:
After reading your comments under my response I now understand what the problem is. Your expectation is that IntelliJ will be able to figure out what the page type at runtime is and provide you with autocompletion. I'm afraid that is simply not possible - you need to track current page instance in your code for IntelliJ to be able to infer types.
Note that tests in geb-example-gradle are written in the very concise, yet dynamic style which means that IntelliJ is not able to infer types. What you need to do is to use the strongly typed style as described in the documentation. That section of the docs could do with a bit of improvement because it's not precise - I've created a Github issue to track that.
Essentially, if you tweak GebishOrgSpec from geb-example-gradle to:
class GebishOrgSpec extends GebSpec {
def "can get to the current Book of Geb"() {
when:
def homePage = to GebishOrgHomePage
and:
homePage.manualsMenu.open()
then:
homePage.manualsMenu.links[0].text().startsWith("current")
when:
homePage.manualsMenu.links[0].click()
then:
at TheBookOfGebPage
}
}
then IntelliJ will provide you with autocompletion.
What is the correct (Most effective) Cucumber Project Layout when Considerring Page Object Modelling?
After allot of research I have come up with the following design:
Maven Project
NEW PROJECT SETUP:
I agree with the main idea you present, however the page object model also refers to the utilites. One of the desired goals of the page object model is to keep the selenium code out of the test itself, so most of those references will go to the pages, then its locators and actions would access the driver class, preferably through the utilities. That does not mean that the test program cannot make direct references to the utilities, but it should do so for non-selenium reasons only. There are exceptions, of course. In the case of Cucumber or any other BDD-based framework, you would only refer to what you are now calling "main" as "steps" and each test would have its own story file, accessing the one, or more, steps files. The rest remains the same. The idea behind that is it allows you to create and maintain a library of related steps that existing and future story files can refer to.
Hope this has helped you and/or others to better understand the flow. Also, disclaimer - most of this is my opinion - there are likely many ways to diagram the relationships, but what I described is what I use.
Upon further examination, I see that I missed the lower half (I am visually impaired). The testrunner is typically at the very top of the chain in this environment. It runs as a single JUnit or TestNG test to run ALL your stories.
And now my browser is messed-up and I cannot re-scroll back up to confirm that diagram again to comment more.
I've drawn a crude layout of what I was trying to describe. I hope it explains my answer to your question more clearly.
Here's the basic project tree:
Here's src/test/java expanded:
And finally, src/test/resources expanded
The only thing in \src\main\resources is some extra stuff that JBehave uses to allow some customization of their reports, called FTL.
I am a manual tester trying to learn GEB and Spock. To learn these do I have to have prior knowledge of java or groovy? I have been reading the book of GEB, What are the prerequisites, books or learning resources? Please help. Thanks.
I tried compiling some essentials and some 'good-to-haves' that I found very helpful when I picked up Geb.
Some Groovy Magic. Most of all that you need to learn Groovy is covered in this manual but for obvious reasons if you get obsessed with the language you might want to consider Groovy in Action. While Java is not needed to pick up Groovy, If you are from a Java (except for closures) or even a Python background, you could probably skim through the tutorial for 15 minutes and you are there already).
A little Selenium. The more, the better but fear not, this single page tells you all that you need to know about the Selenium Webdriver that you would generally use. But to stress, the more the better.
jQuery selectors (everybody says that it is easy but frankly, I refer to the manual at least twice per hour. I am dumb, so…). If you are new to jQuery, you would want to start from basic selectors and click on the left navigation menu for more. Please note that not all jQuery selectors are applicable for Geb but the selectors section of Geb tutorial wasn't very exhaustive and engaging.
At the end of my testcases, I need to generate a fanciful report which stretches across multiple testcases and I had dependencies among testcases. So, I went for TestNG instead of Spock. Frankly, I didn't give Spock a lot of chance.
PageObjects is actually not a prerequisite for Geb but PageObjects are so awesome that you never wanted to think about Geb outside of it. PageObjects is a cute little pattern which says that you wrap the structure of your HTML page into an Object so that the actual test does not have to deal with it. Hah. Got you. Let me put that in plain English.
Say, you have a registration form with input textbox which has an id of "nametext". How would you get the handle of the textbox? In DOM terms, in javascript, you would just do a
document.getElementById("nametext")
In Selenium, you would do a very similar thing
driver.findElement(By.id("nametext"))
So, if you would want to populate Jason in your text box in Selenium, you would do a
driver.findElement(By.id("nametext")).sendKeys("Jason");
If you do that for all your input fields, very soon your testcases become ugly and hateful. Instead of that, in OO terms, you encapsulate. You create a new class, say RegistrationPage and wrap your findElement and sendKeys as in :
public class RegistrationPage{
…
public RegistrationPage fillRegistrationForm(String name, String email){
driver.findElement(By.id("nametext")).sendKeys(name);
driver.findElement(By.id("emailtext")).sendKeys(email);
}
}
and from your testcase, you would say
RegistrationPage regPage=new RegistrationPage();
regPage.fillRegistrationForm("Jason","jason#bourne.com");
(Even better idea is to wrap your input values into a class and pass it to the fillRegistrationForm)
In fact, Geb leverages PageObjects in a much better way - jQuery selectors to the rescue
class InputFormPage extends Page{
…
static content={
name {$("input", id:"entry_0")}
emailAddress {$("input", id:"entry_1")}
}
}
and in your testcase, you would just say
name.value ("Jason")
emailAddress.value ("jason#bourne.com")
I'm starting with Selenium and FitNesse. My goal is to create an acceptance tests suite which can be run easily in different browsers.
At first I wrote a very short wrapper around Seleniums WebDriver. The wrapper functions are used in Scenario Tables, Script Tables and Query Tables. So far, everything is fine.
My idea was to create a wiki page hierarchy called ParameterizedSuites, which has sub-suites and tests in any possible depth. Now I wanted to create one suite called FirefoxSuite defining an variable ${BROWSER} with value "firefox" and include the ParameterizedSuites only. In ParameterizedSuites.SuiteSetUp a WebDriver instance will be instantiated using ${BROWSER}.
But my idea does not work. It seems that I must include every SetUp, TearDown, Suite and Test page seperately? Is my idea completely wrong or am I missing something?
Does anybody something similar?
Hope my description is clear enough to understand the scenario.
Kind regards,
Andi
I think what you want is SymbolicLinks. You can use Symbolic Links to include a subtree of the wiki into a different place in the wiki.
For more information on SymbolicLinks, check your local users guide or the copy online: http://www.fitnesse.org/FitNesse.UserGuide.FitNesseWiki.SymbolicLinks
A common way to do this is to actually create your ParameterizedSuite and then symbolically link it into the Pages that define the configuration and supply specialized SetUp and TearDown pages. This is sort of the oposite of what you are describing, but I think what you are doing could work as well, provided you use SymbolicLinks to make the pages part of the wiki structure of your parameterized tests.
FrontPage
SuiteOne
TestOne
ConfigurationOne
SetUp
TearDown
SuiteOneSymolicLink
ConfigurationTwo
SetUp
TearDown
SuiteOneSymolicLink
In the structure above, SuiteOne can be run via the symbolic link in ConfigurationOne or ConfigurationTwo. Variables defined in the ConfigurationOne or ConfigurationTwo pages will inherit to SuiteOne when is is run via the SuiteOneSymbolicLink in each configuration hierarchy. Additionally, the SetUp and TearDown from the Confiugration Pages will be inherited as well.
Please propose some tool to verify that each public class and member has javadoc comment. I'm using IDEA to edit source, but haven't found a options to make javadoc essential.
Thank you very much.
IntelliJ IDEA can checkt it for you. You have to enable Javadoc inspections.
You can set various parameters. Like check only public classes, members and methods.
A tool such as checkstyle do exactly that, among many other checks. You can use it to produce a full report with many different checks for your codebase.
It is common to use it along with bytecode based analysis tools, such as PMD or findbugs, that are used to detect some coding errors, such as dead code, erroneous null checks, and many more.