Domanda
Quindi, sta usando Cucumber per definire (quasi) complesse interazioni di requisiti con un abuso dello strumento?
Impostazione domanda
È appropriato l'uso di Cucumber (o di qualsiasi altra specifica con uno strumento di esempio) per documentare le interazioni complesse delle regole? Le regole globali nei requisiti scritti possono lasciare delle ambiguità sul modo in cui interagiscono tra loro. Quindi sarebbe bello usare esempi concreti per documentare questo comportamento. Ed è importante che il cliente e la natura umana leggibile di Gherkin sia attraente. Tuttavia c'è una linea guida:
In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together. Dan North
Mentre per qualsiasi interazione con le regole ci sono facilmente dozzine di casi significativamente interessanti da documentare. Quindi, per qualsiasi funzione, si finisce con dozzine di scenari o si affettano sottilmente le proprie funzionalità fino all'assurdità fino a quando non sono più riconoscibili dal client (ad esempio "tutto fa parte del pulsante" auto-complete & save "). Inoltre, non è parte di un processo esplorativo di BDD, ma documenta le decisioni dai requisiti firmati.
Sfondo
Lavoro presso una società di consulenza che fornisce soluzioni personalizzate per la gestione della configurazione di cose relativamente complesse come i camion industriali dove ci sono molte opzioni e le regole e le dipendenze tra le opzioni sono complesse. Per peggiorare le cose, ci sono delle regole di business sulle dipendenze auto-soddisfacenti se l'utente non ha esplicitamente ( eg se non si specifica un motore, ne selezioneremo uno per in base al tonnellaggio attuale del veicolo) e le regole sul tie-break tra le quali l'opzione può essere estesa (ad esempio uno dei tipi di opzioni ha 7 livelli di tie-breaker).
Queste cose sono difficili da appianare nei requisiti che utilizzano le regole generali e sono un'enorme fonte di bug. Vi sono spesso controversie (poiché la rilavorazione comporta fatturazione aggiuntiva anziché essere coperta dal contratto di manutenzione) con il cliente se qualcosa è veramente un bug o hanno un cambiamento nel flusso di lavoro / regole aziendali / sistemi downstream che è una modifica al sistema.
PS - l'uso di una tecnologia diversa (ad es. motore di regole, Prolog) non è accettabile perché avrebbe effetto sul contratto di manutenzione. Deve essere una soluzione Java pura.
PPS - non siamo agili, siamo cascata quindi non è esplorativo, fa parte di un processo semi-ufficiale simile al "Memorandum of Understanding" del NAFTA
PPPS - Ho esaminato se questa domanda è appropriata da porre qui e sembra che rientri nei "metodi e pratiche di sviluppo del software" e nelle altre domande su Cucumber