O programador profissional precisa de testes unitários?

cv wrote:
Pra isso que serve integracao continua.

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

cv wrote:

microfilo wrote:alteram direto o código de produção e boa.

Pra isso que serve gerencia de configuracao.

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.

cv wrote:
Pra isso que serve vodka.

Pra isso que serve violencia.

Isso não resolve o problema

cv wrote:

microfilo wrote:Acho que esse problema de não replicar a alteração em todos os artefatos não é resolvido transformando requisito em teste.

Nao?

Não

louds wrote:
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.

Concordo, mas neste caso, existiam muita mais coisas entre o céu e a terra...

louds wrote:
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.

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

This message was edited 1 time. Last update was at 04/03/2008 13:08:19

Rafael Nunes wrote:

pcalcado wrote:Qual seria a vantagem, Rafael?

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.

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:

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.

microfilo wrote: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.

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.

microfilo wrote:

rodrigoy wrote:
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.

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.

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?

microfilo wrote:
Não são perguntas provocativas, o cara quer isso e pronto! Assim que ele trabalha, assim que todos os outros fornecedores dele trabalham....

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.

microfilo wrote:
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?

Não... não rola... Discutimos isso na thread que já postei aqui.

microfilo wrote:
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.

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

microfilo wrote:
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.

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!

microfilo wrote:
Eu não disse nada sobre matriz de rastreabilidade de requisitos CMMI-like. Disse sobre rastreabilidade entre "artefatos".

microfilo a algumas páginas atrás wrote:
E em todo o caso, existem ferramentas que fazem rastreabilidade entre requisito e outros artefatos, como código por exemplo. Isso pode ajudar a equipe a manter todos os artefatos atualizados.

CMMi 1.2 wrote:
SP 1.4 Maintain Bidirectional Traceability of Requirements

Maintain bidirectional traceability among the requirements and work products.

The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. (See the definition of ?bidirectional traceability? in the glossary.) When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

Se isso não é CMMI-like, o que é?

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 618 Offline

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?

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

s4nchez wrote: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.

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?

microfilo wrote:se a equipe é desleixada o suficiente para deixar um .doc desatualizado, é possível que ela deixe um teste desatualizado também

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.

microfilo wrote: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.

Exatamente. Leia mais sobre gerencia de configuracao de software

s4nchez wrote:
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.

rodrigoy wrote:
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 é 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.

rodrigoy wrote:
Eu particularmente prefiro nem entrar no projeto se vejo que o cliente é burro

Independente se o cara sabe a melhor forma de trabalhar ou não, respeito é bom e eu (e ele) gostamos.

This message was edited 1 time. Last update was at 04/03/2008 15:20:38

cv wrote: 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.

Felizmente, os projetos onde eu tenho trabalhado atualmente não são problematicos como os ambientes que eu descrevi

cv wrote:Exatamente. Leia mais sobre gerencia de configuracao de software

Eu já li bastante sobre isso, mas não ainda não saquei o seu ponto.

rodrigoy wrote:

CMMi 1.2 wrote:
SP 1.4 Maintain Bidirectional Traceability of Requirements

Maintain bidirectional traceability among the requirements and work products.

The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. (See the definition of ?bidirectional traceability? in the glossary.) When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

Se isso não é CMMI-like, o que é?

Então isso necessariamente é algo ruim?

microfilo wrote:
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 eles usam waterfall-like, qualquer pessoa que sabe desenvolver software de verdade e já experimentou os benefícios do desenvolvimento iterativo se torna mestre para falar que eles não sabem desenvolver software. O fato do ambiente ser grande, maduro e estável não necessáriamente diz que é EFICIENTE (e geralmente não é).

Mas OK, eu tenho uma postura radical com relação a isso, e tenho pouca paciência com gestores burros que se acham os gostosões, desculpem qualquer exagero. Pode não ser muito bom para meu bolso, mas já dropei projetos por conta disso. Não é uma decisão emocional, é só um risco que não dava para aceitar (qualquer jogador de Poker ou home-broker sabe do que estou falando).

microfilo wrote:

rodrigoy wrote:

CMMi 1.2 wrote:
SP 1.4 Maintain Bidirectional Traceability of Requirements

Maintain bidirectional traceability among the requirements and work products.

The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. (See the definition of ?bidirectional traceability? in the glossary.) When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

Se isso não é CMMI-like, o que é?

Então isso necessariamente é algo ruim?

É bonito na teoria, mas na prática é um inferno. Especificações executáveis são a únicas que é viável verificar contra o software. O problema de ter toneladas de documentação é quando um requisito escapa de ser realizado na documentação (nenhuma equipe é perfeita). Com testes automatizados e um mínimo qualidade no processo esse tipo de coisa não resiste a primeira execução integrada do build. No caso de documentação no word nada garante isso.

Achar que softwares de rastreabilidade resolvem isso é sales pitch ou ingenuidade pois elas exigem toneladas de trabalho manual para serem usadas e no final até as equipes mais disciplinadas acabam fazendo vista grossa para grande parte do que acontece.

Notícias, artigos e o maior fórum brasileiro sobre Java