Contents:
Behavior Driven Development (BDD)
Features of BDD
BDD Tools
BDD Framework
Examples of Cucumber/SpecFlow/BDD test
Gherkin – BDD Language
The Problem
Example of Gherkin
The Conclusion
SpecFlow Feature File
Keywords for the Feature File creation
How to deliver the right software (Specification by example)Asier Barrenetxea
Talk about Specification by Example. What's the problems it tries to tackle and how to solve them.
I gave this talk at Thoughtworks on a "lunch and learn" meeting for the company.
This is a new version of my previous presentation about "Specification by example"
https://www.slideshare.net/AsierBarrenetxea1/spec-byexample-v2
Contents:
Behavior Driven Development (BDD)
Features of BDD
BDD Tools
BDD Framework
Examples of Cucumber/SpecFlow/BDD test
Gherkin – BDD Language
The Problem
Example of Gherkin
The Conclusion
SpecFlow Feature File
Keywords for the Feature File creation
How to deliver the right software (Specification by example)Asier Barrenetxea
Talk about Specification by Example. What's the problems it tries to tackle and how to solve them.
I gave this talk at Thoughtworks on a "lunch and learn" meeting for the company.
This is a new version of my previous presentation about "Specification by example"
https://www.slideshare.net/AsierBarrenetxea1/spec-byexample-v2
How to successfully grow a code review cultureNina Zakharenko
As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
Unit tests are great, they help a developer gain control over his code and catch bugs and regression issues.
Test Driven Development is a methodology that uses unit tests but it's not about writing unit tests - in fact the tests are only a design tool.
TDD is a methodology that solves problems in an iterative way, it's about emergent design that creates a maintainable solution.
In this session I'll talk about common mistakes and misconceptions, how to benefit from TDD and show how to design your code using unit tests.
The code for this talk can be found on GitHub: https://github.com/dhelper/DesignWIthTests
Did you know that LEGO can be used to popularize and teach technical concepts? Come discover the practice of TDD in a fun and creative way and relive your childhood as you learn through play! No previous experience nor technical knowledge is required.
Pascal Drouin
Jean-Philippe Bélanger
Slides from the session "TDD - That Was Easy!" presented by Fadi Stephan from Kaizenko at AgileDC2019 on September 23, 2019 in Washington DC. A blog post accompanying this talk will be published soon on kaizenko.com
Abstract:
Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?
You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.
Its a simple presentation show you new concepts of software development like waterfall, agile and scrum also in testing like test driven development "TDD"
Patterns for Collaboration: Toward Whole-Team QualityTechWell
A lot of talk goes on in agile about how collaboration among team members helps drive a shared responsibility for quality—and more. However, most teams don't do much more than just hold stand-up meetings and have programmers and testers sit together. Although these practices improve communications, they are not collaboration! Most teams simply don't understand how to collaborate. Janet Gregory and Matt Barcomb guide you through hands-on activities that illustrate collaboration patterns for programmers and testers, working together. They briefly review the acceptance test-driven development process, then illustrate what programmers should know about testing—and what testers should know about programming—to effectively create whole-team quality. Janet and Matt conclude with visual management techniques for joint quality activities and discuss the shift in the product owner role regarding release quality. Leave with new ideas about collaboration to take back to your organization and make whole-team responsibility for quality a reality.
A code review is basically a technical discussion which should lead to improvements in the code and/or sharing
knowledge in a team. As with any conversation, it should have substance and form.
What’s involved in a good code review? What kind of problems do we want to spot and address? Trisha Gee will talk
about things a reviewer may consider when looking at changes: what potential issues to look for; why certain
patterns may be harmful; and, of course, what NOT to look at.
But when it comes to commenting on someone’s work, it may be hard to find the right words to convey a useful message
without offending the authors - after all, this is something that they worked hard on. Maria Khalusova will share
some observations, thoughts and practical tricks on how to give and receive feedback without turning a code review
into a battlefield.
You want to improve your software skills. That’s a given. You may be a mentor or a manager who needs to improve the knowledge sharing among your software developers across different projects. Code Reviews can do just that while improving code quality in your projects. Code Review not only builds developer team spirit but also offers new ways to improve a software solution. You’ll walk away from this session with in-depth understanding of Code Review to strengthen your team.
Test-drevet utvikling er en hellig gral innen smidig utvikling og ofte hører man uttrykk som "TDD fører til bra design", "med TDD trenger man ikke tenke på arkitektur" og "TDD er meningen med livet" (okei, det siste der fant jeg muligens på selv). Men vil TDD automatisk føre til bra design? Eller er det noe de ikke har fortalt deg?
UXDX London 2018 Nik Crabtree - Enhancing the Processes of Test Driven Develo...UXDXConf
As the Lead Principal Software Engineer in ASOS Technology, Nik Crabtree is responsible for Software and QA Engineering, UI Engineering and Data Engineering across the organisation. His role has a simple brief: come in every day with one aim - make engineering and engineers at ASOS better.
On May 10th, Nik spoke to the UXDX London audience about test, deploy and solving problems fast! He highlights why people should adopt a test-driven-development approach.
Shared understanding, shared ownership and a test-first approach leads to high quality software, trust and high performance.
The slides for "Unconventional Influences" keynote given by Alan Richardson at Eurostar 2012, 6th November 2012 at the Amsterdam RAI
You can find more papers and conference talks by Alan Richardson at http://compendiumdev.co.uk
How to successfully grow a code review cultureNina Zakharenko
As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
Unit tests are great, they help a developer gain control over his code and catch bugs and regression issues.
Test Driven Development is a methodology that uses unit tests but it's not about writing unit tests - in fact the tests are only a design tool.
TDD is a methodology that solves problems in an iterative way, it's about emergent design that creates a maintainable solution.
In this session I'll talk about common mistakes and misconceptions, how to benefit from TDD and show how to design your code using unit tests.
The code for this talk can be found on GitHub: https://github.com/dhelper/DesignWIthTests
Did you know that LEGO can be used to popularize and teach technical concepts? Come discover the practice of TDD in a fun and creative way and relive your childhood as you learn through play! No previous experience nor technical knowledge is required.
Pascal Drouin
Jean-Philippe Bélanger
Slides from the session "TDD - That Was Easy!" presented by Fadi Stephan from Kaizenko at AgileDC2019 on September 23, 2019 in Washington DC. A blog post accompanying this talk will be published soon on kaizenko.com
Abstract:
Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?
You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.
Its a simple presentation show you new concepts of software development like waterfall, agile and scrum also in testing like test driven development "TDD"
Patterns for Collaboration: Toward Whole-Team QualityTechWell
A lot of talk goes on in agile about how collaboration among team members helps drive a shared responsibility for quality—and more. However, most teams don't do much more than just hold stand-up meetings and have programmers and testers sit together. Although these practices improve communications, they are not collaboration! Most teams simply don't understand how to collaborate. Janet Gregory and Matt Barcomb guide you through hands-on activities that illustrate collaboration patterns for programmers and testers, working together. They briefly review the acceptance test-driven development process, then illustrate what programmers should know about testing—and what testers should know about programming—to effectively create whole-team quality. Janet and Matt conclude with visual management techniques for joint quality activities and discuss the shift in the product owner role regarding release quality. Leave with new ideas about collaboration to take back to your organization and make whole-team responsibility for quality a reality.
A code review is basically a technical discussion which should lead to improvements in the code and/or sharing
knowledge in a team. As with any conversation, it should have substance and form.
What’s involved in a good code review? What kind of problems do we want to spot and address? Trisha Gee will talk
about things a reviewer may consider when looking at changes: what potential issues to look for; why certain
patterns may be harmful; and, of course, what NOT to look at.
But when it comes to commenting on someone’s work, it may be hard to find the right words to convey a useful message
without offending the authors - after all, this is something that they worked hard on. Maria Khalusova will share
some observations, thoughts and practical tricks on how to give and receive feedback without turning a code review
into a battlefield.
You want to improve your software skills. That’s a given. You may be a mentor or a manager who needs to improve the knowledge sharing among your software developers across different projects. Code Reviews can do just that while improving code quality in your projects. Code Review not only builds developer team spirit but also offers new ways to improve a software solution. You’ll walk away from this session with in-depth understanding of Code Review to strengthen your team.
Test-drevet utvikling er en hellig gral innen smidig utvikling og ofte hører man uttrykk som "TDD fører til bra design", "med TDD trenger man ikke tenke på arkitektur" og "TDD er meningen med livet" (okei, det siste der fant jeg muligens på selv). Men vil TDD automatisk føre til bra design? Eller er det noe de ikke har fortalt deg?
UXDX London 2018 Nik Crabtree - Enhancing the Processes of Test Driven Develo...UXDXConf
As the Lead Principal Software Engineer in ASOS Technology, Nik Crabtree is responsible for Software and QA Engineering, UI Engineering and Data Engineering across the organisation. His role has a simple brief: come in every day with one aim - make engineering and engineers at ASOS better.
On May 10th, Nik spoke to the UXDX London audience about test, deploy and solving problems fast! He highlights why people should adopt a test-driven-development approach.
Shared understanding, shared ownership and a test-first approach leads to high quality software, trust and high performance.
The slides for "Unconventional Influences" keynote given by Alan Richardson at Eurostar 2012, 6th November 2012 at the Amsterdam RAI
You can find more papers and conference talks by Alan Richardson at http://compendiumdev.co.uk
A Keynote presented at the May TestNet 2013. Silver Bullets are an ideal, and we should continue to strive for them, but never believe that we have finally found one.
Test Automation Day 2015 Keynote Alan Richardson - Practical Lessons Learned ...Alan Richardson
Practical Lessons Learned Automating in Testing.
Let us forget theory for a moment, and concentrate on the practice of automation. Alan will describe lessons learned from both success and failure;
as a tester, an automator, and a manager. But more importantly, you will discover how to apply these lessons and improve your automation.
Learn how to stay focused, how to experiment and still add value, how to manage even if you cannot code, and more...
Automation Abstraction Layers: Page Objects and BeyondAlan Richardson
An overview of different approaches to Page Objects and Domain Objects for GUI Automation. Examples use WebDriver and Java.
Full source code is available to download, For more details see the associated blog post.
I attended the Tabara de Testare testing group on 3rd February 2015 to present "Lessons Learned When Automating. A live stream from UK to Romania.
http://compendiumdev.co.uk/page/tabaradetestare201602
I've been asked some very challenging questions about lessons learned, and how decisions are made during the process of automating and performing technical testing. In this webinar I'm going to answer them based on my experience. We'll discus how we know 'what to automate' which means we have to split our analysis into 'detection' and 'testing'. We'll cover lessons learned from solving problems, and making mistakes, and steps we can take during the problem solving process e.g. for intermittent failures, and possible tool bugs. We'll discuss abstraction levels and the different levels of the technology stack to automate: how to do it, and how we make the decisions. We'll discuss coding primarily the differences, and the overlap, between the needs for coding for testing and coding for production deployment. We'll also cover some WebDriver specific answers to some of these questions. I'm also going to describe books and techniques that have helped me over the years when trying to deal with these questions on production projects.
Tips sukses berkarir sebagai developer dan programmer 2021DicodingEvent
Tetap kembangkan skill mu di era pandemi. Jadikan hari-harimu lebih produktif dengan asah pengetahuan dan skill di Dicoding Event. Kali ini Dicoding LIVE disponsori oleh IDCamp dengan tema "Tips Sukses Berkarir sebagai Developer dan Programmer 2021"
Developer dan programmer kini menjadi salah satu pekerjaan yang paling diminati. Jadi, tidak heran jika banyak orang yang tertarik mencoba profesi ini untuk berkarir. Sayangnya masih banyak orang berpikir bahwa bekerja menjadi developer dan programmer hanya berhubungan dengan hal-hal yang bersifat technical, padahal tidak. Banyak hal yang harus dipersiapkan dan diketahui saat ingin mulai berkarier di dunia kerja seperti tools apa yang bisa membantu produktivitas, cara berkomunikasi dengan tim, sampai problem solving masalah dalam tim. Kali ini bersama dengan Andri Suranta Ginting (Mobile Engineer, Gojek) akan kita bahas tips dari pengalaman beliau dalam berkarir sebagai developer dan programmer juga menyiapkan hal technical dan non-technical untuk dikuasai di dunia kerja.
Building a Unified Product Content Strategy | Quentin DietrichLavaConConference
In this session, you’ll learn about the challenges and victories as we worked to build a unified product content practice at an enterprise software company. We took a help documentation team, and from there grew the content practice to influence, drive, and unify content throughout the entire product ecosystem. Many times, it can be hard to know where to start. We’ll share the steps we took and the lessons learned as we reimagined our content practice.
In this session, attendee’s will learn:
Creating a product content style guide
Connecting content through the product ecosystem
Refining your product creation process
Influencing and content decisions across the organization
Working in an agile environment with few resources
At the core, the job of a software developer is and has always been the same: writing good, elegant, sustainable and bug-free software that exceeds the expectations of your clients. But the context in which we do our job is changing and with it the skills required to be a great software developer. In this talk, I want to go through a couple of things that I think make the difference between a developer and a great developer. This includes some technical skills and practices, but also non-technical things that you might not consider relevant for a developer at first.
Numbers and Limits: Balancing Data and Design in Product ManagementJeremy Horn
Slides Vasu Vadlamudi recently used in his discussion w/ mentees of The Product Mentor.
The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…Better Decisions. Better Products. Better Product People.
Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.
http://TheProductMentor.com
Architecting Solutions and Systems – Randy’s Secrets to SuccessRandy Williams
This session will provide background and guidance on how Randy has architected software solutions for the past 20+ years. This will cover a range of mostly technical topics, including infrastructure planning, trade-off considerations, performance and scalability, and separation of tiers. Expect to hear plenty of stories from real projects over his career, along with numerous tips on his secrets to success.
User Centered Design: guarantee that your business process automation project...Bonitasoft
Wide user acceptance is one of the biggest challenges companies face when launching a new project, product, or service. Any of these can fail for a variety of reasons, but failure is often due to a disappointing user experience.
The process of User Centered Design actively takes into account the needs, expectations, and characteristics of end users at each stage of the development process, leading ultimately to better user satisfaction.
The tools and processes manager of a large French automotive group recently noted, "You have to be user-centric to successfully digitize your processes." End users can feel, “This was actually designed with me in mind - my wants and needs were actually considered before a tool was imposed on me to use.”
From layout to delivery of the first iteration and through continuous improvement, learn how to use the Bonita UI Designer as an iteration tool to guarantee an ideal match with the actual needs of end users.
video: https://youtu.be/vmZgeJ86738
How to Effectively Work as a Tech Lead Tech leading is an art which turns the unique skills and talents of an engineering team into a well oiled machine. Many engineers eventually find themselves in a leadership position but without the experience to utilize it to the fullest extent. Developing tactics for how to route information and questions, use group-oriented communication style, developing delegation skills, product vision and working well with other teams can move a tech lead from good to great. During this discussion Derek Parham will talk about his lessons learned on tech leading Google Apps and provide tips to existing and future tech leads on how to play this role effectively. Speaker: Derek Parham Derek is an entrepreneur and technical leader with over twelve years of experience in software engineering. He is the founder of Google Apps for Businesses and served as its technical lead for nearly six years. He launched the project from scratch and helped grow the team to over one hundred engineers serving over 40 million customers today. The project utilized and developed some of the world’s largest scalable systems, along with shaping what is now referred to as "the cloud".
Exploring alternatives is part of the design process.
TDD is a way to do incremental design, or design while you write code.
So can we use TDD to explore design alternatives?
Turns out, I've seen a lot of design exploration during the 30+ code retreats I facilitated and attended. While I don't have a definite proof, it seems that TDD could be used for this purpose.
A developer's guide to common mistakes and pitfalls made while working with localisers. Dwayne Bailey has worked across multiple open source and proprietary projects. Worked with multiple language teams. His war stories are told, not to shame, but to help you be effective when getting your product localised.
Building a SaaS App: From Paper to Prototype to Product.Josh Rodriguez
AdStage presents Building a SaaS App: From Paper to Prototype to Product. CSU East Bay Innovation Conference, Feb. 25th, 2017. Presented by Paul Wicker and Josh Rodriguez.
Similar to Lessons learned with Bdd: a tutorial (20)
Add More Security To Your Testing and Automating - Saucecon 2021Alan Richardson
Presented at SauceCon 2021, April.
More details: https://www.eviltester.com/conference/saucecon2021_conference/
Security Testing is a highly technical set of skills, covering a wide domain of knowledge that can take a long time to learn and gain proficiency. We already have enough to learn with Software Testing and even more when we add in Automating. So are there any simple ways to increase the scope of what we already do, that provide more insight into the security of our application? Answer: Yes. And in this talk we will cover practical steps, dos and don’ts to add some Security focus fast, without spending years learning how to Hack applications.
Much of the automating we do to support testing involves detecting change. Once our tests pass, they fail when the system changes and the automated execution alerts us to the change. There are other ways that automating can help us.
Automating Tactically vs Strategically SauceCon 2020Alan Richardson
One of the biggest concepts that has made a difference to my programming and automating in recent years is the concept of “Tactical vs. Strategic.” Automating tactically might be for a specific purpose, possibly small, possibly a bit rough around the edges, not necessarily completely robust for everyone, etc. And Strategic automation is more critical to long-term aims, maintained and maintainable, etc.
In this talk, Alan Richardson will provide examples of automating both Strategically and Tactically for activities as diverse as supporting testing, marketing and general life. We will also consider how and when to move from automating tactically to strategically, and how the concept has helped me change my programming style and how to write better code.
The recording in https://eviltester.com/talks has:
- longer practice session recording
- live recording - local recording better quality
- 8 bonus recordings with an extra hour of material
- will automation take over
- impact of buzzwords
- how to cope with trends
- contextual problem solving
- information about the references
- exercises
- behind the scenes look at how the talk was prepared and tools used
- transcripts
- subtitles
DevFest 14th Dec 2019 Bishkek
- Alan Richardson
https://www.eviltester.com/conference/devfestbishkek2019_conference
- EvilTester.com
- @EvilTester
- CompendiumDev.co.uk
---
Have you ever wondered how other people test applications? Not in theory, but in practice? What thought processes are used? How did they model the application? What tools were used? How did they track the testing? That's what this talk is all about. This talk will be based on a short Case Study of testing an open source web application. Why open source? Because then there is no commercial confidentiality about the process, tools or thought processes.
---
Alan will explain his thought processes, coverage, approaches, tools used, risks identified and results found. And generalise from this into reusable models and principles that can be applied to your testing. This covers the What?, and the Why? of practical exploratory web testing.
Secrets and Mysteries of Automated Execution Keynote slidesAlan Richardson
Test Automation, Programming Automation, Automated Execution. This presentations contains some high level models, abstractions and approaches for effective, non-flakey and maintainable automation.
https://www.eviltester.com
# Automating Pragmatically
Testival Meetup 20190604
## Alan Richardson
- EvilTester.com
- @EvilTester
- compendiumdev.co.uk
- digitalonlinetactics.com
---
~~~~~~~~
Title: Automating Pragmatically
The online discussions of automating can leave me confused.
- Should you automate through the GUI?
- Should GUI automating be banned?
- Do all testers need to code? Is automating part of testing
or not?
- Do we need to automate to get a job?
In this short session Alan will discuss automating
from a pragmatic and contextual position and
share how he thinks about automating.
~~~~~~~~
Joy of Coding Conference 2019 slides - Alan RichardsonAlan Richardson
Adventures in Testing, Programming, Teaching, Automating and Marketing
When you already know how to code, it's easy to forget how hard some of that learning was... until you have to teach people. And if all you've ever built are applications, you don't know really know the nuances of writing code to automate them. And if you've written the code but never had to market the applications then you've not really experienced the full joy of coding.
In this presentation Alan will revisit many of his past projects to identify lessons learned. Lessons from: writing commercial and open source tools, multi-user adventure games, REST APIs, test automation, automating applications to make them do things they are not supposed to do, and coding for technical marketing.
Some lessons we will learn:
* The 'install' is the hardest part
* Writing frameworks is too much fun and should be banned
* Applications are just "code calling other libraries"
* Writing a Text Adventure s the most fun and educational thing you'll ever code
* The Dangers of knowing how to code
We will also learn the dangers of knowing how to code and discover how our coding skills can give us an edge, in business and online live in general, if we choose to harness our skills to improve our daily experiences.
Programming katas for Software Testers - CounterStringsAlan Richardson
What would be suitable Code Katas for people wanting to learn how to code to support their testing?
CounterStrings
- `*3*5*7*9*12*15*`
A CounterString is a string like this `*3*5*7*9*12*15*` where the `*` represent the position in the string of the number immediately proceeding it. This is a 15 character CounterString.
These are useful because if you paste them into a field, and are truncated then it is easy to see what they were truncated to, it is as James Bach describes it, self documenting test data.
https://www.eviltester.com/blog/eviltester/2019-02-27-programming-katas-for-testers/
Slides for Agile Testers Conference 2018
Technology Based Testing by Alan Richardson
What do you learn if you want to test 'beyond the acceptance criteria'? Technical risk based testing can help. In this case I'm going to use the phrase Technical Testing to cover: "identify technology based risks to drive testing". This thought process can help us make informed decisions about the scope of exploratory testing we will carry out. It also helps focus your studies on the technical knowledge appropriate for the project you are testing.
## Blurb
This requires:
- understanding of the technology
- risk identification
- tools applicable to the technology
This presentation will use a simple example to demonstrate that:
- Even simple technology can pose risk
- Combining simple technology can increase risk
- Understanding technology allows us to evaluate risk
* http://www.eviltester.com
* http://www.compendiumdev.co.uk
* https://twitter.com/eviltester
What is Shift Left Testing? Do you need to use that term to improve your Software Testing and Development process? I don't think so.
- why I don't use the term Shift Left
- Explanation of what Shift Left means when people use it
- Explanation of what Shift Left might mean when people hear it
- How to Shift Left incorrectly
- How to improve your test process without using the phrase Shift Left.
Hire me for consultancy and buy my online books and training at:
- https://compendiumdev.co.uk
- http://eviltester.com
- http://seleniumsimplified.com
- http://javafortesters.com
Have you ever wished that you had a worked example of how to test a REST API?
Not just automate the API, but how to interact with it with command line tools, and GUI tools to support your manual interactive testing. And then take your testing forward into automating the API?
That's what this book provides.
Read the 74 page sample and find out more information on the book page.
https://www.compendiumdev.co.uk/page/tracksrestapibook
The full book has over 200 pages of actual hands on case study information that can improve your testing and automating of REST API based applications.
Technical and Testing Challenges: Using the "Protect The Square" GameAlan Richardson
How good are your Technical Testing in the Browser and JavaScript skills? Put them to the test with the "Protect The Square" game.
https://www.compendiumdev.co.uk/games/buggygames/protect_the_square/protect_the_square.html
TDD - Test Driven Development - Java JUnit FizzBuzzAlan Richardson
A short example Test Driven Development session where I code FizzBuzz.
FizzBuzz is often used as a programming interview question and as a Kata for practicing your coding.
The GitHub code repository with the Java code for this exercise is available at:
https://github.com/eviltester/fizzbuzz
Read the blog post for the video:
http://blog.eviltester.com/2018/03/tdd-test-driven-development-java-junit.html
Slides for Automation Guild 2016 Conference
If you want to automate, you learn to code, and you learn to code well.
“Automate” doesn’t mean “Automate Testing” it means “Automate part of your test process”.
You need to learn to code to do that with the most options open to you.
We’ll look at some ‘we do this alot’ and ‘we want to automate’ activities which we can use tools for. But we’ll also see that we are limited by the tools.
When we code, we can do a lot with minimum code, and gain a lot more flexibility.
Then we’ll cover how to think about learning to code.
solve a problem quickly (automate tactically)
solve a problem for the long term (automate strategically)
To work strategically we need to learn:
to code well,
understand refactoring,
libraries vs frameworks,
abstractions,
etc.
This talk isn’t just for beginners, we’ll cover stuff that should make it useful for the experts in the audience.
We’ll cover a lot in 45 mins, with code examples and tool examples, and I’ll make it all pretty practical.
For more details visit:
https://www.compendiumdev.co.uk/page/tag2017
My aim here is to tell you that I learned to work with Agility rather than work with the Agile Rituals and Definitions. And I learned to trust that working with Agility trumps Rituals and Definitions the hard way. Because sticking to rituals and definitions led to rigidity, rather than agility.
And then "What does testing look like when you adopt that mindset?"
In this presentation you will short cut your learning on the topic of Agility, so you understand "What does testing look like when you adopt an Agility mindset?". Applying this mind set naturally leads to incorporating exploratory testing, technical testing, automated execution, end to end testing and risk. Adopting this mindset allows you to fit into any Agile Software Development project and create a customized testing approach that works.
Keynote at the internal Rabobank Testing Conference on Feb 15th 2018 in Utrecht.
https://www.compendiumdev.co.uk/page/rabobank201802
Your Automated Execution Does Not Have to be FlakyAlan Richardson
This webinar is for anybody who has accepted 'flaky' test automation. Alan believes that to describe and accept your test execution as flaky is merely an excuse. In this webinar he will explore the myths of flakiness, so that you never use those excuses again!
Categories of common problems with suggested solutions.
For more information visit http://eviltester.com/flaky
What is Testability vs Automatability? How to improve your Software Testing.Alan Richardson
Testability is different from Automatability.
- Testability - does the application have features that make it easier for a human to test?
- Automatizability (Automatability) - does the application have features that make it easier to control and interrogate by another application.
You will learn:
- What is Testability?
- What is automatability?
- What is automatizability?
- Adding testability features can introduce risk.
- Features that aid automated execution, can overlap with features that aid testing, but they are not the same.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
1. Lessons Learned With
BDD
Thinking and Automating with Domain
Specific Languages
Alan Richardson
@eviltester
www.compendiumdev.co.uk
www.eviltester.com
www.seleniumsimplified.com
alan@compendiumdev.co.uk
2. Scope
● Part 1 - BDD
○ BDD Opinionated Overview
○ Lessons Learned
○ Exercises for BDD with no tools
● Part 2 - BDD & Tools
○ Cucumber overview
○ FitNesse overview
○ Custom DSL Overview
● Part 3 -
○ Q&A + Summaries
Warning: pretty much everything in here can
be argued with. BDD emphasises
communication. So feel free to disagree.
4. The Brief
Lessons Learned with BDD - Thinking and Automating with Domain Specific Languages
Starting with the the tools for BDD and Acceptance Testing has become increasingly simple. To learn tools like
Cucumber and FitNesse to create tests you can now read books and articles and watch countless videos to help.
But using the tools is only part of the battle.
Over years of working with Agile teams, and using various tools to help Business Analysts collaborate with
Development staff, writing high level tests in a human readable language, I've learned that most people do not
realise that they are writing a Domain Specific Language.
Each of the tools provides a different mechanism for modeling the domain and writing the language. But
fundamentally we are creating a language unique to our domain. And if we do not recognise this, or harness this,
then we make our life harder.
So in this session I want to look at some of the BDD and Acceptance Testing tool mechanisms e.g. tables or
Gherkin, with the additional modeling perspective of a high level language that models the domain.
Business Analysts are trained in modeling domains. Testers are trained in identifying ambiguity. Developer are
trained in refactoring to domain objects. These skills exist in the development team, we just have to harness
them.
In this session we will explore what this means, and how it changes our approach to writing BDD. This session
does not require access to a computer. Tools will be demonstrated. But tests will be written on paper and
discussed by the group to explore how to use BDD tools and and languages to more effectively model the
domain.
5. Alan Richardson
● Has used BDD, ATDD, DDD using tools
such as FitNesse, Cucumber, Domain
Specific Languages
● Domains - finance, gambling,
pharmaceuticals, media
● Has done it well, and badly
● Still gets confused by other people so makes
up his own models
6. My 'BDD' Messages
● The definition of BDD changes, so you
'should' own and define it for your domain
● Tools are not the answer, but neither is
'communication'
● I think of BDD as a process of modelling
communication across multiple domains
● Modelling is a domain specific activity, use
DSLs and DDD to improve BDD
● Expect to make mistakes and receive no
external 'instant fit' answers
(but then I think of
everything as a
process)
Don't get 'Hung Up'
8. BDD relates to communication
... but I think it is the worst communicated
'thing' in Software Development at the moment
BDD, ATDD, Specification By Example, BD
Design, ... Development, 'Real Options', "for
Communication (not development)", Deliberate
Discovery, Feature Injection
9. Plenty of platitudes for what it is not
● "it isn't about testing",
● "it isn't the tool",
● "it isn't just for the development team"
● "if must involve the business"
● "it isn't about the 'how'"
● BDD isn't ATDD
● "it isn't about the automation"
● "It isn't just for the business"
And most of these are probably true, but don't
necessarily help you understand what to do.
10. There are universal platitudes of
"isness"
● It is about communication
● It is for bridging the gaps
● It brings the business and development
closer together
Again these are true, but don't help, you do it.
12. The Definition 'Problem' with
understanding 'BDD'
● 'Definition' has changed over the years
○ ..D used to be for Development
■ because of TDD gaps and flow
■ ATDD not using abstraction layers
○ now is more like Design, but is still development
13. The Tool 'Problem' with
understanding 'BDD'
● Same tools used for BDD, ATDD, Spec By
Example
○ so what is the differentiator?
● BDD is not the tool, but the tool changes the
way you do BDD
● Tools enforce a syntax which BDD does not
require
○ Gherkin e.g. Given, When, Then
○ Tables
17. Domain Specific Language
A shared understanding requires a
shared language, which we agree
over time.
The language 'should' become ubiquitous: in
verbal discussion, in written communication, in
the code, in the tests.
18. Language
● Grammar
● Syntax
● Vocabulary
A simple model:
● Vocabulary and Syntax allow automation
● Grammar unites these with domain rules
19. BDD, ATDD, etc. Nuances over time
● BDD, ATDD, Specification by Example etc. -
different ways of looking at the same
process:
○ Moving from desire to reality
○ Maintaining as many options as possible
○ Allowing us to commit late
○ Allow us to experiment
○ Building a Shared Understanding
○ Checking we are adding value
○ Checking we are building it right
○ Each 'name' attempts to expose an additional
nuance
● Not the same things at all
20. Not the same things at all but BDD is
winning, because...
● When people talk about 'this' they now say
BDD more than any other term
● BDD has changed its definition to stay on
top
● Modelling is hard, so it is easy to point at
other peoples BDD and say 'this is wrong',
then explain the principles again rather than
offer a 'right' answer
21. Principles of this 'BDD' thing
● Communication
● Ubiquitous Language
● 'should' - does it? should it? how? when?
● Declarative vs Procedural
● Concise examples illustrate, explain &
explore
● Use explanatory text
● Model multiple levels
● Living spec - review for durability
● Review for waste
23. Some possible lenses or views if I
have to use the existing terms
● DDD (inside out)
○ are we using the right language? Are we working at
the right level in the domain?
● BDD (outside in)
○ what behaviour should this thing exhibit, how do I
know?
● ATDD (what else?)
○ what else should it do? how would it handle X? how
did we get it wrong?
● Specification by Example (examples?)
○ Do we have enough examples? Too many? The
right examples? Will this make sense later? Adds
Context
● Real Options (commitment)
24. Gherkin: Given x When y Then z
A ubiquitious 'language' (DSL) for analysis, that
made communication easier to automate:
● Feature, Scenario,
● Given,
○ a particular context (preconditions)
● When,
○ a particular sequence of events happens
● Then,
○ observable outcomes
● Examples
○ A set of examples
We add the
Grammar and
Vocabulary of the
Domain around this
Syntax
25. Opinionated Summary
● I don't care what you call it.
● I don't really care how you do it.
● But if I'm involved, and I see waste or
inefficiency, then I use all the lenses to look
at how you model the domain in a DSL and
make suggestions accordingly
● Many times I see people using one lense
above others, and rarely using, or
recognising their use of, a Domain Specific
Language
27. Lessons Learned
● Don't be tool driven
● 'Agree' your domain language
● Change your language
● Building a DSL is hard
● Refine your existing models
28. Don't be tool driven
● When you start, expect to be tool driven
● Fitnesse
○ Script tables
○ Essentially keyword driven automation
○ Because the testers can't code
○ Reuse of 'chunks' of FitNesse pages
○ Refactoring nightmare
● Eventually used for
○ Database setup and comparison
○ A GUI for the data
○ But Spreadsheets would have been better (have you
ever tried to edit FitNesse tables?)
29. Why not be tool driven?
● You're not fixing your communication
problem, you're adding a distraction
● New tools won't save you
● Tool introduces a new layer of abstraction
which may not help communication
● Tool can slow down communication
● Tool might impact your options
○ may not make change easy
○ may not make options easy
30. Do 'agree' your Domain language
● We just wrote down what the BAs said
○ including all the inconsistencies
● Different nouns to mean the same entity
● Different verbs to mean the same process
(sometimes a verb, sometimes a verb
phrase)
31. Expect your domain language to
change
● Because you will discover and learn more as
you try to express and model the domain
● The Domain is not restricted to the business
○ e.g. as soon as you commit to building a web app,
the language of the web becomes part of your
domain
● Do refactor your language
○ if later you decide that 'visitor' is better than 'a user
who is not logged in' then change it - everywhere
32. Building a DSL is hard
● Many people find modelling a DSL hard
○ I didn't realise this until we had people try to do it
● I think because:
○ people are not used to analysing language
○ people are not used to building new languages
○ people don't want to share/own the language
○ people don't feel confident with the written word
○ they are overloaded 'this' is new, the tool is new,
communication is new
○ Gherkin == BDD
33. Refine your existing models
● We kept adding more stuff
● Refine your models to remain relevant and
revealing
○ move acceptance criteria into functional tests as you
generalise and expand the scenarios
■ e.g. after committing to a web app move the web
acceptance criteria from BDD into functional tests
and make the BDD more general again
○ join scenarios and given when thens into a more
generic statement - cover detail in lower level tests
● Try to keep the BDD small by reworking new
parts of the domain into the existing model
34. How to make DSL construction
easier?
● You can limit the DSL modelling options to
the Vocabulary and the Grammar if you use
Gherkin
36. What is the DSL here?
Given a registered user
When the customer logs in
Then the account holder can view their
personal details
Critique?
37. Exercise: How might it read?
5 mins, make it better
● Given a registered user
● When the customer logs in
● Then the account holder can view their
personal details
39. How might it read?
● Are the following:
○ Right or wrong?
○ Good or Bad?
○ Better or worse?
○ Does it provide 'real options'
○ Supported by examples?
40. How might it read?
● A logged in user can view their account
details
Critique?
41. How might it read?
● A logged in user can view their account
details
○ the language encapsulates the context and event
○ this may be harder to automated
42. How might it read?
● Given a logged in user,
● when they view their details,
● then they can view their details
Critique?
43. How might it read?
● Given a logged in user,
● when they view their details,
● then they can view their details
○ context encapsulates details so event written at a
different level,
○ Gherkin forces a redundant 'then'
■ does it have to be redundant?
44. How might it read?
● Given a logged in user, when the user views
their details, then the user can see account
details are correct
Critique?
45. How might it read?
● Given a logged in user, when the user views
their details, then the user can see account
details are correct
○ provides more of a 'why'
○ reveals lack of options
■ there exist other ways that a user could check
the correctness of their account details
46. Right, Wrong?
● Context and Domain specific
● Domain has to include:
○ Business Domain
○ Technical
○ Also automation domain - how much of what we said
could be automated?
47. Is login an appropriate example?
● Is login obvious enough that this is a poor
example?
● Do we need communication around login?
49. BDD does not require a tool
Do some BDD on the Tracks application.
GTD - we think it is going to come back in style.
Pretend we are going to create a new version
of the Tracks app and use BDD to help us.
50. Product Owner (me) Demo of App
Demo of Tracks:
- default admin user created during setup
- login, logout
- create & delete user
- amend details, only I can amend admin email
- create a next action on review pages: home,
project edit, tickler, starred
- projects are always personal
- CRUD actions on next action, project, context
51. Exercise: Pick a few of the areas and
'BDD' them
● Whatever format you want
● I will answer questions as the SME
● Small groups
● Debrief in 20 mins
54. Demo Scope
● cucumber-jvm added easily with maven
● feature files as resources
● run feature files from ide
● step definitions in class
● regex in annotation to find steps
○ supports params
● JUnit runner for CI and report creation
● IDE support for syntax, quick fix and code
completion
● Gherkin - loose syntax checking
● "Scenario Outline" for examples
55. Lesson Learned: Cucumber-JVM is
not BDD
● Cucumber-JVM is an implementation of
Cucumber tool
● Gherkin is a DSL
● Cucumber allows us to map Gherkin text file
statements to code so we can 'execute' a
Gherkin document
● Cucumber means we don't have to write a
parser or lexer or the reporting tools
● If we don't pull out the elements of the tool
then we can't consider options and
alternatives to help us do BDD
56. Lesson Learned: Don't add all your
code into step definitions
● Tempting to add all 'test' implementation
code into step definitions
● But you aren't modelling the 'domain' if you
do that, you are using a tool
● Build abstraction layers. Model the domains
● Creates more options for your
implementation approach
● Supports re-use of automation code across
multiple test layers
● Because "BDD is not about testing"
57. Use Multiple Abstraction Layers
● Domain
● Physical Implementation World
○ Page Objects, Page Components, Sites, etc.
● Workflows
● Feature Files
○ Step Definitions
● BDD
These help increase flexibility for changing,
restrict commitment to fewer layers
58. Lesson Learned: Multiple
Automation Levels
● Functional Testing in conjunction with BDD
helps create multiple abstraction layers
○ refactoring
○ DRY
● Choices about what to model at what level
○ e.g. don't have to do everything in 'BDD' tool
● In this demo I had existing functional tests
which flushed out the page objects prior to
the Scenario implementation
59. Lesson Learned: Refactor your
automation code
● Too easy to add new code in, or copy paste
bits between steps
● Refactor, Refactor, Refactor
● Write clean code
60. About Cucumber-JVM
● Java Implementation of Cucumber
● Available via maven so easy to add to
project
● Annotate Java code with @Given etc. allows
sharing steps between scenarios
● IDEs (IntelliJ 12) are cucumber aware so:
○ can run feature files directly and create steps
Alt+Enter
○ code completion and syntax highlighting
● JUnit runner for CI
● Uses lots of reflection to work
61. Minimal Gherkin Feature File
Feature:
Scenario:
* a statement to check
Supports non standard
modelling
e.g. non Given, When,
Then modelling
62. Typical Gherkin Feature File
Feature: short description of feature
Background: general info
about the feature
Scenario: a scenario description
Given: a given condition
When: a particular event happens
Then: we can observe that this happened
63. Lesson Learned: Use the tool
features
● Don't avoid tool features because you want
the ability to move between tools
○ e.g. cucumber @Before, @After, @tagging, etc.
● Using the tool ineffectively can force you to
move away from the tool
● You can move between tools using
abstraction layers
65. A DSL based on Tables
● Cucumber provides a Gherkin parser
● FitNesse provides a Table parser
● table name
○ a scenario
● columns
○ map on to examples
● setter Columns - add data in to fixture
● getter Columns? - pull data out of fixture
○ if no 'expected' value then these can be used for
execution documentation
66. Demo
● BDD table for login
● Code to implement fixture
○ reuses our page objects etc.
67. Pros & Cons Compared with
Cucumber-JVM
● Cons
○ Technically more painful to setup
○ May deter collaboration if users can edit on server
without pairing with dev or test
● Pros
○ Very rich documentation ability
■ but no-one ever seems to use this
○ Wiki based for collaboration with users
○ Easy to test out new examples from a server deploy
○ FitNesse seems to be receiving more love and
attention again so keep an eye on it
71. When you write your own
● Easiest to create abstraction layers that
'look' and 'act' like a DSL
● Readable code
● Supports refactoring, code completion
● Take this as far as you need to.
○ Can be as complicate or as simple as you like
73. Is it BDD when...
● Testers can write tests using the DSL
● Business can express intent using the DSL
● Moving from business intent to test can be
done collaboratively
74. Lessons Learned: Constant Reviews
● Constantly need to review the DSL code
● Patterns and understanding constantly
evolve so need to keep on top and
communicate across the team
● Review to help enforce 'good' programming
practices
75. Lessons Learned: 'Good'
Programming Practices Required
● Refactor
● Test
● DRY
● Single Responsibility
● Patterns
● Use the language well
● Leverage libraries where you can
76. Lessons Learned: Domain Objects
● Use DDD lessons and embody Domain
objects in your code
● Limit the extent of the objects to avoid
overlapping domains
79. Summary
● Don't get hung up on doing it 'right'
● You make BDD what it is, if its not working
for you, change it and fix it
● Use all the nuances: DDD, ATDD, Example,
Options, TDD to BDD
● BDD is not the tools, but the chosen tools
change your Domain and your BDD style
● Own your DSL
82. Recommended Books
● Domain Driven Design
○ by Eric Evans
● Growing Object Oriented Software
○ by Steve Freeman and Nat Pryce
● Specification by Example
○ by Gojko Adzic
● The Cucumber Book
○ by Matt Wynne and Aslak Hellesoy
● ATDD by Example
○ by Marcus Gartner
88. Some possible Levels to view the
communication process at
● Desire
● Contextualised
● Examples
● Explored
○ what did we miss? how did we get it wrong? is it
enough?
● Implementation (s)
Other people use different levels. So do I.