Teste de integração e cadeia de conexão de banco de dados no app.config

5

Estou trabalhando em um projeto em que SqlConnection é criado por meio de um método estático, digamos que é DatabaseAccess.GetSqlConnection() . Este método lê o arquivo .config para obter a string de conexão e cria uma conexão.

Não há problema em refatorar o código para usar ISqlConnectionCreator (ou ISqlConnectionFactory ) responsável por criar as conexões reais apenas para testar (como parece mais "pelo livro" "para mim) ou vai fácil e basta criar um arquivo .config no projeto de teste contendo seqüências de caracteres de conexão de teste?

A segunda solução parece mais propensa a erros e cria uma relação indireta entre os testes e as classes testadas.

Eu quero ter certeza de que há uma justificativa para o trabalho extra de refatoração de código para usar o criador de conexão injetada.

    
por user1713059 28.03.2015 / 17:48
fonte

2 respostas

1

De um ponto de vista pragmático, recomendo usar o que funciona melhor, com o menor esforço de manutenção.

Nesta situação específica, eu provavelmente usaria a "opção 3": separe a parte que lê a string de conexão da parte que cria a conexão real em dois métodos diferentes. Portanto, a string de conexão se torna um parâmetro de entrada do método 2 e, no seu código de teste, você pode omitir a avaliação de configuração e fornecer a string de conexão de teste como desejar, por exemplo, como parte dos dados de teste codificados. Como resultado, você não precisa nem de um arquivo de configuração de teste nem de um ISqlConnectionCreator .

    
por 28.03.2015 / 20:06
fonte
-1

Estou com dificuldades para ver o benefício desse código extra. O código é uma responsabilidade e, a menos que haja um problema real, eu provavelmente não gostaria de gastar tempo com ele.

Gostaria apenas de criar o arquivo app.config e chamá-lo por um dia.

    
por 27.07.2015 / 14:16
fonte