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.
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...