Parte della gioia del BDD si sta allontanando da quella parola, "test".
Al contrario, abbiamo esempi che illustrano come si comporta il codice, sia a livello di sistema che a livello di unità.
Questi esempi ci consentono di stabilire se il comportamento del codice è appropriato. Ad esempio, potremmo avere una classe "Shop" che è responsabile per la registrazione delle scorte e per gli ordini.
Quando guardiamo gli esempi, possiamo vedere i seguenti comportamenti illustrati:
should Record Stock
should Take Orders
Una delle cose che possiamo fare quando smettiamo di pensare ai "test" è pensare, "dovrebbe? Dovrebbe davvero?"
Possiamo vedere che si tratta di due diversi aspetti del comportamento, quindi sappiamo che forse il negozio dovrebbe delegare tali aspetti. Possiamo iniziare a pensare a cosa dovrebbe fare davvero un negozio.
Qual è lo scopo di un negozio? Bene, è per fare soldi per il proprietario e per fornire beni ai clienti. Registrare le scorte e prendere ordini sono solo parte di ciò.
Quindi forse un negozio:
should Make Money
should Provide Goods for Customers
Wow. Abbiamo la possibilità di prendere ordini e registrare azioni, ma non abbiamo in realtà alcun modo di scoprire se stiamo facendo soldi o fornendo i beni corretti. Forse dovremmo farlo anche noi ...
Usando il linguaggio naturale e parlando di ciò che un codice dovrebbe fare, possiamo avere conversazioni con la nostra attività per vedere se comprendiamo correttamente i loro requisiti, quindi portare il linguaggio che usano nel codice.
A quel punto, molte cose diventano più ovvie.
- Se il nostro codice non sta facendo quello che dice dovrebbe, potrebbe essere il codice sbagliato.
- Se il nostro codice sta facendo ciò che dovrebbe, ma non dice che lo sta facendo, dobbiamo refactoring cose come metodo e nomi di variabili, e forse anche estrarre alcuni metodi.
- Se qualcos'altro dovrebbe fare ciò che sta facendo il nostro codice, dobbiamo spostare le cose in classi diverse.
- Se la nostra applicazione non sta facendo ciò che dovrebbe, possiamo invece chattare con l'azienda su ciò che vogliono realmente che faccia.
Usare un negozio è un esempio piuttosto semplice, ma spero che tu possa vederlo pensando al codice non in termini di "test" e "how to test", ma in termini di "come dovrebbe comportarsi", finiamo utilizzando il principio della responsabilità unica ... beh, più responsabilmente. E probabilmente impareremo molto sul nostro dominio, creando allo stesso tempo codice leggibile e gestibile.
Questo è il cuore di BDD. Trovo che i BDDer esperti abbiano bisogno di rifattorizzare di meno, perché finiscono per creare cose che aderiscono all'SRP per cominciare.