Jak testować kod, który obwodów forever

Question

Mam app (epazote), który po uruchomieniu działa zawsze, ale chcę przetestować pewne wartości przed nim bloków/czeka aż ctrl + c jest wciśnięty lub zostanie zabity.

Oto mały przykład: 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") 
} 

Chciałbym wiedzieć, czy jest posible ignorować niektóre części kodu podczas testowania, czy jak to przetestować przypadki, I wprowadziły interfejs, w ten przypadek do testowania AddString pomógł mi przetestować niektóre części, ale nie mam pojęcia, jak uniknąć "bloku" i testu.

Wszelkie pomysły?

Aktualizacja: Umieszczenie kodu wewnątrz pętli Addstring w kolejnych pracach funkcyjnych ale tylko do testowania tej funkcji, ale jeśli chcę zrobić pełnego pokrycia kodu, nadal trzeba sprawdzić/przetestować blokuje część, na przykład jak sprawdzić, czy jest prawidłowo zachowywać się podczas odbierania ctrl + c lub kill -HUP, myślałem o może tworzyć fałszywe signal.Notify ale nie wiem jak zastąpić importowane w przypadku pakietów, które mogłyby pracować.

Answer 1

Przedstaw delegatów testu w swoim kodzie.

Wyodrębnij pętlę do funkcji, która przyjmuje 2 funkcje jako argumenty: onBeginEvent i onEndEvent. Podpisy funkcje przyjmują:

• stan, który chcesz sprawdzić wewnątrz przypadku testowego
• opcjonalnie: licznik liczby pętli (tak można określić każdą pętlę). Jest to opcjonalne, ponieważ faktyczna implementacja delegata może liczyć ile razy została wywołana przez siebie.

Na początku swojej pętli wywołuje się OnBegingEvent (counter, currentState); niż twój kod wykonuje normalną pracę, a na końcu wywołujesz OnEndEvent (counter, currentState); Przypuszczalnie twój kod zmienił currentState.

W produkcji można użyć pustej implementacji funkcji delegatów lub wdrożyć zerową kontrolę w pętli.

Możesz użyć tego modelu, aby umieścić tak wiele czeków swoich algorytmów przetwarzania, jak chcesz. Załóżmy, że masz 5 czeków. Teraz patrzysz na to i zdajesz sobie sprawę, że staje się to zbyt trudne. Tworzysz interfejs, który definiuje twoje funkcje zwrotne. Te funkcje wywołania zwrotnego są skuteczną metodą zmiany zachowania usług. Cofasz się jeszcze raz i zdajesz sobie sprawę, że interfejs to w rzeczywistości twoja "zasada świadczenia usług";)

Kiedy już weźmiesz tę trasę, będziesz chciał jakoś zatrzymać nieskończoną pętlę. Jeśli chcesz mieć ścisłą kontrolę w teście, możesz wziąć trzecią delegatę funkcji, która zwraca wartość true, jeśli nadszedł czas na wyjście z pętli. Współdzielona zmienna to opcja kontrolowania warunku zakończenia.

Jest to z pewnością wyższy poziom testów niż testowanie jednostkowe i jest niezbędny w złożonych usługach.

Answer 2

Tak, jest to możliwe. Umieść kod znajdujący się w pętli w oddzielnej funkcji, a urządzenie przetestuj tę funkcję bez pętli.