De acordo. No meu projeto solo por exemplo nao uso integracao continua e Collective Code Ownership.
Bem, fugindo um tanto do assunto, mas ainda falando nele:
E se os testes tivessem comentários, e destes comentários fosse gerada uma documentação?
Tipo:
@Documentacao("RF1.2 - blablablabablablabablababla")
public void metodoTestaDocumentaEFazCafe(){
//xxx
}Aliás, existe alguma ferramenta que faça isso?
Qual seria a vantagem, Rafael? O benefício de testes é que a descrição dos requisitos não pode estar desatualizada ou o build não passa.
Se você apenas mudar a documentação textual de lugar só vai usar o Eclipse ao invés do OpenOffice.
Seria um tanto mais prático para lugares que exigem ter um maldito .doc/.pdf/.html com os requisitos em papéis.
Tava só divagando aqui mesmo.
Creio que não entendi aqui.
O que você se refere com ‘descrição do requisito’? Um documento?
[quote=Rafael Nunes]
Creio que não entendi aqui.
O que você se refere com ‘descrição do requisito’? Um documento?[/quote]
[quote=pcalcado]
[…]Mas atualmente eu estou referindo o StoryRunner:
Scenario "file is already in registro's format" do
Given "A file in Registro's format"
And "A parser for log files in DSL"
When "Parser parses file"
And "The resulting DSL lines are interpreted"
Then "A timeline should be created with all entries in the file"
end
[/quote]
Essa é a típica pergunta que um cliente frustrado com fábrica de software faz. Depois da segunda iteração, se você conseguir ficar parceiro dele essas perguntinhas provocativas tendem a desaparecer.
Lembra que falei aqui a minha frustração com ambiente EJB3 com relação a TDD? Dá para rodar no Microcontainer, mas é lento. Cada rodada de teste demora de 10-20 segundos. Ninguém para muito pra pensar nisso, mas é simplesmente ridículo que o EntityManager demore 10 segundos para subir com um mapeamento de umas 100 entidades.
Colocaria isso num requisito? Como assim? Num texto? Num dicionário de dados? :shock: XP, DDD, MDA, DSLs, no fundo, tudo isso tenta fazer com que tenhamos menos “layers” nos nossos artefatos, aproximando o software do negócio. Se a tecnologia permite hoje que a visão lógica e a visão fisica seja a mesma, porque não juntar a necessidade à solução? Você não sonha um dia ter uma ubiquitous language implementada numa DSL ou PIM que resolva o negócio de maneira executável?
Acho que o CV já respondeu isso da melhor maneira possível… dá margem a criar o VDD (Vodka-Driven Development). TDD não resolve tudo. XP não resolve tudo. Nem mesmo a computação resolve tudo. Não procure a bala de prata.
[quote=microfilo]
Sim… já vi utilizarem isso. A quantidade gasta em ferramentas depende do tamanho da equipe. Muita gente não se importa de investir alto em ferramentas pagas que resolvam o seu problema.[/quote]
Cara, na boa, deve ser meio caro desenvolver software na tua visão… como falei, matriz de rastreabilidade de requisitos CMMI-like não é problema para equipes ágeis, então, não precisamos dessas ferramentas.
Isso acontece em equipes que não tem compromisso com o software que estão produzindo. O infeliz que subiu código sem passar pela suíte de testes e os demais membros da equipe que não cobraram dele o fato. Contra cultura ruim e burrice não tem muito para ser feito, nem o JCDD tem alguma chance. Ou a equipe tem compromisso e atitude no sentido de produzir resultado de boa qualidade ou automação de testes só vai ser mais um passo inútil no processo.
Pela minha experiência, a equipe é encorajada a chamar a atenção daqueles que quebrarem o build. Isso é saudável e normalmente acaba aumentando o comprometimento do time. Por isso que posse coletiva de código é fundamental, pois o outro não fez besteira no código dele, mas cagou o seu.
[quote=microfilo][quote=cv]
Se um programador olhar pras assinaturas dos metodos e souber o que os testes estao tentando provar, ele tb entende os requisitos daquela unidade que esta sendo testada.
[/quote]
Certo, eu tenho a visão dos requisitos daquela unidade sendo testada, e da visão do todo? Dos requisitos como um todo?[/quote]
Para isso existem os outros testes, que não são de unidade.
[quote=pcalcado]
[…]Mas atualmente eu estou referindo o StoryRunner:
Scenario "file is already in registro's format" do
Given "A file in Registro's format"
And "A parser for log files in DSL"
When "Parser parses file"
And "The resulting DSL lines are interpreted"
Then "A timeline should be created with all entries in the file"
end
[/quote]
Não são perguntas provocativas, o cara quer isso e pronto! Assim que ele trabalha, assim que todos os outros fornecedores dele trabalham!
Acho que a questão é: se o cara te contratou, você tem que trabalhar nos termos dele, fazendo o máximo para entregar o software com qualidade. Não é por que o cara te obriga a usar Use Case e use case tem a tendência de ficar desatualizado que eu vou deixar ser descuidado e efetivamente deixar o use case ficar desatualizado! Não da para querer mudar a cultura do cliente. O cara quer ser atendido de uma determinada maneira, se der para mostrar para ele como funciona o agile e ele gostar, ok, ótimo, se ele quiser usar waterfall da vida, eu prefiro atender ele nos termos dele.
Não rola só rodar os testes unitários “leves” em quanto desenvolve e deixar os testes mais pesados para rodarem uma vez por madrugada?
Dependendo do caso, colocaria num texto da documentação do requisito - não ficaria detalhando informações sobre a minha estrutura de tabelas num documento de requisitos.
Eu acho que uma equipe deisleixada o suficiente para deixar a documentação de requisitos desatualizada também poderia deixar os testes desatualizados. O problema não é ser um documento word em si, o problema é o desleixo mesmo. É lógico que der 300 mil tipos de documentação não ajuda.
[quote=rodrigoy]
Cara, na boa, deve ser meio caro desenvolver software na tua visão… como falei, matriz de rastreabilidade de requisitos CMMI-like não é problema para equipes ágeis, então, não precisamos dessas ferramentas.[/quote]
Eu não disse nada sobre matriz de rastreabilidade de requisitos CMMI-like. Disse sobre rastreabilidade entre “artefatos”.
Acho que eu já me expressei no post acima: se a equipe é desleixada o suficiente para deixar um .doc desatualizado, é possível que ela deixe um teste desatualizado também
Gerencia de configuração não ajuda aqui. Quando eu me referi a código de produção, eu quis dizer o código normal, excluindo os testes.
Isso não resolve o problema
[quote=cv]
Nao? :mrgreen:[/quote]
Não 
[quote=louds]
Isso acontece em equipes que não tem compromisso com o software que estão produzindo. O infeliz que subiu código sem passar pela suíte de testes e os demais membros da equipe que não cobraram dele o fato. Contra cultura ruim e burrice não tem muito para ser feito, nem o JCDD tem alguma chance. Ou a equipe tem compromisso e atitude no sentido de produzir resultado de boa qualidade ou automação de testes só vai ser mais um passo inútil no processo.[/quote]
Concordo, mas neste caso, existiam muita mais coisas entre o céu e a terra…
[quote=louds]
Pela minha experiência, a equipe é encorajada a chamar a atenção daqueles que quebrarem o build. Isso é saudável e normalmente acaba aumentando o comprometimento do time. Por isso que posse coletiva de código é fundamental, pois o outro não fez besteira no código dele, mas cagou o seu.[/quote]
Ah, isso é legal Numa equipe na qual eu trabalhei, tinha uma abacaxi de brinquedo que a pessoa que quebrava a build ganhava e ficava com ele em sua mesa até uma outra pessoa quebrar a build.
Outra prática legal que eu vi em um treinamento de SCM é fazer com que o cara que quebre a build assuma o papel de build master 
Seria um tanto mais prático para lugares que exigem ter um maldito .doc/.pdf/.html com os requisitos em papéis.
Tava só divagando aqui mesmo.[/quote]
No caso de projetos Java que já possuem uma suite de testes boa, se existisse alguma coisa que pudesse ler as classes da sua suite e através dos métodos gerasse um HTML com a spec seria interessante para apresentar para quem não vai ler o código mas precisa de outros tipos de documentos.
Ex:
class EstoriaXXX {
public void testDeveFazerAbcERetornarXYZ() {
//Teste
}
public void testDeveRetornarXpto() {
//Teste
}
}Esse código poderia ser lido e gerado um HTML ou qualquer outro tipo de arquivo usando o nome da classe como User [Story|Use Case|Coloca seu nome favorito aqui] e cada método as funcionalidades desta. Poderia ser usado Camel Case como convenção para separar acrescentar os espaços ou um underline, ou qualquer outra coisa. O interessante é que para projetos com suites de teste já prontas adiantaria muito.
Ficaria assim a documentação:
- Estoria XXX
- Deve fazer abc e retornar XYZ
- Deve retornar xpto
Podendo usar templates, css e toda parnafenalha que desejar.
Hoje em dia é melhor procurar outras alternativas como RSpec. Mas de qualquer forma o JUnit ainda serve bastante sem sombra de dúvidas.
O fato é que eu estou pra conhecer um bom programador que goste de documentar alguma coisa. No caso dos testes como especificação, ao perceber que aquilo de fato “executa” e te ajuda a guiar o Design da sua aplicação, facilitando o seu trabalho, o programador tende a encarar a coisa de forma completamente diferente do que um documento do word.
Testes unitários defasados retornam erro num click de botão, ou a cada commit no CVS/Subversion.
Documentação defasada retorna confusão quando alguem resolve ler a sério.
[quote=microfilo][quote=rodrigoy]
Essa é a típica pergunta que um cliente frustrado com fábrica de software faz. Depois da segunda iteração, se você conseguir ficar parceiro dele essas perguntinhas provocativas tendem a desaparecer.
[/quote]
Não são perguntas provocativas, o cara quer isso e pronto! Assim que ele trabalha, assim que todos os outros fornecedores dele trabalham!
Acho que a questão é: se o cara te contratou, você tem que trabalhar nos termos dele, fazendo o máximo para entregar o software com qualidade. Não é por que o cara te obriga a usar Use Case e use case tem a tendência de ficar desatualizado que eu vou deixar ser descuidado e efetivamente deixar o use case ficar desatualizado! Não da para querer mudar a cultura do cliente. O cara quer ser atendido de uma determinada maneira, se der para mostrar para ele como funciona o agile e ele gostar, ok, ótimo, se ele quiser usar waterfall da vida, eu prefiro atender ele nos termos dele.
[/quote]
Se você engole qualquer coisa só pra fechar contrato ou acredita que seu cliente sabe mais de desenvolvimento do que você, só posso desejar boa sorte na hora de entregar o seu produto final.
Apropósito, essa é a sua posição ou da empresa onde você trabalha?
O bom fornecedor entrega aquilo que o cliente precisa não o que ele pede. Pode ter um gap muito grande entre esses dois. Não à força, mas pode ter certeza que quando uma montadora, um hospital, uma indústria chega pra você e pede “quero casos de uso, quero UML, quero Java, quero BPM, quero CMMI-like” eles não têm a mínima noção do que são essas coisas. É um mito que se criou no mercado. O que eles querem é uma solução para problemas de negócio. A incapacidade de certos fornecedores de separar aquilo que é problema deles dos problemas do cliente fez essa confusão toda acontecer, inclusive a aberração do Waterfall. Eu particularmente prefiro nem entrar no projeto se vejo que o cliente é burro e depois vai querer me usar como bode expiatório.
Não… não rola… Discutimos isso na thread que já postei aqui.
Tá bom, mas saiba que você não precisa dessa ambiguidade. Um diagrama de classes pode ser um documento de requisitos, um MER pode ser requisitos, uma anotação pode ser um requisito. Se o requisito é executável eu não preciso de matriz nenhuma.
http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm#ExecutableRequirements
Sim… já comentei sobre isso! Cara, é mais difícil jogar a poeira pra baixo do tapete com EMMA, TDD. Documento Word aceita qualquer porcaria que você escreva!
[quote=microfilo]
Eu não disse nada sobre matriz de rastreabilidade de requisitos CMMI-like. Disse sobre rastreabilidade entre “artefatos”.[/quote]
Se isso não é CMMI-like, o que é?
Se o cliente pagar por isso, não vejo problema em documentação não executável.
Suite de testes é bom senso da empresa desenvolvedora, implica na qualidade de seu produto e melhor entendimento dos códigos pelos desenvolvedores.
Temos no manifesto ágil a prioridade de sofware em funcionamento que documentação abrangente, porém temos também priorizar colaboração com o cliente do que negociação de contratos. Se o cliente pede e faz questão de documentação .pdf, e paga por isso, pq não colaborar com ele?
Olá s4nchez,
como assim engolir? Na realidade não vejo muita opção. Pelo menos tenho visto mais clientes que acham que sabem mais que o a equipe de desenvolvimento do que desenvolvedores agilistas. O único lugar que vejo desenvolvedor agilista é em fórum de discussão, reuniões e eventos. Fora isso, conto nos dedos da mão direita os programadores que conheci pessoalmente que ao menos usassem TDD.
Enfim, qual é a dica para se dar ao luxo de não engolir as situações citadas pelo Rubem? :mrgreen:
Com integracao continua e medicao de cobertura de testes nao da pra “deixar um teste desatualizado”. Cabe a equipe se policiar, mas aparentemente as equipes onde vc trabalha preferem ser tratadas como criancas, entao talvez a gerencia do projeto tenha que acordar pra vida, tambem.
Exatamente. Leia mais sobre gerencia de configuracao de software
Não é questão de engolir qualquer coisa… Bom, os clientes muitas vezes são empresas de TI ou que possuem ambientes de desenvolvimentos grandes, maduros e estáveis - muitas vezes ambientes de desenvolvimento que funcionam razoavelmente bem usando waterfall-like. Então eles acreditam ter um grande know-how em desenvolvimento de software - quem somos nós para falar que eles não têm?
Se ele falou que quer a coisa assim ou assado e você acha que não é a melhor maneira, não acho que seria correto simplesmente rejeitar o projeto - as vezes com o tempo você consegue até mostrar as vantagens de outras abordagens - soa até arrogância, eu acho…
Basicamente isso, se o cara tem um forma de trabalhar, não quer mudar no primeiro momento, entao sigamos o processo do cara. Se ele quiser que a gente melhore o processo do cara, a gente melhora :).
Até existem clientes que aí oque eles realmente querem que você faça, não improta como, ele define o que e você define como. Aí é bem interessante, já surgiu algumas execuções utilizando agile quando isso acontece - as vezes o cliente contrata para ajudar a defin ir o seu processo interno, aí são outros quinhentos.
Independente se o cara sabe a melhor forma de trabalhar ou não, respeito é bom e eu (e ele) gostamos.