𝟯 𝗧𝗵𝗶𝗻𝗴𝘀 𝗡𝗼𝗯𝗼𝗱𝘆 𝗧𝗲𝗹𝗹𝘀 𝗬𝗼𝘂 𝗔𝗯𝗼𝘂𝘁 𝗕𝗗𝗗
Your Cucumber suite takes forty minutes to run. You cannot explain what a single feature file tests without reading layers of code.
Many teams adopt BDD because business stakeholders need to read tests. Then, those stakeholders stop reading. You end up with a maintenance nightmare.
Here are three truths about BDD.
𝟭. 𝗚𝗵𝗲𝗿𝗸𝗶𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲
Stop writing test scripts in Gherkin. If your scenarios list every click and every field, you are doing it wrong.
Bad Gherkin:
- Given the user enters email "test@example.com"
- And the user enters password "Password123!"
- And the user clicks "Place Order"
Good Gherkin:
- Given the user has items ready to purchase
- When the user pays with a valid credit card
- Then the order is confirmed
The "how" lives in your step definitions. The "what" lives in your feature files. Keep your feature files simple so a product manager can read them in seconds.
𝟮. 𝗦𝘁𝗲𝗽 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗮 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗴𝗿𝗮𝗽𝗵
Do not make step definitions import other step definitions. This creates a tangled web. If one step fails, it poisons the entire state.
The fix is simple:
- Separate your page objects from your step definitions.
- Use a shared domain layer.
- Step definitions should be thin wrappers that call domain objects.
This makes your steps stateless. You can change one part of your code without breaking every other scenario.
𝟯. 𝗕𝗗𝗗 𝗶𝘀 𝗮 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁
BDD is about communication, not just testing. The tests are a side effect.
If you optimize only for test coverage or execution speed, you lose the main goal. Your feature files should be the first thing a new engineer reads to understand your system.
If a person cannot understand your system by reading your feature files, your BDD suite has failed.
𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄:
- Pick your worst feature file.
- Rewrite scenarios to be three to five lines long.
- Move data into step definitions or factories.
- Replace step-to-step imports with domain objects.
Can you explain your system to a new hire using only your feature files in five minutes? If not, start rewriting.
3 cose che nessuno ti dice sul BDD prima che la tua suite Cucumber diventi un incubo di manutenzione
Il Behavior-Driven Development (BDD) è un approccio straordinario per colmare il divario tra gli stakeholder tecnici e quelli non tecnici. Tuttavia, se non viene gestito con cura, può trasformarsi rapidamente in un enorme debito tecnico.
Ecco tre cose che nessuno ti dice prima che la tua suite Cucumber diventi un incubo di manutenzione.
1. Stai scrivendo il "Come" invece del "Cosa"
L'errore più comune è scrivere scenari Gherkin che descrivono i dettagli dell'implementazione invece del comportamento del business.
Esempio sbagliato:
Quando clicco sul pulsante con ID "submit-btn"
E inserisco "test@example.com" nel campo "email-input"
Questo è un approccio orientato all'interfaccia utente, non al comportamento. Se l'ID del pulsante cambia o se l'interfaccia viene riprogettata, i tuoi test falliranno, anche se la funzionalità è ancora corretta.
Esempio corretto:
Quando invio le mie credenziali di accesso
Il secondo esempio descrive l'intento dell'utente, rendendo lo scenario molto più resiliente ai cambiamenti dell'interfaccia.
2. L'esplosione delle Step Definition
Molti team iniziano con pochi step, ma col tempo si ritrovano con una quantità enorme di step definition quasi identiche. Questo accade quando gli step sono troppo granulari.
Se hai step come:
Quando clicco su "Home"Quando clicco su "Profilo"Quando clicco su "Impostazioni"
Stai creando una manutenzione infinita. Invece di creare step atomici per ogni singola azione, dovresti cercare di creare step più compositi che rappresentino azioni di business significative.
3. Il falso senso di sicurezza
Questo è il punto più pericoloso. Puoi avere una suite Cucumber con una copertura del 100% che passa tutti i test, ma che non garantisce affatto che il prodotto funzioni per l'utente finale.
Perché succede? Perché spesso i test BDD finiscono per testare la logica dell'applicazione in modo isolato o, peggio, testano solo il "happy path" senza considerare i casi limite o le interazioni reali tra i componenti.
Se i tuoi scenari sono troppo semplici o troppo focalizzati su dettagli tecnici insignificanti, avrai una suite che passa sempre, ma che non ti avverte quando una vera funzionalità si rompe.
Optional learning community: https://t.me/GyaanSetuAi