2. Problems:
Software regression
No so rare issue, when after some time appears
that some feature accidently stopped working.
Manual regression tests
Before each release spend time for this, but it
actually not fully cover all cases because of
human factor.
Knowledge of project features
Without documentation there is no clear way to
find out how to do this or that.
3. Solution:
Automated behaviour tests
Check functionality often and automatically and
detect regression ahead.
Spend QA time more efficiently
Save time on manual regression. Avoid human
factor during tests.
Knowledge share
Features test cases can be used as source of
information about project functionality.
4. BDD=TDD+DDD
- Behaviour Driven Development
- Successor of TDD but with behavioral tests, inspired
by DDD
- core sense of BDD - clear conversation between
business and developer, ubiquitous language
- automating of BDD test is very second part of the
process, main purpose and goal, to eliminate
communicate problem that can be very costly
- Test Drive Development
- do tests first, after that code
- Domain Driven Design
- project domain is first, and from this point plan and
build software, use same terminology and so
5. Cucumber & Gherkin
- Cucumber is tool that were done to be able to run
automated tests in BDD style
- Gherkin is implementation of BDD’s ubiquitous language
6. Gherkin syntax
- the goal to enforce firm,
unambiguous
requirements, that will be
readable by any person
- clearly outline purpose of
feature, benefits for
involved end user
- scenarios main parts are
Given/When/Then, each
line is step
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...
7. Behat, Mink, MinkExtension
- Behat actually just transform Gherkin into PHP calls that
should be implemented by developer
- in general BDD process expects that Gherkin sentences
will be written in very clear language and not necessary
will be reused at another page, and expects that developer
later automate it if needed, main goal is clear sentences
- Mink is standalone tool, that allow control browser with
help of some drivers (selenium/goutte/etc)
- MinkExtension offer list of already transformed sentences
of Gherkin into calls that interact with browser for long list
of actions, like navigation, filling forms, etc
8. Handled by QA on their
own
- MinkExtension steps expects to work with very well-formed
HTML, but in app with modern design, Wikipedia as
example, this isn’t so simple and it’s usage will lead to low
quality and not so readable features like “I click on #row
a”, because of unfortunately not so well-formed HTML
- here help extension for Behat named Business Selector
Extension, that allow store in configuration file mapping
like “Some button: #row a”, making possible “I click on
Some button”
- with help of this QA can on their own, without developers
help, implement behavioral tests, populate this file by use
of Chrome inbuilt selectors copy functionality and use this
selectors in Business Selector Extension steps
9. Tool or framework is
just base
- this is very good, but not necessary to outline requirements
in Gherkin and follow BDD process
- Behats can be used just as acceptance testing tool to fix
software regression, reduce time for manual regression
and so
- QA can translate requirements in Gherkin, promoting more
robust flow