NET Teste de nomenclatura convenções [fechado]

Question

Quais são as melhores convenções de nomeação de teste-montagens em .NET (ou qualquer outra linguagem ou plataforma)?

O que eu estou principalmente dividido entre são estas opções (por favor, fornecer outros!):

• Company.Website - do projeto
• Company.Website.Tests

ou

• Company.Website
• Company.WebsiteTests

O problema com a primeira solução é que ele se parece com .Tests são uma sub-namespace para o local, enquanto eles realmente são mais paralelo na minha mente. O que acontece quando uma nova sub-namespace entra em jogo, como Company.Website.Controls , onde devo colocar os testes para que namespace, por exemplo?

Talvez ele deve mesmo ser:. Tests.Company.Website e Tests.Company.Website.Controls , e assim por diante

Answer 1

Eu vou com

* Company.Website - the project
* Company.Website.Tests

O curta razão e resposta é simples, testando e projeto estão ligados no código, portanto, deve compartilhar namespace.

Se você quiser divisão de código e testes em uma solução que você tem essa opção de qualquer maneira. por exemplo. você pode configurar uma solução com

-Code pasta

• Company.Website

-Testes pasta

• Company.Website.Tests

Answer 2

Eu, pessoalmente, iria com

Company.Tests.Website

Dessa forma, você tem um espaço de nomes e projetos dentro dela testes comum, seguindo a mesma estrutura que o projeto real.

Answer 3

Na verdade, tenho uma raiz paralela alternativa.

Tests.Company.Website

Ele funciona muito bem para disambiguating coisas quando você tem novas sub namespaces.

Answer 4

Eu sou um grande fã de estruturação do namespace teste como este:

Company.Tests.Website.xxx

Company.Tests.Website.Controls

Assim como você, eu acho que os testes como uma estrutura de namespace paralelo com o código principal e este fornece-lhe com isso. Ele também tem a vantagem de que, desde o namespace ainda começa com o nome da empresa que você não deve ter quaisquer colisões de nomes com bibliotecas 3rd party

Answer 5

Eu também preferem "testes" prefixando o nome real do conjunto de modo a que a sua fácil de ver todos os meus conjuntos de teste de unidade listados em ordem alfabética juntos quando eu mass-selecioná-los para puxar para NUnit ou qualquer equipamento de teste que você está usando.

Assim, se o site fosse o nome de minha solução (e montagens), sugiro -

Tests.Website.dll para ir junto com o código real de montagem WebSite.dll

Answer 6

Nós seguimos uma abordagem integrada:

Company.Namespace.Test
Company.Namespace.Data.Test

Desta forma, os testes são perto ao código que está a ser testada, sem a necessidade de activar e para trás entre os projectos ou caçar referências para garantir que há um teste que abrange um método em particular. Nós também não tem que manter duas hierarquias separadas, mas idênticos,.

Também pode testar partes distintas do código como melhorar e desenvolver-se.

Parece um pouco estranho no início, mas a longo prazo ele tem trabalhado muito bem para nós.

Answer 7

Eu costumo projetos nome de teste Project-testes para a brevidade no Solution Explorer, e eu uso Company.Namespace.Tests para namespaces.

Answer 8

Eu prefiro ir com:

Company.Website.Tests

Eu não me importo com qualquer sub-namespaces como Company.Website.Controls, todos os testes de ir para o mesmo espaço de nomes: Company.Website.Tests. Você não quer que seus namespaces teste ter que estar em parrallel com o resto do seu código, porque ele só faz refatoração namespaces levar o dobro do tempo.

Answer 9

Eu prefiro Company.Website.Spec e geralmente têm um projeto de teste per solução

Answer 10

Com MVC começando a se tornar uma realidade no mundo de desenvolvimento web .net, eu iria começar a pensar ao longo destas linhas. Lembrar que H, V e C são os componentes distintos, de modo que:

• Company.Namespace.Website
• Company.Namespace.Website.Core
• Company.Namspance.Website.Core.Tests
• Company.Namespace.Website.Model
• Company.Namespace.Website.Model.Tests

site é a sua opinião leve. Núcleo contém controladores, ajudantes, as interfaces de vista, etc. Core.Tests são seus testes para a referida Core. Modelo é para o seu modelo de dados. A coisa legal aqui é que os testes de modelo pode automatizar seus testes específicos de banco de dados.

Este pode ser um exagero para algumas pessoas, mas eu acho que isso me permite separar preocupações com bastante facilidade.