Namespace

Olá Paulo,

os testes ficarão num projeto separado do projeto com as lógicas de produção. Vamos supor que no projeto em produção na pasta/namespace Caelum.Leilao temos a classe Avaliador. Qual o jeito mais fácil e rápido de achar a classe de testes do Avaliador no outro projeto onde estão os testes NUnit? Para justamente ser rápido de achar, é interessante que a classe AvaliadorTest esteja num namespace semelhante, como Caelum.Leilao. Como são projetos separados e o projeto de testes pega a referência do projeto de produção, mas o inverso não ocorre, os testes acabam realmente ficando isolados e não interferem no código de produção.

Obrigado Lucas, também compreendi isso, o isolamento lógico, a separação física dos projetos e a rastreabilidade. Minha duvida seria algo mais relativo à expressividade arquitetural.

Estruturalmente falando, AvaliadorTest não faz parte do contexto Caelum.Leilao e sim Caelum.Leilao.Test, isso porque o teste tem um contexto diferente da produção.

Na prática, criar um projeto de teste com o nome Caelum.Leilao.Test, adicionar uma classe dentro dele e depois alterar o Namespace dessa classe para Caelum.Leilao, pra mim é tão contra intuitivo que temos que fazer manualmente no Visual Studio. Se não me engano, algumas IDE's do Java, seguindo a convenção da Oracle, não permite que o namespace esteja numa estrutura diferente da pasta.

Quando vi essa orientação no texto que fala sobre convenções na aula 2, fiquei curioso em saber porque se tratando de testes temos essa convenção.

Obrigado pela sua atenção.

Na verdade quem usa largamente este padrão de manter o mesmo namespace tanto de produção quanto de teste é justamente a comunidade do Java. Em Java, ao invés de namespace eles chamam de packages, que é praticamente a mesma coisa, só que no Java você é forçado pelo compilador que sua estrutura de pastas seja igual ao package, diferente do .net que as coisas são separadas, por mais que se recomende que siga a mesma ideia.

Só que mesmo assim, no java o package da classe Avaliador e do AvaliadorTest, por convenção, é o mesmo para facilitar a organização. O que diferencia na arquitetura o que é classe de produção e o que é teste é a Source Folder, uma pasta raiz do projeto que não aparece no package em si, serve apenas para organizar a estrutura e fazer separações como códigos de produção, testes, configurações de infra, etc.

As convenções para nome de packages do java é diferente do namespace do c#, mas se a gente fosse usar o namespace Caelum.Leilao do c# num projeto Java, ficaria mais ou menos assim a estrutura das pastas:

pasta src    (pasta raiz)
    pasta main    (subpasta raiz)
        pasta Caelum    ("namespace")
            pasta Leilao    ("namespace")
                classe Avaliador
    pasta test    (subpasta raiz )
        pasta Caelum    ("namespace")
            pasta Leilao    ("namespace")
                classe AvaliadorTest

Assim, o namespace/package tanto do Avaliador quanto do AvaliadorTest ficariam o mesmo Caelum.Leilao dado que, nas regras de negócio, os dois são referentes a mesma parte de um projeto Leilao. E o que demarca na arquitetura é a pasta e subpastas raiz onde ele está localizado e para as classes de teste termo Test no final do nome. Desta forma, a organização fica espelhada dado que no fundo um teste nada mais é do que um reflexo do que ocorre em produção.

Só que em .Net, como não existe este conceito de Source Folder, uma adaptação é numa Solution separar por projects diferentes, um de produção (que meio que seria a "src/main" do java) e um de testes (que seria a "src/test" do java).