Test di una classe che ha solo un campo solo che è un numero ID

0

Sto cercando di incorporare BDD nelle pratiche di lavoro dei team per rendere più efficaci le interazioni con gli Analisti aziendali. Recentemente ho posto questa domanda: Devo passare un Numero ID dal file delle caratteristiche?

Vedi il codice qui sotto:

public class Chestnut
{
    private Guid _id;

    public Customer (Guid id)
    {
       if (id == Guid.Empty)
                throw new ArgumentException();           
         _id = id;
    }
    //Chestnut methods go here.
}

Come potrei testare questa classe se stavo usando Specflow (come nella mia altra domanda)? Stavo pensando di creare due test:

1) Viene creata una castagna perché viene passato un ID valido. 2) A Chestnut non viene creato perché viene passato un ID vuoto.

Stavo pensando di fare quanto segue:

1) Dato un ID;    Quindi crea una castagna con uno stato valido

2) Dato un ID vuoto    Quindi viene presentato un errore di convalida per l'ID

Tieni presente che non sto specificando l'ID nello scenario effettivo, perché si tratta di un dettaglio di implementazione.

È un test "buono" o esiste un altro modo per approcciarlo? Dovrei anche creare un test per questo?

    
posta w0051977 03.03.2018 - 10:51
fonte

2 risposte

1

Quel costruttore ha un comportamento, quindi testarlo potrebbe essere ragionevole. In particolare: perché viene scritto questo codice se non si effettua un test pass?

Un test che controlla solo che un oggetto è stato creato è un test estremamente debole . Quali proprietà utili fa questo esercizio? Vicino a nessuno, perché altre parti del codice che devono creare un Chestnut dovranno comunque eseguire quel costruttore.

Il test che la costruzione dovrebbe fallire per gli ID vuoti è più prezioso, ma ciò solleva la domanda su quale sia il valore commerciale di questo controllo e perché un ID possa persino essere vuoto. Se riesci a rispondere (e dai a questo scenario di prova un nome ragionevole), allora è grandioso, ma comunque testalo comunque.

Si noti che questi test sui livelli di "costruttori" e "ID" sono probabilmente dettagli di implementazione di livello molto basso e non codificano alcun utile comportamento . Quali requisiti di livello aziendale sono affrontati da questo comportamento? Per dettagli di così basso livello, uno scenario in stile Gherkin probabilmente richiede uno sforzo ingiustificato. Questi test in stile BDD dovrebbero solitamente concentrarsi su comportamenti e requisiti di livello superiore. Se testate questo (e dovreste farlo!), Allora un quadro di testing unitario più semplice sarà molto più appropriato.

    
risposta data 03.03.2018 - 22:58
fonte
0

Il test di un costruttore con un comportamento ha senso. Se qualcosa è pubblico e può essere testato in modo esplicito, dovrebbe essere testato in modo esplicito.

Non sono d'accordo con Amon, non vuoi testare implicitamente il costruttore con altri test. La mia comprensione è che in particolare non si desidera testare nulla del componente che si sta testando dipende in modo esplicito. Parola chiave "isolamento di prova". (Non si parla di test di integrazione)

Comunque, hai una dichiarazione if in una funzione. Deve essere testato da un test unitario. Costruttore di funzione.

    
risposta data 04.03.2018 - 19:08
fonte

Leggi altre domande sui tag