Usando approcci BDD e DDD, che sembrano complementarsi e contraddirsi l'un l'altro

-1

Sto cercando di applicare BDD e DDD insieme a un nuovo progetto Il problema che sto avendo al momento può essere riassunto dalla seguente citazione (presa da qui: link ):

"The approach for most BDD practitioners is to test outside–in by testing every scenario through the user interface, UI. In contrast, what DDD practitioners care most about is the domain core which for them is hidden behind a slow and fragile UI and they therefore tend to work middle–out, starting with the domain core and not until the implementation of the core is stable enough, an implementation of a UI on top of the core is done."

L'articolo dice:

"In order to bring BDD and DDD practices together the two techniques needs to be combined and Kudryashov does this by first removing the UI then running tests through the domain"

Idea 1

Dire che ho una definizione Step come questa:

[When(@"I calculate eligibility for Loans")]
public void WhenICalculateEligibilityForLoans()
{
    _actualLoans = _eligibilityController.CalculateEligibility(_person, _availableLoans.ToList();
}

Si noti che la Definizione Step chiama un controller dall'interfaccia utente. Ciò significa che devo aspettare che l'interfaccia utente sia pronta prima di poter eseguire questo test. In effetti la Step Definition non verrà compilata fino a quando non verrà sviluppata l'interfaccia utente (alla fine dello sprint). È normale?

Idea 2

Modifica la definizione del passo a questo:

[When(@"I calculate eligibility for Loans")]
public void WhenICalculateEligibilityForLoans()
{
    _actualLoans = _eligibilityDomainObject.CalculateEligibility(_person, _availableLoans.ToList();
}

Idea 3

Modifica le definizioni dei passaggi mentre lavoro attraverso lo sprint. Ciò significa che l'idea 2 verrà utilizzata quando svilupperò il modello di dominio e l'idea 1 quando svilupperò l'interfaccia utente.

Qualcuna delle mie idee è valida o esiste un'altra idea?

    
posta w0051977 21.03.2018 - 11:38
fonte

1 risposta

0

Testare direttamente un controller non ha molto senso per me. Hai una quantità limitata di cose da testare a questo livello, e la maggior parte sta verificando che i metodi di dominio appropriati sono stati chiamati e sono state restituite le visualizzazioni corrette. Chiamare direttamente il controller significa che non stai testando realmente che l'interfaccia utente sia cablata correttamente. Per testare veramente un'interfaccia utente è necessario raggiungere un livello più alto e interagire con le visualizzazioni, questo garantisce che l'interfaccia utente funzioni effettivamente e che siano state restituite le viste corrette.

Se si verifica che CalculateEligibility restituisce risultati corretti, è necessario eseguire solo sull'oggetto dominio. La tua interfaccia utente può assumere che i valori che riceve siano sempre corretti se trasmettono valori validi, altrimenti stai duplicando il test.

    
risposta data 21.03.2018 - 13:34
fonte

Leggi altre domande sui tag