Chcę zaimplementować JUnit na małym projekcie, nad którym pracuję, ponieważ chcę się trochę o nim dowiedzieć.Jak mogę porównać pliki w teście JUnit?
Samouczki, które przeczytałem, odnoszą się do metod, które mają określone wyniki.
W moim przypadku moje dane wyjściowe są plikami, jak mogę to zrobić? jakiś prosty przykład? Jakieś podejście, które może mi w tym pomóc?
Pliki są nieprzetworzonymi plikami tekstowymi, które są tworzone metodą prywatną void.
Chcesz uzyskać poprawny plik wyjściowy dla danego zestawu danych wejściowych i skonfigurować test, aby wywołać metodę void z tymi danymi wejściowymi, a następnie porównać sprawdzony plik wyjściowy z wynikami uzyskanymi za pomocą metody. Musisz upewnić się, że masz jakiś sposób na określenie, gdzie twoja metoda zostanie wyprowadzona, w przeciwnym razie twój test będzie bardzo kruchy.
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Test
public void testXYZ() {
final File expected = new File("xyz.txt");
final File output = folder.newFile("xyz.txt");
TestClass.xyz(output);
Assert.assertEquals(FileUtils.readLines(expected), FileUtils.readLines(output));
}
Używa commons-io FileUtils tekstu wygodą porównania plików & JUnit na TemporaryFolder celu zapewnienia plik wyjściowy nie istnieje przed przebiegów testowych.
Po metodach zapisz plik, w jednostce testowej możesz odczytać plik i sprawdzić, czy jest on poprawnie zapisany.
Inną rzeczą, która ma sens, jest podzielenie metod na takie, które pobierają te dane i zwracają je do metod, które tylko zapisują je w pliku. Następnie możesz sprawdzić, czy dane zwrócone przez pierwszą metodę są w porządku.
Kolejnym wiarygodnym podejściem byłoby przekazanie OutputStream do metody, która zapisuje dane. W "prawdziwym kodzie" można podać FileOutputStream/FileWriter, podczas gdy w kodzie testu można napisać fałszywą implementację OutputStream i sprawdzić, co jest do niego zapisywane.
Jeśli nie możesz kontrolować metody, aby umieścić dane wyjściowe w strumieniu, to powiedziałbym, że musisz zmienić kod, aby metoda otrzymywała strumień w parametrze (lub w konstruktorze swojej klasy) .
Po tym testowanie jest dość łatwe - wystarczy sprawdzić strumień. Łatwo testowalny kod zwykle jest dobry.
Problem polega na tym, że w rzeczywistości nie tworzy jednego pliku, tworzy od 3 do 5 plików w zależności od różnych rzeczy. Ale ponieważ jestem naprawdę noob z junit, chciałem najpierw wypróbować go z jednym plikiem, aby całkowicie go zrozumieć. Dzięki = D. – Saikios
@Saikios ma to znaczenie dla dowolnej liczby plików :) –
Mimo że pytanie może wydawać się uproszczone, uderza ono w sedno testów jednostkowych, należy napisać dobrze sformułowany kod, który można przetestować. Dlatego niektórzy eksperci zalecają, aby najpierw napisać test jednostkowy, a następnie klasę wykonawczą.
W twoim przypadku proponuję zezwolić twojej metodzie na wykonanie i utworzyć oczekiwane pliki, po czym twoje testy jednostkowe mogą analizować, że pliki są tworzone poprawnie.
Dzięki, będę mieć to na uwadze, aby następnym razem najpierw wykonaj test mojej jednostki: D – Saikios
Fragment kodu, który zapisuje cały plik, jest prawdopodobnie zbyt duży i złożony. JUnit może pokazać, czy kod nadal działa (brak regresji) i to jest coś. Jednak naprawdę dobre testy jednostek pomagają również znaleźć co jest uszkodzone – h22
Użyj klasy junitx.framework.FileAssert z . Inne linki:
Jedną z metod:
assertEquals(java.lang.String message,
java.io.Reader expected,
java.io.Reader actual)
** chronione ** static void assertEquals (komunikat java.lang.String, oczekiwany java.io.Reader, rzeczywisty stan java.io.Reader) – user482745
Jak metody zapisu pliku? Jeśli dostaną strumień, możesz po prostu dać im swoje, zamiast wskazywać na plik, a następnie porównać go. –
Whith podstawowy bufor do zapisu wewnątrz robota sieciowego (wciskam enter, ale napisałem wiadomość) kod jest podobny do: txtUrlSpecial.write (bigText.charAt (j)); – Saikios