6

Is it too much to ask the non-technical staff to get familiar with the basics of your repo management tools? This would have a few benefits: They could keep things simple by using branch, checkout, add, commit, push. It's a new skill for them to learn so they may be happy to get that experience. You (or other techies) could review their pull requests, and, ...


5

From The Cucumber Book: Cucumber doesn’t actually care which of these keywords you use; the choice is simply there to help you create the most readable scenario. Some people find Given, When, Then, And, and But a little verbose. There is an additional keyword you can use to start a step: * (an asterisk). So you could write: Scenario: Attempt withdrawal ...


5

@BeforeTest, @AfterTest annotations are not supported since Cucumber doesn't has the concept of test. It has features and you are executing the steps in Given, When & And, Then format. So in your case Cucumber only understands your steps not Tests. Use @BeforeFeature & @AfterFeature which was Cucumber understands the hooks. See the list of cucumber ...


4

Did you run PageFactory.initElements? The PageFactory magic won't actually parse the annotations until you do so. I usually put into the constructor a line like: PageFactory.initElements(driver, this); So that it runs when I construct the page.


4

This looks fine. BDD feature files is meant to be at a level to give useful information to product folks. In each step you can call lower level steps if you want to give more specific information (or more reusable actions) For this one for example Given I am signed in It might just call within it // enter the username GivenIEnterInTheField(string ...


4

Given is a precondition. When is a user action. Then is testable outcome. So when we keep this in mind you should choose your second option: Given I have an account for the site (precondition). When I login to the site with a valid username and password (user action). Then I should see X content (testable outcome). Hope this helps.


4

Same reason why you would split large modules in your regular code base: maintainability & navigability. Over time as your step definitions grow you will have steps that are closely related to certain parts or functionalities of your system, but not related to other steps in the step definitions. Once the file becomes large enough it will become harder ...


4

