Tag Archives: Test

Palestra TDD com Javascript na FA7

Amanhã, 11/04/2011, palestrarei no evento “8.ª Jornada CETI – Cursos de Extensão em Tecnologia da Informação” na FA7, sede do BrazilJS.

Titulo: Test Driven Development com Javascript
Resumo Original:  Entenderemos que só TDD é o caminho e a luz da escrita de um bom software, será demonstrado como até em plataformas difíceis se pode praticar essa metodologia, admitir que testes em TDD é apenas um benefício e não a causa, além de códigos e mais códigos.

Ah, será duas vezes:

Manhã

Data: 11/04/2010, segunda-feira
Horário: 07h30
Local: Auditório do Curso de Direito

Noite

Data: 11/04/2010, segunda-feira
Horário: 19h
Local: Auditório do Curso de Direito

Typically chemist’s shop can sale to you with discreet treatments for various heartiness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a highly complicated matter. Matters, like “coupons for viagra“, are connected numerous types of heartiness problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile malfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a recipe is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

Sem tempo suficiente

Recentemente, em um determinado projeto, tínhamos uma semana para disponibilizar uma versão e uma timeline definida por motivos externos que não poderíamos furar. O problema era que toda modificação gerava ainda mais medo por conta da baixa cobertura de testes, praticamente estavam codificando e corrigindo nessa altura do campeonato.

Eu radicalmente sugeri um grande refactoring para corrigir nossa bateria de testes, uma parada faltando apenas uma semana para entrega, mas só assim voltaríamos a trabalhar na entrega das features.

Nesse momento, o clássico “Não temos tempo para isso” surgiu das profundezas do inferno.

Fiquei sozinho nessa decisão, o time inteiro foi contra. Na defesa da solução apresentada eu falei: “Vocês podem se enganar imaginando que podem entregar essa release em uma semana com a qualidade do código existente que vocês sabem que vai de mal a pior ou podem trabalhar para corrigir esses problemas e entregar o possível, mas funcionando”.

Sabemos da importância de testes, todas as metodologias os cobra obrigatoriamente, então se você não testa, você está errado em todas as metodologias. O problema sempre é a desculpa da timeline e quanto mais vai se aproximando mais desculpas procuramos encontrar para esconder as deficiências. Como nesse caso não tínhamos Test First, os problemas vão se empilhando no final e se tornam mais difíceis de serem detectados.

Por sorte, minha sugestão acabou sendo acatada, apesar de ser apenas um consultor no projeto, portanto uma galinha e não porco.

De onde nascem essas desculpas?

Coragem é um dos valores do XP, é importante enfrentarmos esse tipo de situação que descrevi, na vida real isso quase nunca é possível porque essas arquiteturas flácidas ou códigos mal cheirosos não nascem do dia para o outro e vão se acumulando.

O projeto que descrevi era um projeto novo, tecnologias fresquinhas e um time modernoso. Imagina agora se você está em uma corporação que usa um processo cascata, todo amarrado, criando documentos UML desnecessários no EA, struts 1 como framework, CVS como controle de versão do código [quando há! Sim, em pleno 2010 ainda há quem não use nenhum], o código de banco de dados cheio de procedures e tantas modernidades da década de 80.

Então, acha que só coragem basta?

Em muitas oportunidades o custo de mudanças ou simplesmente “fazer o que se tem que fazer” não se pagará nem a médio prazo, nessas horas convencer já não basta. É muito difícil você convencer a alta direção que deve jogar fora um determinado projeto e começar do zero, ou modificar toda a infraestrutura existente.

A degradação de um software nasce de pequenos problemas que se acumulam, no final há tanto para se fazer que ninguém mais tem coragem para isso.

Socorro, Milfont!

Recebo constantemente pedido de socorro de pessoas que me conhecem das comunidades que participo como XPCE, GURU-CE, JAVA-CE, entre outras. Geralmente são funcionários que se encontram nessa situação que citei anteriormente, com projetos muito defasados e problemáticos.  O pedido é sempre o mesmo, querem que eu vá lá dizer para a alta direção o que eles [funcionários] já sabem. Só que isso não basta, o movimento tem que começar por lá.

Em reunião com a turma da TriadWorks, temos discutido isso já há muito tempo e acabamos preparando um serviço de resgate aos clientes para contornar esse problema. A proposta é envolver as pessoas desses clientes, dar coragem e ânimo nelas para começarem a resolver o problema.

Resolvemos começar com nossos próprios clientes, sim, dá preferência a quem tem contrato conosco e depois verificar como abrir para a comunidade.

Então, esse envolvimento nós demos o codinome de “AvoidNotEnoughTime” e consiste basicamente em um conjunto de ações/eventos  com os funcionários dessas empresas para dar essa força necessária para anular o NotEnoughTime na base. É um movimento de baixo pra cima, roots, serão desde Coding Dojos, Code Retreat, Code Jam, Hack Days, Lightning Talks, Open Space ou um formato adequado a um determinado problema que identificarmos.

