8
The TDD cycle is more a development cycle for a developer, to quote James Shore, The Art of Agile, Test-Driven Development chapter:
Programmers new to TDD are often surprised at how small each increment
can be. Although you might think that only beginners need to work in
small steps, my experience is the reverse: the more TDD experience you
have, the ...
answered May 22 '16 at 19:18
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
8
The key difference is that the screenplay pattern organizes the Page Objects
The Screen Play pattern tries to address the issues, challenges and solutions that you will eventually encounter and address when developing most UI acceptance test automation, including when you would introduce the Page Object pattern and then face challenges using it due to the ...
6
At the UK Selenium Conference, there was a presentation on the Screen Play pattern, see The Screenplay Pattern - a SOLID alternative to Page Objects | Antony Marcano
We have a huge technology ecosystem (60+ apps) and base everything on the Page Object model. We tried the Screen Play pattern and learned many things about it and where it is more and less ...
5
Although the main purpose of BDD is to enhance conversation between people involved in a project is can be used to described any level of test.
Besides UAT, one can describe an object behavior (unit test) using Given-When-Then:
Given I create a Cache object created with the arguments "..."
When "15" seconds passed
Then the cache is empty
The point of ...
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
I would recommend doing both approaches, for different purposes.
Given / When / Then is good for testing communication. This format brings assurance that what you are testing is what the business owner / requirements writer intended. The bugs mainly caught by these tests, IME, are ones where the business owner intended X and the dev did Y. Often, these ...
4
Specflow and Fitnesse approach the process of testing in two different ways. The process of passing different inputs into your tests is very much a way of exploring the functionality of what the system can do. BDD however is all about defining scenarios that define exactly what the system should do.
As a result, I would suggest the execution pattern for ...
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
I'd plan it this way:
The specific tests that are written 'before the code' are unit tests that are written by developers just before they write the actual code.
It should only take 5-20 minutes to write a simple test. The test is written, the code is written for it and then the test is changed or the next test is written and then more unit level code is ...
4
It depends on lots of factors and there will be tradeoffs:
BDD does introduce few benefits, for specifics, please refer to this article on wikipeida. BDD on Wiki
Based on my personal experiences, there are a few issues you need to address before converting to BDD.
Those issues are:
BDD framework uses a high level, English like syntax. You will need to ...
4
Disclaimer up front: I do not agree with some of what is quoted below. I believe that a decent POM-framework can lead to VERY readable and maintainable tests.
Reading this page, the intent becomes clear. Per the source:
Even though Page Objects reduce code duplication and encourage reuse
across tests within a single project and a single test suite, the
...
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
I believe there is no support for multi-dimensional examples tables in Gherkin scenarios as you have described. Also keep in mind what BDD is largely for: being readable to the business. We developers have to be careful not to get too technical in the feature files ;)
That being said, I can think of a couple ways to solve this problem.
1.Write either the ...
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
This is not a complex scenario, instead, it is common in many applications. Every application in a given user journey, goes through different states and at any step application can get into an undesired state and test might be failed.
So yes, it can be represented as an acceptance test/end to end test where on failing at any step, remaining steps will be ...
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)
...
answered Sep 27 '19 at 9:28
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
4
Break it up.
Just as importantly, however, see what unit and integration tests you can make.
I see:
confirmation form validations
composition of email to a new user
triggering email for a new user
triggering of notifications to Administrator
setting email status based on event
trigger of analytics notification
All of these should have unit tests to ...
4
In Cucumber 5.7.0 the support of tags is handled in different way so that expression(infix boolean expression) can also be used in the same way.
You can pass the multiple tags like
@CucumberOptions(tags = "@smoke and @positive")
public class RunCucumberTest {}
Another way to manage the tags by JVM System Property
mvn test -Dcucumber.filter.tags="@smoke ...
4
This is an example of building a software system for the marketplace. In this case, you have many customers or users, each of which has its expectations for the system. However, someone must have identified that there is a need for the product in the marketplace. If someone did not justify the possible need or desire for the product, how did anyone fund the ...
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
In my experience, you can't sell new development processes.
The only path I've found which works is to simply start doing it: Only develop with TDD from this point forward. You'll still deliver your code on time, but it'll be more maintainable and have far fewer bugs. You'll feel much less anxiety and be proud of your work.
After a little time, management ...
3
Cel,
As always, it depends. If there's a requirement that the link contain a label then obviously the test needs to check that a label exists (whether automated or not).
Here are some of the possible things I'd consider with this scenario:
Is the code dynamically generated or static? For a static "once and done" page, the mark 1 human eyeball might be ...
3
If developers also write unit tests, then what's the point of having special testers in our team and should we replace testers with developers?
Unit testing is not the only kind of automated testing. Integration tests, performance tests, scalability tests, and fault tolerance tests are all examples of automated tests that are not unit tests and that a ...
3
Unit tests should be written by developers. Unit tests are very close to the core code and developers have intimate knowledge of how units should work. testers are usually more removed from the deep innards of the core code and they will not be ass effective writing unit tests as core developers are.
Acceptance/integration/end-to-end tests do not require ...
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 ...
answered Dec 6 '16 at 7:57
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
3
This depends who you let write them. It is not like there is a rule whom should write them.
At least the "Feature:" part of the BDD should be written by a business person as user-story format is from a business perspective. The "Scenario:" examples could be written by others:
Product Owner: In Agile teams I think this is a great candidate.
QA: BDD ...
answered May 20 '17 at 7:00
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
3
BDD is suitable for all levels of testing, Gherkin not so much. Writing unit-tests with the overhead of Gherkin (e.g. English feature files, regular expressions and functions to execute the tests) is extra work, but work that does not have the value of conversation as only developers read them.
Describing your tests from a behaviour stand-point is very good ...
answered Oct 1 '17 at 9:39
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
3
To learn TDD I suggest doing a kata everyday. Start with the String Calculator Kata and do it test-driven.
The coding dook handbook has loads more example kata's to practise and learn the following skills:
test design
refactoring safely
naming tests
driving code with tests
designing clean code
Also read Test Driven Development: By Example
answered Nov 2 '17 at 6:58
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
3
This is answer for specific OP's circumstances: beginner working alone. For a beginner working in a big team, advice would be "follow your leader". YMMV, and you are free to do whatever you want with your own time.
In general, experience in more generic tools ("clean" Selenium) is easier to transfer to other positions, easier to grow your career in the ...
Only top voted, non community-wiki answers of a minimum length are eligible
