Testy jednostkowe z długimi wejściami

Question

[TestMethod] 
public void SomeTestMethod() 
{ 
    string input = "some looooong input..."; 

    var proc = new Processor() 
    string result = proc.DoSomething(input); 

    Assert.Equals("good", result); 
} 

Jeśli piszę test jednostkowy i mam dane wejściowe, które są niezwykle długie (takie jak transakcje EDI), czy powinienem wkleić to do mojej metody testowej jako długi ciąg?

Inni sugerują, że powinienem wkleić ten długi ciąg do pliku i potraktować ten plik jako zasób osadzony w moim projekcie testowym. Jeśli zrobię coś takiego i potrzebuję różnych danych wejściowych dla każdego z moich testów, widzę wiele plików spiętrzających się i trudnych do utrzymania.

Czy są w tym jakieś najlepsze praktyki? Czy powinienem dalej wklejać te długie łańcuchy w moje metody testowania?

Answer 1

Zawsze umieszczam długie ciągi testowe w zasobach i utrzymuję spójne nazewnictwo między testami i ich zasobami, aby mapowanie było łatwe. Używam tej samej nazwy dla zasobu i testu. Gdy potrzebuję kilku zasobów do testu, dodaję przyrostek 1, 2, 3 i tak dalej.

Answer 2

Jeśli jest to coś szybkiego, o co mnie nie obchodzi, upuść go w kodzie. Ponieważ jestem bardziej niż prawdopodobny testowanie koncepcji.

Jeśli jego kod będzie zachowywał się jak testy lub kod produkcyjny, użyj pliku zasobu jako zasobu osadzonego lub pliku resx, z którym możesz wygodniej pracować.

Answer 3

Można użyć innego konstruktora ciąg stworzyć bardzo długi ciąg powtarzających się znaków, takich jak to:

string input = new string('x', 1024 * 1024/2); 

Takie podejście daje znacznie bardziej elegancki sposób tworzenia długich ciągów withing konieczności wklej długie ciągi do swoich testów.

Answer 4

To jest tylko "opiniotwórcza" odpowiedź, ponieważ nigdy nie widziałem najlepszej praktyki w tym zakresie;

Pracuję z plikami EDI, a nasze przypadki testowe są zwykle samodzielne z wklejonymi danymi testowymi, tak jak to robisz, w naszym przypadku jako stałe zdefiniowane poza samym testem, aby nie zaśmiecać rzeczywistego kodu testu.

Okazało się, że obsługa plików zewnętrznych jest podatna na błędy.

Answer 5

Testowałem niektóre regexp, które przeciw plikowi. To, co zrobiłem, skopiowałem wklejono zawartość pliku do klasy testowej jako normalną właściwość, ale użyłem tagów #region, aby ją ukryć. Nie muszę wyświetlać 200 wierszy tekstu za każdym razem, gdy otwieram tę klasę testową. Jest to również jeden z nielicznych przypadków, w których znacznik #region jest przydatny.

Answer 6

Bez znajomości kodu Processor „s, jak ja to widzę, Processor testy powinna mieć prosty, szybki, jednostkowe obejmujące jego wewnętrzne mechanizmy, podczas gdy testy takie jak SomeTestMethod powinny być traktowane jako testy Integracja.

Jako takie, przechowałabym wszystkie moje dane testowe w pliku XML i ładowałam je do testu, uruchamiając ten sam test dla każdego wejścia (Jeśli chcesz przetestować poważne ilości danych - możesz użyć bazy danych) . Nie ma potrzeby pisania osobnych testów dla każdego wejścia.

Bardzo czyste i eleganckie podejście do tego, jak robi się to w MSTest, jest opisane jako here.