After a long hard fought battle, I was able to overcome this using opposite of what K-8 had suggested. Instead of checking if an element is visible on the viewport, I checked the negative of that, which is if element is not visible on the viewport. So, I did this public waitForSpinnerDisappear(){ let EC = protractor.ExpectedConditions; browser.wait(EC....


4

I think the pros of BDD are captured in a very good way by a user djojo in his answer - in this SO post - all credits to him I totally agree the communication is one of the biggest advantage however the benefits are for all the parties involved and the advantages for those are different. So briefly: For All: living documentation collaboration, early ...


4

The problem Cucumber addresses, is communication not architecture. These keywords are just syntactical sugar , for the business user's understanding and readability. Technically there is no difference. Having said that, the whole concept of Cucumber (BDD) is to have a common shared vocabulary(DSL) so all team members can communicate on same level including ...


4

The only way to get a List from the Gherkin input is to use datatables. To use this approach in your example you would have to re-implement the Then step, like this: ... Then following keywords are here | toto | tata | titi | With mapping step like this (notice there is no regular expression to match any keywords, just the step itself): @Then("^following ...


4

I personally divide the logic into three levels: feature file (Cucumber), step definition (Cucumber + Java), page objects (Selenium and Java). Cucumber separates business logic from the programming logic (1. and 2.) and the page object pattern separates test methods from the pages locators.


4

Katalon has an example project on github: https://github.com/katalon-studio-samples/katalon-bdd-cucumber-tests Although I find the directory structure hard to navigate the feature example does follow a pattern like: Feature file (feature code example) Steps that use test cases in pages (steps code example) Pages that implement actions (page action example) ...


3

I would store the Cucumber features files next to the code it tests in the version control system. This way your tests will reflect the "current" version even if you branch or release versions. I have build a lot of tests based on Cucumber (JVM version), personally I was very happy with it in a tester / product owner role. From a developer perspective it ...


3

If QA and DEV environments are equal (have the same dependencies installed, the same build, etc.), there is no much sense to run acceptance tests on both of them, since it will be just duplicated execution and additional overhead in terms of analysing test results on two environments instead of one. Acceptance tests are the tests which provide you ...


3

You can use the global hook at_exit: at_exit do your script goes here end For example, in features\support\env.rb I typically have: at_exit do browser.close end


3

Have you seen these? I did a search in google for: "rest testing with ruby" How to test a JSON REST API REST API test cucumber steps best practise On the other hand, if you have Ruby skills, then you can write your own library to deal with REST responses or you can use something from RubyGems.


3

The importance of any Behavior-driven development framework, methodology or tool is to communicate. Cucumber is primarily a tool to communicate requirements between the business people and the developer. Which can also function as automatable tests. Cucumbers Gherkin could also be used to create a DSL or predefined steps to let non technical testers also ...


3

QA certainly does not design anything but some tests. Design of a feature is responsibility of people who have substantially deeper knowledge about the inner workings of the system, like system analyst, system architect, database and system administrators (for their parts) and senior, most experienced designers. Then, developers design the parts they ...


3

You can achieve it using cucumber-jvm hooks. If a hook receives a Scenario as a parameter, you can know if it has failed or not. Example: @After public void afterFailedScenario(Scenario scenario) { if (scenario.isFailed()) { // Some code to execute... } } Note the import of @After: import cucumber.api.java.After; The code under an @After is ...


3

Try adding only Feature folder name in "features" instead of the full folder path. EX: @RunWith(Cucumber.class) @CucumberOptions( format = {"pretty", "html:target/Destination"}, features = "Feature", glue={"stepDefinition"}) public class TestRunner { } The above solutions may work for Cucumber version 1.2.2. In your case, if it ...


3

Use cucumber. Specflow is a part of cucumber family that is developed for .Net world. So if you do not need .Net but need Java, just use the solution that was originally intended for Java


3

You need to rework your utils.getDriver to make it producing a Singleton. You also should not invoke quit() method since it "destroys" the webdriver.


3

You can use Scenario Outlines. Scenario Outline: Insert and Verify data blah blah Given I insert <code>, <name> and <Price> into database Then I can verify that <code>,<name> and <price> has been inserted successfully Examples: | Code | Name | Price | | 001 | Product 1 | 1,00 | | 002 | Product 2 | 1,50 | | 003 |...


3

DL;DR: It's possible, but you shouldn't. All the tools you've mentioned are essentially test runners, meaning they execute a DSL focused on test code in someway. JUnit and GoogleTest execute methods according to a code-based instruction*, have class/method-level mocking support, and do reporting. On the other hand, Cucumber and Robot are focused on ...


3

Python, Ruby, Java all are very suitable for BDD. For Java + Cucumber you get a lot of support in my experience. Also, you have nice plugins like CucumberReporting I think Python should be good too. I would choose the language based on: - Toolstack your team uses (so that if you need a helping hand you can get it) - Language you are more comofortable with


2

find_elements(:name,"Like")[0].click find_elements(:name,"Like")[1].click ... button(1).click button(2).click ... ele_index(:UIAButton,1).click ele_index(:UIAButton,2).click ... buttons[0].click buttons[1].click ...


2

One way is to store these User/Pass in application property files. I am using Spring though you can check this link to see how you can read the application property. In this way, you can have and save multiple username and password for different staging environments in an external file. For example your property file (release.properties) contains: ...


2

Cucumber is your test-management tool, not? The scenario's are the test-cases for the requirement. The the cucumber book explains how you can structure your features in a logical way to use it as documentation. I suggest you combine cucumber-reporting with Jenkins to run the cucumber steps and archive the results per build.


2

Run all the tests just right after the build as soon as possible, before deploying to the test environment. Developers should have feedback about their check-ins as soon as possible. Also you say the test-env is used for manual testing, why would you want to risk deploying a non working build. Certainly if you could have run the tests first. In short the ...


Only top voted, non community-wiki answers of a minimum length are eligible