Come testare il codice che loop per sempre

Question

Ho un app (epazote) che una volta che si avvia corre sempre ma voglio provare alcuni valori prima blocca/attende fino Ctrl +c viene premuto o viene ucciso.

Ecco un piccolo esempio: http://play.golang.org/p/t0spQRJB36

package main 

import (
    "fmt" 
    "os" 
    "os/signal" 
) 

type IAddString interface { 
    AddString(string) 
} 

type addString struct{} 

func (self *addString) AddString(s string) { 
    fmt.Println(s) 
} 

func block(a IAddString, s string) { 

    // test this 
    a.AddString(s) 


    // ignore this while testing 
    block := make(chan os.Signal) 
    signal.Notify(block, os.Interrupt, os.Kill) 

    for { 
     signalType := <-block 
     switch signalType { 

     default: 
      signal.Stop(block) 
      fmt.Printf("%q signal received.", signalType) 
      os.Exit(0) 
     } 
    } 
} 

func main() { 
    a := &addString{} 
    block(a, "foo") 
} 

Vorrei sapere se è posible a ignorare alcune parti del codice durante il test, o il modo di testare questo caso, ho implementato un'interfaccia, in questo caso per il test AddString che mi ha aiutato a testare alcune parti ma non ho idea di come evitare il "blocco" e il test.

Qualche idea?

Aggiornamento: Mettere il codice all'interno del ciclo Addstring in un altro opere di funzione, ma solo per testare quella funzione, ma se voglio fare una copertura del codice completo, ho ancora bisogno di verificare/testare la parte di blocco, per esempio come verificare che si comporta correttamente quando si riceve ctrl + c o kill -HUP, stavo pensando di creare forse un falso signal.Notify ma non so come sovrascrivere i pacchetti importati nel caso in cui potesse funzionare.

Answer 1

Introduci i delegati di test nel codice.

Estrai il tuo loop in una funzione che accetta 2 funzioni come argomenti: onBeginEvent e onEndEvent. Le funzioni firme adottano:

• stato che si vuole ispezionare all'interno del banco di prova
• optional: contatore del numero di loop (in modo da poter identificare ogni ciclo). È facoltativo perché l'effettiva implementazione dei delegati può contare il numero di volte in cui è stata invocata da sola.

All'inizio del ciclo si chiama OnBegingEvent (contatore, currentState); che il tuo codice fa il suo normale lavoro e alla fine tu chiami OnEndEvent (counter, currentState); Presumibilmente il tuo codice è cambiato in currentState.

Nella produzione è possibile utilizzare un'implementazione vuota della funzione delegati o implementare il controllo nullo nel proprio ciclo.

È possibile utilizzare questo modello per eseguire tutti i controlli degli algoritmi di elaborazione desiderati. Diciamo che hai 5 assegni. Ora guardi indietro e comprendi che sta diventando troppo difficile. Si crea un'interfaccia che definisce le funzioni di callback. Queste funzioni di callback sono un potente metodo per modificare il comportamento del servizio. Fai un passo indietro ancora una volta e renditi conto che l'interfaccia è in realtà la tua "politica del servizio";)

Una volta che prendi quella rotta, vorrai interrompere il tuo ciclo infinito in qualche modo. Se si desidera un controllo stretto all'interno di un caso di test, è possibile assumere un delegato di terza funzione che restituisce true se è il momento di uscire dal ciclo. La variabile condivisa è un'opzione per controllare la condizione di uscita.

Questo è certamente un livello più elevato di test rispetto ai test unitari ed è necessario in servizi complessi.

Answer 2

Sì, è possibile. Inserisci il codice che si trova all'interno del ciclo in una funzione separata e l'unità prova quella funzione senza il ciclo.