Quanto dovrebbe essere grande un array di input per testare un metodo con un loop? [chiuso]

Question

Quanto dovrebbe essere grande un array di input per testare un metodo con un loop? [chiuso]

#1 da (1 voti)

0

Probabilmente questa sembra una domanda stupida, perdonami se ti sto chiedendo questo nel posto sbagliato, sarei felice di cancellarlo se è così. Sono un po 'nuovo al test delle unità e mi piacerebbe imparare le migliori pratiche su questa domanda, mi ha infastidito per un po'.

Supponiamo che esista un metodo che accetta un array come input ed esegue un algoritmo per i suoi elementi. Può esserci una situazione in cui il metodo viene chiamato ripetutamente con input contenente elementi che sono già stati elaborati dall'oggetto (e ricordati da qualche parte). Vorrei provare che il metodo non elabora gli stessi elementi di input due volte, cioè che non fa nulla la seconda volta che incontra quegli elementi.

L'oggetto sotto test è in realtà un wrapper attorno a un altro oggetto fornito come depenency, quindi posso prendere in giro quell'oggetto e verificare che vengano chiamati i metodi di elaborazione necessari.

Quindi la mia domanda è:

Quanti elementi di input considereresti "sufficienti" per verificare che il metodo funzioni correttamente (sia per i vecchi che per i nuovi elementi)? Uno? Tre? Dieci?

unit-testing

posta iosdude 12.11.2015 - 05:11

fonte

1 risposta

Leggi altre domande sui tag unit-testing

Dove devo accedere l'utente in base alla sessione http: servizio o controller? Programmazione orientata agli oggetti - subobject vs globals (use case) [closed]

score 1 · Accepted Answer

Ciò che descrivi è qualcosa del formato:

for elt in list loop
  if unprocessed(elt) then process(elt) end loop
end loop

Ciò che REALMENTE hai è qualcosa del tipo

for elt in list loop
   maybe_process(elt)
end loop

dove

proc maybe_process(elt) is
   if unprocessed(elt) then process(elt) end if
end proc

I LISPer riconosceranno immediatamente il secondo modulo come MAPC, che accetta una funzione e la applica a ciascun elemento di una lista.

A quel punto, il tuo problema originale è scomposto in due problemi molto più semplici, quello di chiamare una funzione ARBITRARY su ogni elemento di una lista e quella di scrivere una funzione che può prendere un elemento, determinare se è già stata elaborata e, se non, elaborarlo. La prima funzione prende come pochi elementi nella lista di cui hai bisogno, probabilmente ne userei tre. La seconda funzione prende tutti i singoli casi di test di cui hai bisogno per controllare i due pezzi della torta.

Anche se lo decomponi nel primo modulo, puoi utilizzare funzioni di test molto semplici per controllare il ciclo, e quindi una funzione process () molto semplice per controllare il predicato non elaborato ().

La chiave è che puoi usare le funzioni MUCH SIMPLER per fare le tue fasi di test.