Quali sono i casi di test validi per le chiamate di metodo all'interno della condizione if-else

Question

Quali sono i casi di test validi per le chiamate di metodo all'interno della condizione if-else

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

1

Ho un servizio di sconti che viene chiamato se vengono soddisfatte determinate condizioni. Devo scrivere casi di test per verificare se il servizio di sconto è chiamato. Il mio dubbio è verificare se il servizio di sconto NON è chiamato per il tipo 4 e 5 è uno scenario di test case valido.

public void ApplyDiscount(int typeId, double amount)
{

if(typeId == 1)
{
  //call discount service
}

else if(typeId == 2)
{
  //call discount service
}

else if(typeId == 4)
{
   //do other stuff
}
else if(typeId == 5)
{
   //do some other stuff
}

}

unit-testing c#

posta Sunny 29.01.2014 - 21:17

fonte

4 risposte

Leggi altre domande sui tag unit-testing c#

Inserimento dati di connessione socket Struttura dati che supporta le seguenti operazioni

score 1 · Answer 1

(Ho più familiarità con Java, Junit e mockito - quindi quello che scrivo qui di seguito è basato su la mia comprensione di questo si applica a ciò che riesco a trovare)

Stai cercando uno strumento di simulazione come Moq .

In questo scenario ciò che faresti è prendere in giro l'oggetto che contiene DiscountService.

A questo punto, dovresti fare qualcosa di simile (non ho modo di verificare se il seguente codice è corretto per il framework, ma è nella giusta direzione):

public void Test() {
    var mockService = new Mock<IDiscountService>();
    SomeClass.ApplyDiscount(1, 0.0);
    mockService.Verify(
       mockService = foo.ApplyDiscount(), Times.Once());
}

E questo verificherà che il servizio sconti sia stato chiamato una volta (e solo una volta) quando è stata effettuata la chiamata a ApplyDiscount con il parametro specificato.

Ti informerò che la struttura di questo codice che hai pubblicato su psuedocoded sembra anche sospetta. L'int è passato e quello che sembra essere qualcosa che vuole essere un'istruzione switch odori come se volessi essere polimorfismo.

Considera che se il test è difficile da scrivere, a volte significa che il design del sistema è sbagliato e dovrebbe essere rivisitato. Il codice ben scritto tende ad essere facile da testare.

Tuttavia, vorrai leggere su Moq e usarlo nei posti giusti (come verificare che qualcosa sia stato chiamato il numero appropriato di volte senza inserire il codice di prova nel tuo codice reale - che ha un odore ancora peggiore di quello degli interruttori).

score 0 · Answer 2

A questo punto non ci sono casi di test validi.

Non c'è molto da provare qui. Il metodo restituisce void, quindi qualsiasi test verrebbe focalizzato su qualsiasi effetto su un oggetto o su uno stato interno a questo metodo o su uno stato di alterazione di ambito globale. Se i casi 1 e 2 chiamano semplicemente un servizio, non vi è alcun cambiamento di stato, quindi non c'è nulla da testare.

Casi 4 e 5, non so che tipo di cose stai facendo, quindi a questo punto non scriverei nessun test per questo.

Inoltre, probabilmente utilizzerei un'istruzione switch invece di un gruppo di if / elses. Sembra che il caso 1 e 2 siano uguali.

score 0 · Answer 3

Il modo più semplice per scoprire il test a cui stai pensando nella lista delle caratteristiche che vuoi formare il codice sotto test, ad esempio:

"quando il tipo è 1,2 servizio sconto chiamate"
"quando il tipo è 4 fai qualcosa"
"quando type è 5 fai qualche altra cosa"

Forse non hai bisogno di un test per verificare esplicitamente che il servizio sconti non sia chiamato, probabilmente hai più servizi nelle tue applicazioni e non vuoi controllare che non ci siano chiamate a tutti quei servizi.

score 0 · Answer 4

Tutte le buone suite di test unitarie non si limitano a testare i casi di sole, ma anche a testare per vedere cosa succede se viene fatto qualcosa che non è consentito.

Dovrai fare un elenco esaustivo dei casi che la tua unità deve essere in grado di gestire. Per ognuno dei tuoi tipi di caset nello snippet che hai pubblicato, dovrai pensare ad almeno un caso che deve evocare il codice di gestione degli errori nel codice per ogni errore gestito dal tuo codice. Per i casi di sole è importante quanto è il tuo 'intervallo di input'. Dovrai testare per ogni classe di input nell'intervallo che dovrai gestire.

Dopo averlo fatto, devi determinare quali valgono la pena di lavorare per il test completo.

Il tuo non chiamare 4 o 5 dovrebbe essere sicuramente uno dei vari casi di test.

BTW, sono d'accordo con @MichaelT e suggerirei di utilizzare un modello di strategia [1] per ottenere un design migliore. Ciò renderebbe anche più semplice creare una suite di test adeguata per la tua applicazione, poiché tutti i comportamenti si trovano nelle loro classi.

[1] link