Testy jednostkowe z funkcjami zwracającymi losowe wyniki

Wymyśl lub sfałszuj generator liczb losowych

public interface IRandomGenerator
{
    double Generate(double max);
}

public class SomethingThatUsesRandom
{
    private readonly IRandomGenerator _generator;

    private class DefaultRandom : IRandomGenerator
    {
        public double Generate(double max)
        {
            return (new Random()).Next(max);
        }
    }

    public SomethingThatUsesRandom(IRandomGenerator generator)
    {
        _generator = generator;
    }

    public SomethingThatUsesRandom() : this(new DefaultRandom())
    {}

    public double MethodThatUsesRandom()
    {
        return _generator.Generate(40.0);
    }
}

W Twoim teście, po prostu udawaj lub wyśmiewaj IRandomGenerator, aby zwrócić coś w puszkach.

Myślę, że są trzy różne aspekty tego problemu, które testujesz.

Pierwszy: czy mój algorytm jest właściwy? Oznacza to, że biorąc pod uwagę prawidłowo działający generator liczb losowych, będzie produkować daty, które są losowo rozmieszczone w całym zakresie?

Druga: czy algorytm poprawnie obsługuje przypadki edge ' a? Oznacza to, że gdy generator liczb losowych wytwarza najwyższe lub najniższe dopuszczalne wartości, czy coś się łamie?

Trzeci: czy mój implementacja algorytmu działa? Oznacza to, że biorąc pod uwagę znaną listę pseudolosowych wejść, czy produkuje oczekiwaną listę pseudolosowych dat?

Pierwsze dwie rzeczy nie są czymś, co wbudowałbym w zestaw testów jednostkowych. To coś, co udowodniłbym podczas projektowania systemu. Prawdopodobnie zrobiłbym to, pisząc uprząż testową, która generowała miliony dat i wykonywała test chi-kwadrat, jako daniel.zasugerował: rikowski Upewniłbym się również, że ta uprząż testowa nie zostanie przerwana dopóki nie obsłuży obu przypadków krawędzi (zakładając, że mój zakres liczb losowych jest na tyle mały, że mogę uciec z tego). I udokumentowałbym to, żeby każdy, kto przyjdzie i spróbuje poprawić algorytm, wiedział, że to przełomowa zmiana.

Ostatni to coś, dla czego zrobiłbym test jednostkowy. Muszę wiedzieć, że do kodu nie wkradło się nic, co łamie jego implementację tego algorytmu. Pierwszy znak, jaki dostanę, gdy tak się stanie, to że test zawiedzie. Potem wrócę do kodu i dowiem się, że ktoś inny myślał, że coś naprawia i go złamał. Jeśli ktoś zrobił naprawienie algorytmu, to na nim będzie również naprawienie tego testu.

Nie musisz kontrolować systemu, aby wyniki były deterministyczne. Jesteś na właściwym podejściu: zdecyduj, co jest ważne w wyjściu funkcji i przetestuj to. W takim przypadku ważne jest, aby wynik był w zakresie 40 dni, a Ty testujesz na to. Ważne jest również, aby nie zawsze zwracał ten sam wynik, więc przetestuj również to. Jeśli chcesz być bardziej fantazyjny, możesz sprawdzić, czy wyniki przechodzą jakiś test losowości..

Normalnie używam dokładnie Twojego sugerowanego podejścia: Kontroluj generator losowy. Zainicjalizuj go do testu domyślnym zalążkiem (lub zastąp go proxy zwracającym liczby pasujące do moich testów), więc mam deterministyczne / testowalne zachowanie.

Jeśli chcesz sprawdzić jakość liczb losowych (pod względem niezależności), można to zrobić na kilka sposobów. Dobrym sposobem jest test chi kwadrat .

W zależności od tego, jak twoja funkcja tworzy losową datę, Możesz również sprawdzić nielegalne daty: niemożliwe lata przestępne lub 31 dzień 30-dniowego miesiąca.

Metody, które nie wykazują deterministycznego zachowania, nie mogą być właściwie testowane jednostkowo, ponieważ wyniki będą się różnić w zależności od wykonania. Jednym ze sposobów na obejście tego jest seed generator liczb losowych o stałej wartości dla testu jednostkowego. Można również wyodrębnić losowość klasy generowania daty (a tym samym zastosować zasadę pojedynczej odpowiedzialności ) i wprowadzić znane wartości dla testów jednostkowych.

Jasne, użycie generatora liczb losowych ze stałymi nasionami będzie działać dobrze, ale nawet wtedy po prostu próbujesz przetestować to, czego nie możesz przewidzieć. Co jest ok. To jest równoznaczne z kilkoma stałymi testami. Pamiętajcie jednak-testujcie to, co ważne, ale nie próbujcie wszystkiego testować. Uważam, że testy losowe są sposobem na próbę przetestowania wszystkiego, a to nie jest skuteczne (lub szybkie). Potencjalnie musisz przeprowadzić wiele randomizowanych testów przed trafieniem w błąd.

What I ' m próba dotarcia do tego jest taka, że powinieneś po prostu napisać test dla każdego błędu, który znajdziesz w systemie. Testujesz przypadki edge, aby upewnić się, że twoja funkcja działa nawet w ekstremalnych warunkach, ale tak naprawdę to najlepsze, co możesz zrobić, nie spędzając zbyt dużo czasu lub spowalniając testy jednostkowe lub po prostu marnując cykle procesora.

Zalecałbym nadpisanie funkcji losowej. Testuję w PHP więc piszę ten kod:

// If we are unit testing, then...
if (defined('UNIT_TESTING') && UNIT_TESTING)
{
   // ...make our my_rand() function deterministic to aid testing.
   function my_rand($min, $max)
   {
      return $GLOBALS['random_table'][$min][$max];
   }
}
else
{
   // ...else make our my_rand() function truly random.
   function my_rand($min = 0, $max = PHP_INT_MAX)
   {
      if ($max === PHP_INT_MAX)
      {
         $max = getrandmax();
      }
      return rand($min, $max);
   }
}

Następnie ustawiam random_table, ponieważ wymagam tego na test.

Nie sądzę, żeby testy jednostkowe były do tego przeznaczone. Możesz użyć testów jednostkowych dla funkcji zwracających wartość stochastyczną, ale użyj stałego ziarna, w którym to przypadku w sposób, który nie jest stochastyczny, że tak powiem, dla Random seed, nie sądzę, testowanie jednostkowe jest to, co chcesz, na przykład dla RNGs to, co masz na myśli, to test systemu, w którym uruchamiasz RNG wiele razy i spojrzeć na dystrybucję lub momenty tego.