A unidade testou “usando” o projeto ou apenas possui o mesmo espaço para nome?

fundo

Estou trabalhando em um projeto com C # .NET e acabei de adicionar um novo projeto de teste de unidade à minha solução no Visual Studio. A maneira que eu sempre faço isso é:

Crie um novo projeto de teste de unidade.
Faça com que esse projeto inclua uma referência ao projeto em teste .
Basta incluir ( using) o projeto.

Eu acho que a outra maneira que você poderia fazer isso seria ...

Crie um novo projeto de teste de unidade.
Faça com que esse projeto inclua uma referência ao projeto em teste .
Faça o projeto de teste de unidade compartilhar um espaço para nome com o projeto em teste .

Questão

Existe uma maneira aceita de fazer isso para projetos no mundo .NET ou isso é apenas uma opinião e não há mais nada?

— Snoop
fonte

Usar o mesmo espaço para nome parece uma maneira de acabar com conflitos no espaço para nome. E você ainda precisará de uma referência ao assembly que contém o código em teste.

— David Arno

Eu concordo com David. A menos que você tenha o cuidado de nomear explicitamente seus métodos de teste como algo diferente do método em teste, você corre o risco de haver conflitos de nomes. Só não vejo como compartilhar um espaço para nome traz algo para a festa.

— Robbie Dee

Se eles forem escritos corretamente, os testes nunca deverão entrar em conflito, pois os nomes dos métodos serão semelhantes MethodName_StateUnderTest_ExpectedBehavior(), e tenho certeza que você poderá encontrar nomes não conflitantes adequados para as classes de teste. A verdadeira questão é: você realmente deseja que esses tipos apareçam no seu intelecto?

— Robert Harvey

O @DavidArno TDD não é aplicável em todas as situações. Se tudo o que meu código faz é ir e ler algum dispositivo eletrônico e retornar um resultado (que é 99% do tempo para os EEs escreverem código) ... Tudo o que me interessa é se eu devo ou não obter o valor certo, nesse ponto Não importa se eu escrevo o teste antes ou depois.

— Snoop

@StevieV, minhas desculpas, isso não deveria ser um comentário sério (portanto, o rosto sorridente), mas acho que não foi assim.

— David Arno

Respostas:

Seus testes de unidade estão em um projeto separado e cumprem uma função separada do código principal; portanto, colocá-los em um espaço para nome separado faz mais sentido para mim.

Se você está pensando em colocá-los no mesmo espaço para nome apenas para salvar a usinglinha, não o faça. Menos código é bom, código mais claro é melhor.

— svick
fonte

E você não deseja liberar / distribuir / implantar testes de unidade.

— Radarbob

A colocação de testes em um espaço para nome separado garante (em alguns idiomas) que você esteja vendo a API como um consumidor de terceiros, ou seja, não acessando membros que são acessíveis apenas a classes no mesmo espaço para nome. Convenientemente, seus testes silenciarão quaisquer avisos espúrios sobre os membros públicos da API não serem referenciados ou expostos desnecessariamente.

— StackOverthrow

@TKK A questão é sobre C # e, em C #, os namespaces não funcionam assim.

— svick

@svick: sim, e o C # não o força a atribuir a cada assembly seu próprio espaço para nome. No entanto, é uma convenção útil, especialmente em projetos maiores, e eu não lidaria com um conjunto de teste de unidade de maneira diferente de qualquer outro conjunto.

— Doc Brown

Eu usei o projeto de testes de unidade com o mesmo espaço para nome do projeto real (removendo manualmente o Testssufixo no espaço para nome do projeto de teste) por alguns anos sem zero problemas.

Eu acho que isso leva a um código mais direto, então eu geralmente sugiro seguir essa abordagem. Algumas das desvantagens, como possíveis conflitos de espaço para nome, não devem ocorrer ao lidar com um projeto de teste de unidade, pois você já está seguindo algumas convenções de teste para isso, como sufocar todas as classes de teste Tests. Além disso, para mim, parece bastante intuitivo ter as classes e as classes de teste no mesmo espaço para nome.

Algumas pessoas pensam que é estranho, mas isso realmente não deve ser o caso, pois muitos assemblies de estrutura também usam essa estratégia de ter várias DLLs que têm classes nos mesmos espaços de nomes: não é uma coisa surpreendente ou ruim. praticar por si só.

Eu acho que este é mais sobre o gosto pessoal, por isso não é realmente "responsável" por si só. Dito isto, "meu voto", conforme o raciocínio acima, é tentar você mesmo primeiro e, se você gosta da abordagem, faça isso.

— julealgon
fonte