Onde defino pontos de extremidade do cliente WCF em um projeto de teste?

5

Eu tenho uma biblioteca de classes - chamo de Services.dll - que é um wrapper para algumas funcionalidades de terceiros. O terceiro nos deu um monte de DLLs e as DLLs "internas" chamam um serviço WCF.

Normalmente, quando Services.dll está em execução, ele reside no processo do site e usa o web.config associado ao site. Então, quando eu quero definir os pontos de extremidade do cliente WCF, eu edito o web.config. Isso é muito simples.

Mas agora quero escrever um conjunto de testes de integração automatizado. O projeto de teste é, naturalmente, uma biblioteca de classes (vamos chamá-lo de Services.Tests.dll ), portanto, será necessária a configuração definida para o processo de hospedagem. Mas eu acho que no caso de um projeto de teste, o processo de hospedagem é o próprio Visual Studio. O projeto de teste certamente não emite um .exe próprio.

Então, onde defino os pontos de extremidade do cliente WCF para o projeto de teste? Qual arquivo de configuração eu edito? Eu edito devenv.exe.config ? Eu configuro algum tipo de arquivo de configuração "satélite" (por exemplo, Services.Tests.dll.config )? Se sim, como faço para que o executor de testes do Visual Studio escolha a configuração?

Ou ... existe uma maneira de fazer isso sem configuração, interceptando / zombando de chamadas para System.Configuration ? Infelizmente não posso alterar as DLLs de terceiros.

Ou .. eu substituo com algum uso inteligente de ServicePointManager , para que a configuração não seja um problema? Não sei como eu faria isso.

Ou ... a melhor prática é escrever um projeto de teste de integração não como uma biblioteca de classes, mas como um .exe, com seu próprio app.config?

Por favor, note-- não estou executando testes unitários (separados). Esses são testes de integração, então não quero isolar as chamadas do WCF. Eu preciso deles e preciso que eles sejam configurados para apontar para os servidores de teste certos.

    
por John Wu 20.04.2017 / 04:33
fonte

2 respostas

3

Existe um truque simples que você pode usar.

O Visual Studio carregará o app.config para o projeto de teste em seu processo de host, se estiver presente. No entanto, os projetos de teste geralmente não possuem app.configs. Você pode forçar o visual studio a criar um adicionando configurações ao seu projeto:

  1. Clique com o botão direito do mouse no seu projeto e selecione "propriedades".
  2. Vá para a opção "Configurações", na barra à esquerda.
  3. Insira qualquer coisa nesta página. Apenas qualquer coisa funcionará.
  4. Salve o projeto.

Agora, você verá que seu projeto de teste agora tem um arquivo app.config. Basta adicionar seus pontos de extremidade / ligações do WCF e você é bom.

    
por 22.04.2017 / 16:18
fonte
0

Minha solução favorita para projetos de teste como o seu, é manter vários modelos de arquivos .config, usando o SlowCheetah para alterar os arquivos de configuração principais, dependendo da configuração da compilação.

link

Foi um pouco difícil manter os testes na mesma base de código-fonte, direcionando ambientes como localDev, Dev, QA, Stage e Prod (com seleção de teste também) apenas alterando a configuração de construção (que pode acontecer automaticamente em ambientes de construção contínua) )

Dessa forma, o executor de testes sempre obtém o mesmo arquivo .config, mas o arquivo de configuração é alterado dependendo de qual configuração é construída.

    
por 26.04.2017 / 00:20
fonte