Bdd masterclass
Download as PPTX, PDF0 likes353 views
This document discusses Behaviour Driven Development (BDD), which focuses on specifying and testing software behavior rather than implementation. It provides three key points about BDD: 1) BDD specifies examples or scenarios before implementation in collaboration with stakeholders. Automated acceptance tests are a byproduct. 2) BDD uses a feedback loop throughout the development cycle to continuously collaborate and deliver changes, unlike the traditional sequential process. 3) Common mistakes in BDD include tying scenarios too closely to implementation details rather than focusing on intent, and using ambiguous or inconsistent language in scenarios. BDD works best with declarative rather than imperative scenarios.
Bdd masterclass
- 2. WHAT Behavioural Driven Development (BDD) is a design process in software engineering where you focus on the behaviour of a feature/application. So instead of writing tests you should think of specifying behaviour. BDD is Test Driven Development done with a specific mindset; testing the intent of the system rather than testing a particular piece of code. The difference is subtle but the effects are large. BDD means examples (or scenarios) are written *before* the implementation of the software and happens iteratively, in collaboration with non-technical stakeholders Automated acceptance tests are a by-product of BDD
- 3. Traditional Requirements Analysis Design Code Test If Testing shows the requirement has not been met then the time has been lost Feedback loop takes time as code is deployed and devs wait for test results Only when code is written is it identified that it can’t meet the design
- 4. BDD (Behavioural Driven Development) Requirements Analysis Design Code Test Feedback loop is continuous and happens throughout each cycle Deliver incremental changes into production quicker for faster results Team collaboration up front removes Chinese whispers Collaborate
- 5. WHY Lets use the “5 Whys” technique to help understand why we use BDD Q1. Why would we use BDD? A1. To get a better quality product Q2. Why? A2. Because we (often) get it wrong Q3. Why? A3. Because there are misunderstandings, ambiguities or errors in what has been specified and/or what we eventually get in the form of the product Q4. Why? A4. Because the traditional methods for specifying behaviour are not always effective in capturing Q5. Why? A5. Because they fail to use concrete examples and a ubiquitous language
- 6. THE PROBLEMS WITH BDD It is NOT a silver bullet, but is often perceived as one In reality, it is about design and has nothing to do with test automation, but is often thought of as a test only activity, which means it will FAIL. It is a TEAM activity and requires a high performing, collaborative and technical one, to be a success. It does not negate the need for testing. In fact, it means exploratory testing is essential, as we should aim to capture 80% of scenarios before we develop. We are agile and accept that things change and aim to document system behaviour not tests. There can be a disconnect between the features and scenarios captured and what they become upon implementation. This is a technical problem which can be solved with good business process and there will be technology that can solve this Only one of these problems (the last one) is a REAL problem with BDD. The rest are team based problems which can be easily solved.
- 7. COMMON BDD MISTAKES The most common mistake is tying the scenarios (or acceptance criteria) too closely to the implementation. This is the difference between using Declarative and Imperative language. An Imperative example: Given I am on the log in page When I enter user name “Hamish” and password “pa55w0rd” And I click the log in button Then I will be logged in Why is this example bad? 1. It has made a number of assumptions (more likely) or prescriptions (even worse) about what the system should appear like, when really the intent or behaviour is to just validly log in It assumes or prescribes a log in page It assumes or prescribes a user name and a password field is required It assumes or prescribes a button to log in is required This dictates to technical teams how the feature should be implemented and will probably mean that when it is built the feature, step definition and page object code will all need to be refactored
- 8. COMMON BDD MISTAKES A Declarative example: Given I have logged in to the demo application with valid credentials Then I should see the demo application welcome message Why is this example better? 1. It specifies the intent or behaviour without tying it to the implementation This means that technical teams can implement this however they choose, as long as they ‘log in’ and see a welcome message -> SO TEAMS ARE FREE TO USE THEIR CREATIVITY -> TEAMS ARE HAPPIER It means if the implementation changes less refactoring is required. The feature files and step definitions are unlikely to change, however, the page object may change. For example, if we go from a user name and password required, to windows authentication with no user name and password, then this scenario is still valid, however, the previous one is not 1. It is smaller, more succinct and uses more eloquent language
- 9. COMMON BDD MISTAKES The second most common problem (I see) is writing ambiguous scenarios or ones which use inconsistent grammar A real life example: When I edit additional details like Authorised And I can update the corporate client record Then I can find the corporate client record when I search Why is this example bad? 1. The "When" steps use "I can", which imply that the user can do something rather than does do something. A "When" should be an action not an intention, which is either granular, or at a higher level. 2. The "Then” steps use "I am" or "I can". This often leads to questioning of the result or ambiguities. Using "should" means a contractual obligation and tends to lead to less questioning. It marks the sentence, or expected result, as a requirement, which of course, in agile, can of course be negotiated, but it is a starting point for discussion.
Editor's Notes
- #4: Feedback loop is too long have to code and deploy prior to finding results