Nós não vamos cobrar a mais dos clientes por isso, aliás, eles nem foram avisados e não terão controle sobre o projeto, nós que decidimos quando, como e com quem faremos justamente para evitar sabotagem ou direcionamento.

Sem planejamento nem nada, resolvemos iniciar mesmo assim, domingo passado [27/06/2010] realizamos um Git Session onde eu [@cmilfont], @triadworks representada por @handersonbf, @rponte e @carlosatilabreu, recebemos funcionários de clientes nossos. @jeffersongirao da TubForm, @rodrigogalba da Casa Magalhães e @rodrigodealer da Fortes Informática.

O que vocês ganham com isso?

Resolvemos fazer um Git Hack Session devido alguns de nossos clientes usarem CVS e SVN. O tempo perdido resolvendo problemas de repositório como merges e bobagens simples causam um prejuízo enorme, as desculpas para mudarem cai sempre no “não temos suficiente” ou “depois fazemos quando terminar esse projeto”.

Então cada ponto de dificuldade que um time enfrenta e observarmos que se repete nos demais clientes, vamos organizar ações para envolver essa turma afim de anular essas desculpas. Treinar multiplicadores em todos os princípios.

No caso do Jefferson Girão, que trabalha também para a Hoodiny, veio mais para nos auxiliar, já que está mestre no uso do git no meu cliente Tubform [uma das maiores indústrias do Nordeste].

Dessa forma nosso trabalho de consultoria será facilitado e no mínimo já faríamos esses eventos internamente, então unimos o útil ao agradável.

Se você gostaria de participar de algum desses eventos mesmo não sendo funcionário de cliente nosso, mande um email para mim [cmilfont@gmail.com] e tentaremos incluir sempre quando puder. Domingo agora surgiu um desfalque, até twittei convocando alguém que estivesse disponível, mas foi em cima da hora.

Começou #gitsession on Twitpic

Typically chemist’s shop can sale to you with discreet treatments for various heartiness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a highly complicated matter. Matters, like “coupons for viagra“, are connected numerous types of soundness problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may turn on erectile malfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a recipe is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

Na teoria, é você quem não conhece a prática

O Dr Alan Kelon [ou quase dr., não sei se já terminou] com a arrogância clássica da academia deu uma aula de engenharia de software a esse pobre AMADOR SEM EDUCAÇÃO que vos escreve.

Se eu fosse um novato, recém integrado na faculdade, sem base acadêmica para duvidar de um Dr. [ou quase] eu estaria destruído com minha ignorância.

Esse é o temor que tenho da academia, a sua falta total de pé-no-chão ou conhecimento real daquilo que ensina, é o que me fez abandoná-la e nunca mais pisar por lá.

Tantas citações a obras importantes é típico da academia, mas o discurso que eu gostaria de ouvir não existe:

“Quando eu implantei CMMi na XPTO…”

“Quando eu trabalhava com RUP, nós…”

Alan Kelon

Na prática a teoria é outra

Caro Dr., eu estudei muito sobre isso, li todos esses documentos e até cheguei já a acreditar que eram válidos para garantir a qualidade de um produto. Claro, isso no início desse século quando eu era estagiário e sem conhecimento real.

Depois de passar por implantação de CMMi mais de uma vez, ISO e Mps.Br, foi que aprendi o valor da teoria e como aquilo que está escrito não reflete a realidade na “engenharia de software”.

Talvez o que mais me marcou em verificar que não existe engenharia de software [ou ela é ainda muito incipiente] foi ter participado de avaliações ISO em outros setores como indústria, imobiliária e serviços. Fica evidente para todo mundo que a avaliação nesses setores é de processo e não de produto e serviço porque eles tem métricas reais e aplicáveis em suas industrias.

Quando CMMi ou ISO falam em qualidade de produto eles não dizem como fazer e sim o que fazer, essa é a diferença básica entre processo e produto, caro Dr.

Essa bobagem semântica  faz toda a diferença, quando eu avalio a qualidade de um produto como uma garrafa PET, existem métricas reais para testar a qualidade [como por exemplo durabilidade], existe um processo normatizado por órgãos [como ANATEL, ANVISA, e tantos outros] que garantem a qualidade mínima do produto ou serviço.

Esse foi o seu primeiro erro conceitual, dizer que tem que fazer é diferente de dizer “como” tem que fazer. “O que” é processo, DR. “Como” é produto, Dr.

Testes de Software

Vou fazer um mea-culpa porque quando escrevo eu sempre esqueço que meus leitores não me conhecem e não podem advinhar o que fica nas entrelinhas, eu não gosto de citar referências por preguiça de sair catalogando nomes de livros e autores [só quando lembro na integra de cabeça e acho importantissimo] e espero que as pessoas não acreditem em uma só linha sem verificar. Como vão verificar, eles acham a referência por si só, não preciso colocar bibliografia nos meus textos.

Esse trecho fica evidente que falho por omissão:

