Un progetto Test di accettazione per strato o un progetto Test di accettazione per Contesto limitato

-1

Questo link ( link ) dice: "I test di funzionalità dovrebbero dipendere solo dall'applicazione strato "cioè livello di presentazione.

Sto cercando di capire come si adatta BDD quando si utilizza l'architettura di Onion e TDD per sviluppare un sistema. Ho comprato un libro, che dovrebbe arrivare nel fine settimana.

La mia comprensione di Cipolla e TDD è la seguente:

1) Scrivi i test per il core. Quindi sviluppo del core in modo che i test passino

2) Scrivi i test per il livello infrastruttura. Quindi sviluppo del livello infrastruttura in modo che i test superino

3) Scrivi i test per il livello di servizio dell'applicazione. Quindi sviluppo del livello del servizio applicativo in modo che i test superino

4) Scrivi i test per il livello dell'interfaccia utente. Quindi sviluppo del livello dell'interfaccia utente in modo che i test superino

In che fase si inserisce BDD? La mia lettura mi sta dicendo che il BDD dovrebbe essere end-to-end. Ad esempio, se si utilizzava Specflow, le definizioni di passo avrebbero accesso al controller. Ad esempio (tratto da qui: link ):

[When(@"I perform a simple search on '(.*)'")]
public void WhenIPerformASimpleSearchOn(string searchTerm)
{
    var controller = new CatalogController();
    actionResult = controller.Search(searchTerm);
}

In questo caso BDD viene scritto solo quando viene scritto il livello più esterno dell'applicazione (interfaccia utente).

Tuttavia, stavo anche leggendo qui su una squadra che appare (potrei sbagliarmi) per sviluppare solo il modello di dominio e usare Specflow per i test di accettazione, cioè le definizioni dei passaggi fanno riferimento direttamente al modello di dominio. Questo non finisce qui per finire.

Domanda

Le funzioni BDD sono utilizzate per testare tutti i livelli come questo:

MyApplication.UI.AcceptanceTests - includes features and step definitions
MyApplication.ApplicationService.AcceptanceTests - includes features and step definitions
MyApplication.Infrastructure.AcceptanceTests - includes features and step definitions
MyApplication.Core.AcceptanceTests - includes features and step definitions

o hai una sola applicazione, che fa riferimento all'interfaccia utente:

MyApplication.AcceptanceTests

Ho fatto molte ricerche online per la mia risposta, tuttavia non l'ho trovata. Per esempio, ho cercato qui: Usando gli scenari di Specflow sia per i test di integrazione che per i test di unità, qui: BDD Outside-in (con Specflow) e qui: BDD: Quando / dove impostare gli stub?.

    
posta w0051977 09.03.2018 - 17:41
fonte

1 risposta

2

write tests for x then development of the x so that the tests pass

Beh no, scrivi un singolo test per una piccola parte di x. Quindi sviluppa parte di x in modo che il test passi. Refactor. Ripeti.

Il BDD è diverso in quanto a BDD non importa se la parte di x è visibile all'utente finale. BDD vuole test che restino focalizzati sui risultati visibili.

Alcuni diagrammi in questo modo:

La principale differenza tra questi test è a chi sono rilevanti. Un test unitario è rilevante per uno sviluppatore. Un test di accettazione è rilevante per il proprietario del prodotto.

Come per i livelli, è completamente una funzione di come organizzi il tuo codice. BDD non si preoccupa dei livelli. I livelli non sono qualcosa di cui un proprietario del prodotto deve sapere. Quindi non chiederglielo.

    
risposta data 10.03.2018 - 09:19
fonte

Leggi altre domande sui tag