Uma boa prática é sempre analisar projetos open source e comparar com a forma que trabalhamos, com tais comparações conseguimos absorver conhecimento e experiência que pode ser útil nos nosso projetos, recentemente Anderson Fraga, no fórum Tectura, iniciou uma discussão onde ele faz um questionamento familiar para muitos desenvolvedores, ele comparou a declaração de métodos e classes do projeto Restfulie e viu que no projeto foi usado nomes curtos e expressivos.
Diante disso, tenho uma curiosidade: o que vocês estabelecem como padrão para usarem nos models? Nomes curtos (e.g. class User, método buscar) ou nomes mais complexos e descritivos, semelhantes aos recomendados para TDD (e.g. class User, método buscarPeloId). Qual idéia/metodologia vocês usam?
As vezes a expressividade prejudica a legibilidade, como no caso:
@TestverificaSePodeHabilitarNovoRegistroPassandoParametroInvalido(){}
acho q tudo deve ser um balanceamento entre expressividade e legibilidade
it "deveria enviar um email caso ocorra um erro" doend
public class GerenciamentoClientesManagedBeanTest {@Test public void filtrandoClientes(){dadoQueEstouAcessandoComoGerenteDaLoja();eEstouGerenciandoMeusClientes();ePossuoClientesCadastrados();quandoInformarCriteriosDeBusca();eSolicitarPesquisaPorClientes();oSistemaDeveriaApresentarAListaDeClientes();masSeEuNaoTiverClientesParaOsCriteriosInformados();eSolicitarPesquisaPorClientes();oSistemaDeveriaExibirMensagem("Não a Clientes para os critérios informados");masSeAlgumCampoDoCriterioDeBuscaFoiInformadoIncorretamente();eSolicitarPesquisaPorClientes();oSistemaDeveriaEmitirMensagem("Informe Critérios de busca corretamente");masSeEuEstiverComAlgumErroNoSistemaDeBuscasPorClientes();eSolicitarPesquisaPorClientes();oSistemaDeveriaExibirMensagem("Erro no sistema, não foi possível efetuar busca");oSistemaDeveriaLogarOErroNoLog();}}
@Testpublic void addACardInAnIteration() {given.thereIsAnUserNamed("sergio").and().thereIsAProjectNamed("IEs4Linux").ownedBy("sergio").withACardNamed("support IE8").planningCard().whichDescriptionIs("IE8 must be supported").and().withAnIterationWhichGoalIs("new release").and().iAmLoggedInAs("sergio");when.iOpenProjectPageOf("IEs4Linux").and().iOpenThePageOfIterationWithGoal("new release").and().iAddTheCard("support IE8").inThisIteration();then.theCard("support IE8").appearsOnList("iteration_cards");}
Como a sugestão que o Lucas deu, componha um comportamento longo por diversos comportamentos menores.Existem diversos padrões para fazer isso como neste post do blog da Caelum.
Comentários da comunidade
Interessante...
by Mayck Xavier /
Desprenda-se de convenções de nomenclatura em nomes de testes
by Prodis a.k.a. Fernando Hamasak... /
Interessante...
by Mayck Xavier /
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Parei pra pensar nesse assunto há algumas semanas atrás. Meus métodos estavam ficando com nomes bastante grandes, e como o projeto também é grande, depois de algum tempo me deparei com vários métodos fazendo a mesma coisa.
Achei muito interessante também o modo como a Cecília escreveu os métodos. Tentarei utilizar esse modo sempre que possível.
Desprenda-se de convenções de nomenclatura em nomes de testes
by Prodis a.k.a. Fernando Hamasak... /
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Acredito que o nome de métodos de testes precisam ser bem expressivos, para qualquer um bater o olho e já saber do que se trata o teste. Uma alternativa para melhorar a visibilidade de nomes de métodos de testes longos é não utilizar a convenção de nomenclatura de métodos de Java ou C#.
No exemplo do Geraldo Ferraz, o nome do método de teste poderia ser escrito assim:
Há quase um ano atrás escrevi a respeito no meu blog:
prodis.pro.br/2009/11/21/desprenda-se-de-conven...