Há controvérsias sobre testes automáticos garantirem qualidade interna, na verdade, não vejo onde há relação direta. Testes são sim de suma importância, independentemente de serem automatizados ou não, que fique claro, mas não garantem totalmente a qualidade, nem externa e muito menos interna (em breve explicarei o porquê), muito menos é o único método para se conseguir qualidade. Inspeções e revisão de software (e especificações associadas), juntamente com analisadores estáticos, são tão efetivos quanto testes na detecção de defeitos e tem possibilidade maior de melhorar a qualidade interna de produtos de software.

Quando falo em testes, é óbvio para quem me conhece que estou me referindo sobretudo a TDD e também BDD. Testes por si só não garantem nada, nem sequer que as falhas estão cobertas.

O processo de TDD é que fortalece a qualidade interna do software porque ao você aplicar as práticas desse processo, você se torna minucioso na verificação de coesão, complexidade, acoplamento sem precisar de ferramentas de análise de código.

Eu não estou afirmando que não use ferramentas de análise de código, longe disso, só que essas ferramentas não verificam qualidade real no código, no máximo elas avaliam erros clássicos e mau cheiro no código. É perfeitamente possível escrever um código horroroso e ilegível e passar por todas as ferramentas de análise de código facilmente, isso acontece na prática no cotidiano.

Como testar?

Antes de me dizer, responda-me: Você faz que tipo de teste? Unitário, integração, sistema, aceitação? Testes funcionais, estruturais ou baseados em defeitos? Para testes funcionais, você utiliza classes de equivalência, análise de valor limite, grafo causa-efeito e ainda tenta error-guessing? Para testes estruturais, você aplica grafos de fluxo de controle? Como define seu critério de cobertura de instruções, decisões, condições e caminhos? E quais das métricas já citadas ou quaisquer outras tem adotado? (Zhu, Hall and May, 1997) Se você não tiver uma boa estratégia para cada uma destas táticas, sinto muito informar-lhe, mas VOCÊ NÃO SABE TESTAR SOFTWARE.

Eu não sigo as estratégias do Zhu “Who?”, eu sigo um AMADOR SEM EDUCAÇÃO chamado Kent Beck que não é nada científico mas funciona. Sim, eu faço testes unitários, integração, aceitação, stress, carga e o que der mais para fazer com o tempo disponível para entregar o software o mais saudável possível. As ferramentas de análise de cobertura são frágeis e deixam escapar a real cobertura, da qual temos que aplicar triangulação e outras práticas não-acadêmicas criadas por AMADORES SEM EDUCAÇÃO.

O bacana de tudo são esses números:

Ou seja, mesmo que você tenha 100% de cobertura, você terá apenas garantia de detecção de defeitos em 25% dos casos (Glass, 2002).

Minha vó dizia que os números quebrados tem mais credibilidade, se fosse pelo menos um 25, 37%… vá lá.

Não estou a par de nenhum estudo rigoroso que mostre relação positiva entre presença de testes automáticos e código mais coeso, desacoplado, limpo, claro e legível também.

Dr. o mundo não vive de Papers apenas, saia da academia e visite uma empresa que faça TDD e outra que não, o senhor avaliará por si só. Alias, quem deveria fazer esses estudos era a academia, não? Como farão se não saem às ruas?

Caso alguém tenha, por favor, entre em contato. Gostaria de saber também, se possível, quais processos preocupam-se com qualidade externa em detrimento de qualidade interna. Seriam os processos ágeis?

Todos os processos avaliam qualidade externa pelo que escrevi acima.

O seguinte trecho quase me faz não responder esse artigo:

Por fim, o PROJETO é a quarto e última variável necessária para construir software, porque planejamento e gerenciamento são nossas únicas armas para controlar a complexidade

O que diabos complexidade tem a ver com planejamento e gerenciamento?

Desde quando voce planeja a complexidade de um software?

Fazendo notação matemática do algoritmo?

Desculpe, mas nem todo mundo tem o tempo do Dr. Knuth para entregar software, precisamos de verificação rápida e não notação matemática e não existe um mecanismo que faça isso antes de ter um software escrito.

Novamente, o projeto pode ser tão detalhado e formal quanto se queira.

Não, DR. O projeto não pode ser tão detalhado e formal quanto o queira, isso eu acreditava antes de fazer coisas reais e ficava apenas em cima de livros, se a engenharia de software realmente existisse, eu tinha mecanismos reais para fazer esse detalhamento, mas hoje esses mecanismos reais não existem.

Cada vez mais me convenço de que a academia está morta e não produz nada de real, apenas papers repetitivos de bobagens que ninguem lê.

Deveriam ter terminado a notação formal da orientação a objetos mas estão preocupados demais com “modelos de qualidade” [sic] que nunca avaliaram na prática e não fazem idéia de como mensurar.

Isso não é científico, Dr.

Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated matter. Matters, like “coupons for viagra“, are connected numerous types of health problems. If you need to take prescription medications, ask your druggist to check your testosterone levels before. Sometimes the treatment options may turn on erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.