Test Driven Development: Dobry / zaakceptowany sposób testowania działania systemu plików?

W tej chwili pracuję nad projektem, który generuje tabelę (między innymi) na podstawie zawartości systemu plików, a z kolei wprowadza pewne modyfikacje metadanych dotyczących znalezionych elementów. Pytanie brzmi: w jaki sposób należy napisać testy lub skonfigurować? Czy istnieje prosty sposób na wyszydzenie tego? Czy powinienem skonfigurować „piaskownicę”?

Jak zawsze w TDD z zasobami zewnętrznymi: tworzysz jeden lub więcej interfejsów do operacji systemu plików i „wyśmiewasz je”. Chcesz przetestować „generator tabel” i kod modyfikacji metadanych, a nie same operacje systemu plików (najprawdopodobniej używasz gotowych implementacji bibliotek do uzyskiwania dostępu do systemu plików).

Co jest złego w posiadaniu „testowego” systemu plików?

Utwórz szablonową strukturę folderów / katalogów, która ma wystarczającą zawartość do przetestowania operacji.

Podczas konfiguracji testu jednostkowego skopiuj tę początkową strukturę (zaleca się skompresowanie szablonu i rozpakowanie w obszarze testowym). Uruchom swoje testy. Usuń wszystko podczas niszczenia.

Problem z wyśmiewaniem polega na tym, że po pierwsze systemy plików, systemy operacyjne i bazy danych, które należą do twojego projektu, tak naprawdę nie kwalifikują się jako zasoby zewnętrzne, a po drugie, wyśmiewanie wywołań systemowych niskiego poziomu jest zarówno czasochłonne, jak i podatne na błędy.

Jest to coś, czego zdecydowanie potrzebujesz do testu integracji, ponieważ rzeczywiste systemy plików mają wszelkiego rodzaju dziwne zachowania (na przykład sposób, w jaki system Windows nie zezwala na usunięcie pliku, jeśli otwarty jest jakikolwiek proces, w tym program usuwający).

Podejście TDD polega więc na napisaniu najpierw testu integracyjnego (ściśle mówiąc, TDD nie ma odrębnych pojęć „test jednostkowy” i „test integracyjny”; są to tylko testy). Całkiem prawdopodobne, że to wystarczy; więc praca wykonana, przestań, idź do domu .

Jeśli nie, pojawi się pewna złożoność wewnętrzna, która nie jest łatwa do odpowiedniego przetestowania poprzez uporządkowanie plików. W takim przypadku po prostu wyeliminuj tę złożoność, umieść ją w klasie i napisz testy jednostkowe dla tej klasy . Całkiem prawdopodobne, że przekonasz się, że ta wspólna klasa jest użyteczna także w bazach danych, plikach xml itp.

W żadnym wypadku nie wziąłbyś podstawowego rdzenia pisanego kodu i „wyśmiewałeś” go, aby napisać testy, które przejdą, czy testowana jednostka jest błędna.

Rozumiem twoje pytanie jako „Dobry / zaakceptowany sposób przetestowania klasy zależnej od operacji systemu plików”. Nie zakładam, że chcesz przetestować system plików swojego systemu operacyjnego.

Aby utrzymać wysiłek związany z „interfejsami do operacji w systemie plików i„ wyśmiewać je ”, ponieważ sugerowana odpowiedź @Doc Brown jest tak mała, jak to tylko możliwe, dobrym pomysłem jest użycie binarnych strumieni Java lub czytnika tekstu (lub ich odpowiednika w języku c # lub używany język programowania) zamiast używania plików z nazwami plików bezpośrednio w klasie opracowanej przez TDD.

Przykład:

Za pomocą java zaimplementowałem klasę CsvReader

public class CsvReader {
    private Reader reader;

    public CsvReader(Reader reader) {
        this.reader = reader;
    }
}

Do testów wykorzystałem takie dane w pamięci

String contentOfCsv = "TestColumn1;TestColumn2\n"+
    "value1;value2\n";

CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));

lub umieść dane testowe w zasobach

CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));

W produkcji używam systemu plików

CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));

W ten sposób mój CsvReader nie zależy od systemu plików, ale od abstrakcyjnego „Czytnika”, w którym istnieje implementacja systemu plików.

Utwórz opakowanie dla operacji systemu plików. W testach przekaż próbny, który implementuje ten sam interfejs co opakowanie. W produkcji przekaż opakowanie.