Test Driven Development: Uma maneira boa / aceita de testar as operações do sistema de arquivos?

14

Estou trabalhando em um projeto no momento que gera uma tabela (entre outras coisas) com base no conteúdo de um sistema de arquivos e, por sua vez, faz algumas modificações nos meta-dados sobre as coisas que ele encontra. A questão é: como os testes devem ser escritos em torno disso ou configurar? Existe uma maneira fácil de zombar disso? Ou devo configurar um "sandbox"?

    
por Kirbinator 07.10.2013 / 05:31
fonte

5 respostas

13

Como você sempre faz em TDD com recursos externos: você cria uma ou mais interfaces para as operações do seu sistema de arquivos e "zomba delas". Você quer testar seu "gerador de tabelas" e seu código de modificação de meta-dados, não as operações do sistema de arquivos em si (provavelmente você está usando implementações de bibliotecas prontas para acessar o sistema de arquivos).

    
por 07.10.2013 / 08:07
fonte
10

O que há de errado em ter um sistema de arquivos "teste"?

Crie uma pasta de modelos / estrutura de diretórios que tenha conteúdo suficiente para testar suas operações.

Durante a configuração da sua cópia de teste de unidade, esta estrutura inicial (recomendaria que você feche o modelo e descompacte na área de teste). Execute seus testes. Exclua a coisa toda durante a derrubada.

O problema com o mocking é primeiramente sistemas de arquivos, sistemas operacionais e bancos de dados que pertencem ao seu projeto realmente não se qualificam como recursos externos e, em segundo lugar, debater as chamadas de sistema de baixo nível é demorado e propenso a erros.

    
por 07.10.2013 / 10:13
fonte
2

Eu entendo sua pergunta como "Uma maneira boa / aceita de testar uma classe que depende das operações do sistema de arquivos". Eu não presumo que você queira testar o sistema de arquivos do seu sistema operacional.

Para manter o esforço de 'interfaces com as operações do seu sistema de arquivos e' ridicularizá-las '' como @Doc Brown answer sugeriu o menor possível, é uma boa idéia usar java binary streams ou leitor de texto (ou outro equivalente em c # ou a linguagem de programação que você está usando) em vez de usar arquivos com nomes de arquivos diretamente em sua classe desenvolvida pelo tdd.

Exemplo:

Usando java eu implementei uma classe CsvReader

public class CsvReader {
    private Reader reader;

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

Para testes eu usei em dados de memória como este

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

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

ou inclua testdata nos recursos

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

Na produção eu uso o sistema de arquivos

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

Dessa forma, meu CsvReader não depende do sistema de arquivos, mas de uma abstração "Reader", onde existe uma implementação para o sistema de arquivos.

    
por 07.10.2013 / 17:07
fonte
2

Esse é o tipo de coisa que você definitivamente precisa para o teste de integração, já que os sistemas de arquivos do mundo real têm todo tipo de comportamento estranho (como o Windows não permite excluir um arquivo se algum processo, incluindo o deleter, aberto).

Portanto, a abordagem do TDD é escrever primeiro o teste de integração (o TDD, estritamente falando, não possui conceitos distintos de 'teste de unidade' e 'teste de integração'; são apenas testes). Muito provavelmente isso será suficiente; então trabalho feito, pare, vá para casa .

Se não, haverá alguma complexidade interna que não é fácil de testar adequadamente, organizando os arquivos. Nesse caso, você simplesmente elimina essa complexidade, coloca-a em uma classe e escreve testes de unidade para essa classe . Muito provavelmente você descobrirá que essa classe comum é utilizável no banco de dados, arquivo xml, etc. casos também.

Em nenhum caso você pegaria o núcleo fundamental do código que você está escrevendo e 'zombaria' para escrever testes que passarão se a unidade sob teste está errada ou não.

    
por 08.04.2015 / 23:55
fonte
0

Crie um wrapper para as operações do sistema de arquivos. Nos testes, passe uma simulação que implemente a mesma interface que o wrapper. Na produção, passe no invólucro.

    
por 07.10.2013 / 08:15
fonte