2020 Approach to software development with in its core these elements: • Focus on learning • Language as a first class citizen • Multiple models is the key for not evolving into a big ball of mud. Alberto Brandolini
2020 Approach to software development with in its core these elements: • Focus on learning • Language as a first class citizen • Multiple models is the key for not evolving into a big ball of mud. • Good coding practices are expected Alberto Brandolini
2020 Approach to software development with in its core these elements: • Focus on learning • Language as a first class citizen • Multiple models is the key for not evolving into a big ball of mud. • Good coding practices are expected • Know your core domain Alberto Brandolini
the problem domain. Benefits: - Bridging the Business and IT gap - Managing the complexity of software - Creating maintainable software systems, that are easy to understand and change
the problem domain. Benefits: - Bridging the Business and IT gap - Managing the complexity of software - Creating maintainable software systems, that are easy to understand and change Highly Recommended
that gets straight to the good stuff (…) My response is behaviour-driven development (BDD).” “It has evolved out of established agile practices and is designed to make them more accessible and effective (…) Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.” Dan North; Introducing BDD Blog
existing good practice, it is not a radically new departure. Its aim is to bring together existing, well-established techniques under a common banner and with a consistent and unambiguous terminology.
(and can be understood by) both Business and IT 3. The Behavior can be seen as the stable specifications of the system. The contract of how the system should behave to its users. Why behavior first?
a common, rigorous language between software team and the users/experts. • So focus on a shared vocabulary with clear meaning DDD – Ubiquitous Language* *Comes from the Latin word ubique, meaning "everywhere".
a common, rigorous language between software team and the users/experts. • So focus on a shared vocabulary with clear meaning Not only words, but also about relationships. The Business and IT people should have a shared understanding of the domain model. • Focus on the model, how is all related DDD – Ubiquitous Language* *Comes from the Latin word ubique, meaning "everywhere".
are assigned to those domains, teams are as independent as possible (bounded context, DDD). When teams are responsible for a domain, they can own and evolve the ubiquitous language of that domain. Teams aligning around problem domains
user to solve a problem or achieve an objective User stories are Requirements Story As a User, I want some Behavior, so that I can achieve some benefit
user to solve a problem or achieve an objective User stories are Requirements Story As a User, I want some Behavior, so that I can achieve some benefit Stable requirements when user stories and acceptance criteria are focussed on “the problem domain”
to handle traffic spikes - Doesn’t have the view of a user - Focussed on solutions - What is the problem behind the traffic spikes? Better Alternative: As a user, I want the website to load quickly even during Black Friday so that I can shop without interruption Bad User Story Examples
advertisement on the checkout page, to increase ad revenue. - Doesn’t describe what to user gains / the added value is - This actively degrades the user experience to benefit the business. Better Alternative: As a shopper, I want to see relevant product recommendations during checkout, so I can discover items I might like. Bad User Story Examples
of a system’s behavior, and from which scenarios can be derived. A scenario is an example of the system’s behavior from one or more users’ perspectives. Acceptance criteria and Scenarios https://lizkeogh.com/2011/06/20/acceptance-criteria-vs-scenarios/ Liz Keogh
baby animals younger than their recommended selling age Given a rabbit called Fluffy who is 1 1/2 months old And the recommended selling age for rabbits is 6 months old When we try to sell Fluffy Then we should be told Fluffy is too young.
must be alphanumeric and exactly 6 characters. • A single code can only be used once per customer. • If the code is expired, it cannot be used. Scenarios (Concrete Examples) Given the user is checking out, When the user applies a valid discount code, Then the discount value should be subtracted from the total Given the user is checking out, When the user applies an expired discount code, Then the user should be notified it is expired.
decoupled from implementation Otherwise they are too tightly coupled to your implementation, and you have to change them over and over. Given the user is checking out, When the user applies an expired discount code, Then the user should be notified it is expired. VS Given the user is on the checkout page, And the user enters an expired discount code in the discount field, When the user clicks apply, Then the the error message “This code is expired”, should be displayed
decoupled from implementation Otherwise they are too tightly coupled to your implementation, and you have to change them over and over. Given the user is checking out, When the user applies an expired discount code, Then the user should be notified it is expired. VS Given the user is on the checkout page, And the user enters an expired discount code in the discount field, When the user clicks apply, Then the the error message “This code is expired”, should be displayed Focus on the goal Instantly readable Hides implementation details Reduces maintainance Test case is always true
of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.” Importance of concrete scenario’s Liz Keogh
of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.” “When we’re discussing the scenarios, it isn’t always necessary to write scenarios for all the acceptance criteria. As long as the acceptance criteria are clear enough to derive the relevant scenarios easily, I recommend leaving it as acceptance criteria until the point where it needs to be automated.” Importance of concrete scenario’s Liz Keogh
scope of the story • Examples that can lead to acceptance tests. • Questions about scenarios where your team isn’t clear on expected behavior. • Assumptions you’re making in order to move forward • New backlog items that you discover as a result of the discussion or sliced off and deferred from delivery.
day -> Ideal week Quite complex: Scenarios ready and confirmed with the business before we started building During sprint: Automate scenario first, then build
don’t follow an all-in BDD process, you can benefit from this thinking. Used BDD mindset as a developer to create software that is easy to use by other software If it is difficult to write a test, your software is hard to use. (and design is bad) Write the test first: Forces you to think first from a users perspective, before writing code
globally this way: Given a bodemonderzoek is started by consumer When the bodemonderzoek is completed Then consumer is notified that the bodemonderzoek is completed And the the document is saved correctly
Test Scenarios by functionality in a separate test file • Reveals the why of a system • Documentation for new team members • Always later extractable Documentation
should be working as a “Definition of Done”. So even when you don’t automate these tests before you start developing, they have a lot of value! Regression tests
setting up projects or creating build pipelines, but not for durable software development. LLM benefit from more context. Using Scenarios as Specifications, creates more focussed instructions to the LLM, with test cases as constraints. This enables a more spec-driven development approach, instead of pure vibe coding. https://www.scalablepath.com/ai/spec-driven-development-guide BDD provides context and understanding
paulvdslot
ks91
hamatsutaichi
rung
shinyaigeek
iwamot
hiroakis
joker1007
kumorn5s
starfish719
watany
htokoyo
ydah
lara
jonoalderson
cassininazir
aleyda
axbom
davidcarrasco
marcelosomers
matthewcrist
lauravandoore
techseoconnect
tamaranovitovic
codingconduct
