Cadê os testes?

Assuntos Gerais Agile
#21

Confesso que não entendi muito bem o que você quis dizer com proibir a publicação e divulgação de software livre e nem como isso vem à discussão.

Quanto ao resto, vamos lá:

Eu acho que você tem todo o direito de escrever o seu software da forma como bem entende e não tenho o menor motivo para duvidar da sua capacidade técnica de construir um software sem testes, muito menos tenho a menor intenção de comprar uma briga homérica para mudar a sua opinião.

No entanto, há outras pessoas que leem esse fórum, que muitas vezes vêm até aqui em busca de esclarecimento às suas dúvidas ou de pessoas que passam ou passaram pelo mesmo problema que elas. E é direcionado a essas pessoas que farei esse post.

Pode ser que estes caras estejam lutando para aprender a escrever software melhor, e nessa luta estão esbarrando na dificuldade dos testes. Aí eles vem aqui e se deparam com um tópico desses e pronto. Logo percebem que eles estão certos e os testes errado. Mas pode não ser bem assim.

Vamos supor o seguinte trecho de código:

public void execute(int codigoDaBase, int codigoDaAltura){
  double base = dao.buscarBaseDoTrinagulo(codigoDaBase);
  double altura = dao.buscarAlturaDoTriangulo(codigoDaAltura);
  double area = (base * altura)/2;
  dao.salvarAreaDoTriangulo(area);
}

Claro que esse é um exemplo simples, onde a solução de refatoração é óbvia. Mas na realidade você vai se deparar com códigos muito piores que esse, com logicas bem mais complexas e bem mais difíceis de refatorar.

Mas num caso real, o desenvolvedor menos experiente, que leu aqui e ali sobre testes vai tentar testar o seu código. Vai ter que mockar a chamada da busca da base do triangulo, vai ter que mockar a busca da altura do triangulo, testar o cálculo da área, e mockar o método salvar.

Os testes nesse caso serão um inferno, e desnecessariamente, porque a intenção seria só testar o cálculo da área. Bastaria eu extraí-lo e testá-lo isoladamente. É um caso típico, entre muitos e muitos outros, de problema de design de código que dificulta a aplicação de testes unitários.

Aí o sujeito desavisado vem pro GUJ e dá de cara com um tópico como esses e pronto. Lá se foram os testes da vida dele e junto com eles uma boa oportunidade de aprender a escrever um código melhor.

Como eu disse, eu não quero convencer ninguém a mudar de idéia, nem dizer que quem não escreve software com testes não sabe o que está fazendo. Mas eu posso dividir facilmente minha carreira em antes e depois de aprender TDD. O índice de defeitos do que eu escrevia diminuiu absurdamente depois que eu passei a usar testes unitários e a facilidade de manutenção no que eu escrevo é muito maior hoje do que era antes.

Lógico que eu não sou perfeito e ainda tenho muito que melhorar, mas TDD pra mim foi a mais revolucionária ferramenta que eu experimentei. Foi o maior salto de qualidade que eu obtive. Então para mim ela teve a sua eficiência mais do que comprovada.

Se você não gosta, ou não quer usar a técnica é um direito seu, mas respeite-a porque ela será útil para muita gente.

E para quem lê e que concorda com o autor do tópico e deixo o conselho: antes de maldizer algo que vem crescendo bastante certifique-se de que o problema não está no seu código antes de simplesmente abandona-la.

#22

Só para complementar, eu não busco cobertura de 100%, não escrevo testes com mocks, só pra simular um if-else ou try-catch de falha de conexao.

Eu uso mocks, bastante, em códigos legado, onde mormalmente é bem mais fácil extrair interfaces e simular as diversas possibilidades que o código está tentando fazer do que tentar entendê-lo só olhando, ou, pior ainda, tentar executar em situação real.

Mocks pra mim são ferramentas de refactoring de código legado.

Eu uso TDD como um duto por onde a informação vai passar, nao importa de onde vem, nem pra onde vai, se de um xml ou de um banco de dados, o que me importa é que ao passar por meus objetos de negócio ela irá respeitar as regras que eu estipulei através dos testes.

Para isso eu preciso isolar a minha regra de qualquer forma de acesso a dados, arquivos externos, requests e responses e afins. Fazendo isso eu praticamente não preciso de mocks.

Essa é a minha realidade, dentro do tipo de software que eu desenvolvo, não sei se seria possivel abrir mão de mocks em outros tipos de produtos.

#23

Se você tiver um tempo neste fim de semana dá uma lida neste tópico aqui de 2007, alguns exemplos, não irei citar os autores não estou preocupado com a vida de ninguém, apenas com as opiniões :

01:

Qual o problema de vários frameworks no planeta ? Se isso for problema deveria haver apenas um sistema operacional também, afinal é software.

02:

As coisas só funcionam se tiver javadoc e teste unitário ? Porque baixar o código do spring e olhar o javadoc deles ? Porque não olhar o javadoc da API do java ?

03:

Essa frase não necessita de comentários…

04:

Essa frase não necessita de comentários…ninguém é obrigado a usar JSF ou EJB 2.1 bem como usar o GUJ para divulgar alguma coisa, basta mudar de emprego ou se cadastrar em outro fórum.

05

Essa frase não necessita de comentários…

06, 07, 08 …vários outros comentários…

Se essa coisa toda é “opensource” porque ao invés de criticar não escrevem os benditos testes unitários para o projeto ?

Ou os que criticam nunca leram a respeito das 4 liberdades do opensource criadas pela FSF ?

Deixo claro que não faço parte do time do neoframework, mas algumas pessoas/profissionais divulgam algo para ajudar a comunidade de alguma forma e recebem críticas em vez de ajuda com codificação ou criação de testes ou incentivos.

Me responda se isso não é ridículo ?

#24

Sei o que é um mock , mas hoje não consigo abrir mão do cigarro, já tentei parar de fumar mas ainda não consegui.

#25

Li o tópico, principalmente os mais “contundentes” e tive a seguinte impressão:

Embora muitos dos posts tenham de fato sido desnecessariamente desrespeitosos e mal-educados, outros com opiniões favoráveis a TDD e testes unitários em geral, são bem menos agressivos. A estes você escolheu simplesmente ignorar ou fingir que não existiram e concentrar-se naqueles mais “tensos” e respondê-los, como se respondendo a eles poderia provar a tese de que TDD é desnecessário.

Este seria muito mais útil para uma discussão se você respondesse do que os quais você quotou no seu post.

Um simples post do tópico que você indicou que sintetiza minha opinião:

Para quem não leu, considere ler o tópico que o helio indicou, é excelente, apesar de realmente haver algum excesso por parte de um ou outro defensor do TDD, principalmente no começo do tópico.

#26

Teste unitário, TDD, Usar ou não IDE …

Isso não é BOM ou RUIM.

É disso que estou falando, concordo com o Sérgio programar para mim também é uma arte e deve ser feito com prazer e vontade e motivação, não com imposições do mercado.
Não sou um robô nem um número como diz o trecho da música do Iron Maiden “im not a number i’m a free man !”

#27

[quote=heliofrota]Teste unitário, TDD, Usar ou não IDE …

Isso não é BOM ou RUIM.

É disso que estou falando, concordo com o Sérgio programar para mim também é uma arte e deve ser feito com prazer e vontade e motivação, não com imposições do mercado.[/quote]
E como foi que você conheceu Java? Por que você trabalha com Java?
Tudo o que conhecemos e/ou estudamos são, direta ou indiretamente, influenciados pelo mercado. Já trabalhei com Delphi, Java e Ruby, e aprendi essas três tecnologias por causa do mercado.

Só que aí entra o ponto onde concordo contigo: é uma decisão pessoal querer aprender ou não o que o mercado nos direciona a aprender.

Você, o Sérgio e outros demonstram um certo incômodo com o “estresse” que TDD traz, porque vocês se sentem um pouco obrigados a testar todos os aspectos do seu código. Mas aí que tá: quando usamos TDD, não precisamos testar um if-then-else, não precisamos nos preocupar com os detalhes da estrutura do código. Precisamos apenas testar o que ele faz.

Falando por mim, eu sinto o maior prazer em usar TDD. Programar os testes pra mim é tão viciante quanto programar o código em si. Particularmente, sou meio viciado em fazer o vermelho ficar verde hehehe. Mas para mim, o maior benefício que TDD traz não é sentido na hora que você cria o código, mas sim na hora que você precisa mantê-lo. Quando digo manter, me refiro a adicionar uma nova funcionalidade ou modificar uma que já existe. E se a gente for analisar o ciclo de vida de um software, a gente passa muuuuuito mais tempo modificando esse software do que o criando. Então TDD caiu muito bem pra mim nesse sentido.

Quando vejo alguém que não gosta de TDD, fico me perguntando que tipo de experiência traumática a pessoa teve para não gostar de TDD. No caso do Sérgio, eu sei o que houve porque já estava no fórum quando as pessoas jogaram pedra nele porque o Mentawai não tinha testes - e não concordo nem um pouco com esse apedrejamento. O Mentawai não deixou de ser um excelente framework só porque não tinha testes, e nem o Sérgio passou a ser um programador irresponsável só porque não usa TDD.

Mas se você tem essa resistência a TDD, convido você a insistir mais um pouco. Você não vai conhecer os benefícios do TDD se ficar com essa resistência, e nunca vai entender porque quem usa fala tão bem. Acredite, como profissional você só tem a ganhar.

#28

Em 2000 estudando em casa.
Porque não nasci rico, e java não é apenas mercado. Quem me conhece falo que se ganhar na mega-sena vou tentar escrever jogos em java por diversão.

Isso faz parte do pensamento.

Como citei anteriormente: a questão aqui são as críticas destrutivas à softwares sem testes unitários, não à metodologia de TDD.

Você é livre para escolher o que gosta parabéns, ruim é querer que todos gostem a todo custo do que “você declara” concorda ? (não estou me referindo a você diretamente, nem à metodologia)

Sinto prazer em estar aqui no fluxbox customizado da maneira que eu quero, com a ultima versão do slackware linux 32bits da maneira que eu quero, e lendo a especificação da jvm, claro, apenas os capítulos que quero, enquanto paro por alguns minutos para lhe responder da maneira, que, obviamente quero.

#29

[quote=heliofrota]Em 2000 estudando em casa.
Porque não nasci rico, e java não é apenas mercado. Quem me conhece falo que se ganhar na mega-sena vou tentar escrever jogos em java por diversão.[/quote]
Aí é que tá… Provavelmente não teríamos estudado Java se não fosse a influência de algo, e esse algo é o mercado em 99% das vezes. Por mais que tenhamos estudado em casa, sozinhos, devorando livros, por que fomos estudar Java e não outra coisa? Não dá pra negar a influência, direta ou indireta, do mercado em nossas decisões profissionais.

Isso realmente é um saco, e é lamentável que as pessoas julguem o profissionalismo dos outros pelo que o que ela deixa ou não de usar em seu trabalho.

#30

unit test, tdd, bdd, caixa preta, branca, azul, rosa, etc. é tudo um conceito, gente. Quem aplica a técnica com autoridade sabe que a grande utilidade disso não é em apenas diminuir bugs ou melhorar o design, mas sim encorajar o programador a alterar/refatorar o código lá na frente, visto que o mesmo possui o “escudo” dos testes para evidenciar qualquer erro causado por determinada alteração. Testes = facilitar alterações. Como tu vai fazer isso? Não importa, desde que seja possível executar a bateria de testes de forma prática e evidente. Testar no main das classes e/ou testes de interface é muito instável. Então eu considero que pessoas que não escrevem testes para partes críticas do sistema ou não sabem ou são preguiçosos.

Minha opinião.

#31

A sua opinião é completamente válida, porque é sua.

A minha opinião é que eu iria ficar puto se você escrevesse aqui informando que não usa software que não tem teste unitário vi que você usa o wordpress

Acessei o código fonte e não vi testes unitários do wordpress isso seria contradição sua, entendeu onde quero chegar ?

http://core.svn.wordpress.org/

Eu acho o wordpress uma excelente ferramenta, se não tiver nenhum teste unitário, continuo achando uma excelente ferramenta.

Este tópico é sobre abrir as mentes e formar opinião, não sobre denegrir testes unitários ou metodologias.

Ler a terceira frase que escrevi no post inicial :

#32

[quote=gomesrod][quote=heliofrota]
Patrick Volkerding:

[/quote]
Isso traduz bem o que penso: testes unitários onde eles são necessários.
Geralmente uso em rotinas que executam lógicas complexas ou razoavelmente complexas, mas sem essa obrigação de 100% de cobertura. Por exemplo, um determinado parâmetro não informado lança uma exceção. Não crio um teste para isso pois está bastante óbvio o comportamento do código.

Outros pontos que o pessoal às vezes faz malabarismos com mock apenas para conseguir cobertura de 100%: Actions/Controllers, Serviços que só delegam ao DAO.[/quote]

Gostaria de comentar algumas coisas aqui. Não realmente responder ao autor do trecho acima, mas tocar os pontos texto.

Primeiro ha que distinguir “teste” de "test-drive-developement’ (aka TDD) e “test-first”. Também destinguir “teste” de “experiencia”.
É muito comum ouvir a frase “teste de mesa”. Isto não existe. O que se quer dizer é “experiencia de mesa”. O programador após criar o código experimenta se ele funciona. E fica experimentando até que o código faz o que ele espera.
É certo que os programadores só fazem experiencia quando têm dúvidas se o código funciona. Ninguém experimenta 2+ 2 , mas provavelmente vão experimental BigDecimal.divide() porque tem 2 argumentos em vez de um, que seria o de esperar. E mesmo tem gente que usar o junit para criar experiencias mais complexas e avançadas. Mas são experiencias.

Teste é algo mais técnico. Primeiro ha que saber onde podem estar as falhas, criar cenários (passo-a-passo) para exercitar essas falhas. Os chamados “corner cases” são importantes. Incluir regras de qualidade (por exemplo, o método nunca deve retornar os parametros que recebeu, ou o método não deve aceitar nulo, o objeto é realmente imutável). Depois código é escrito para realizar estas verificações. A diferença é que um teste é criado sem saber nada sobre o código a ser testado e sim sobre a unidade sob test ( classe, sistema, etc). Apenas quem escreve o código do teste tem que se preocupar com isto.

Estes testes são raros a menos que haja investimento da instituição e das equipes.

Test-Fisrt é simplesmente a prática de criar o teste antes de programar a unidade (classe, sistema, etc…) a ser testada. Desta forma, apenas quando criarmos o código de teste iremos nos preocupar com a real interface da unidade, mas não para fazer a lista de coisas a testar.

TDD é abusar do conceito de Test-First para ajudar no desenvolvimento. Ou seja, o código do teste é utilizado para guiar como será a interface da unidade sob teste, quantos e quais outras unidades serão necessárias, como elas interagem etc… ou seja, é simplesmente modelar o código melhor usando o cheklist de testes para prover um melhor desing. Por exemplo, Testar um singleton é um parto, então, usando TDD irá criar um outro design mais simples de testar e que obtém os mesmos resultados.

Isto nada mais é que a velha prática de criar mais do que um cliente para o seu código. O código de teste que chama o seu business é tao importante quanto o código do action que chama o business. São ambos dois clientes válidos para o business.

Não confundir TDD com Test-First. O primeiro é um receiturário de processo de desenvolvimento (não de teste), o segundo é uma Diretiva de Desenvolvimento ( usada, por exemplo, no XP)

Só um ponto de ordem, todos os testes são unitários , o que muda é a unidade que pode ser um classe, uma instancia de uma classe, um conjunto de classes, um conjunto de instancias, um sistema completo, um conjunto de sistema. Nome variados são usados para agrupar as coias como teste de integração e coisas assim, mas quando se fala em “Unit Test” não se está falando em teste onde a unidade é o mais baixo possivel, e sim na metodologia geral de testes. “Unit test” significa teste no sentido que expliquei antes, para não confundir com “experiencia”.

Dado isto, a resposta do Pratick não é “Não quero saber de testes unitários” é “Eu escrevo testes, e ocasionalmente usando o principio do Test-First, mas não desenvolvo meu código usando os testes” ou seja, ele desenvolve o código como qualquer um faria, usando a experiencia, imaginação e um plano mental do que ha fazer e como, e depois escreve os testes do que realizou. E às vezes, ele escreve primeiro o teste - provavelmente para deixar bem claro para ele mesmo o que ha a ser feito e quais os riscos.

Em nenhum ponto ele escreveu “eu não escrevo testes” ou “só escrevo quando me apetece” ou “só escrevo quando acho que é necessário”.

É fácil mal-intepretar as respostas, mas o ponto é simples : Testes Unitários (os que não são experiencias) sim são importantes e vitais.

Ninguém disse que é fácil. Ninguém disse que é rápido. Mas todos concordam que é importante e vital.
Ok, não preciso criar o teste antes. É muito útil se fizer isso, mas isso não é tão importante. O importante é que o teste exista.

Por outro lado, quando se programa é muito simples criar estruturas que não são fáceis de testar. É para evitar isso que existe o TDD e o Test-First. Mas se você sá sabe criar bom código, que é simples de testar, vc simplesmente vai lá e escreve o código.
Se o código é bom, não importa realmente a ordem. Agora, se o código é ruim, ou o programador não sabe o que está fazendo, então sim, estes princípios são importantes até que o gramador ganhe uma maestria do design.

Por outro lado, os testes não são criados para ver se o código funciona. Isto é um pensamento errado. Não estamos querendo saber se sódio com cloro dá sal. Não é uma investigação. Não é um experimento. O que queremos com isto é ter um mecanismo automatizado que nos diga que o sistema ainda está funcionando. É esta segurança que procuramos e não se o sistema funciona. Porque é esta segurança que nos permitirá realizar modificações sem medo pois existe outra diretiva que diz “Não tenha medo de refactorar”. Vc pode ter medo que o seu codigo seja impossível, caro, ou lento de refactorar, ou que refactorando ele deixe de funcionar. Esses são medos válidos e são eliminados usando, por exemplo, testes automáticos. Ter medo que deixe de funcionar é normal, ficar paralizado por isso não é.

Cobertura de 100% é impossível. O normal é 30-50% e 70% é absurdamente bom. Mas claro, testar todos os get/set não conta nesta cobertura. Além disso testes são incrementais. Começa por testar o que você espera que possa dar errado. Depois, vc vai receber tikets com erros que mostra que alguns cenários vc não previu e vc adiciona mais testes e assim vai… ninguém testa tudo da primeira vez. Seria insano.

Criar testes é dificil, caro , demorado e muitas vezes mais dificil que criar o próprio sistema. Eu vivo isto todos os dias, não apenas no trabalho, mas no meu projeto pessoal que tem mais de 60 mil linhas de código e 1900 classes. Para tudo isto tenho 127 testes com 16% de cobertura - muito pouco. Mas não vale me enganar achando que o mais importantes é o código e que não preciso dos testes. É claro que preciso. Muitos refactorings são feitos na fé e isso não é bom. Não vale me enganar dizendo que se o Spring ou o JDK não têm testes eu também não preciso. Não vale tentar arranjar desculpas para não fazer os testes.

Então vamos parar com essa ideia que existe a mínima chance de não ter que escrever testes. Não ha!. Pode ser preguiçoso, pode ter falta de tempo, recursos e até de conhecimento de como fazer os testes, mas dizer que eles não são necessários é simplesmente burrice. É como dizer que o cinto de segurança não é necessário.

Eu já convivi com vários projetos que não têm testes automáticos. Ok, funciona. Até que descobrimos que não funciona. E quando descobrimos isso e precisamos refatorar - valha-nos Deus. E se queremos melhorar o sistema em algum ponto , logo alguém grita “Não! pode quebrar”. É claro que pode quebrar. A questão é se vamos saber. Se ha um mecanismo automático que testa o pontos vitais mais preocupantes e se esses continuam funcionando podemos dizer que o refactoring foi um sucesso. Mas e quando não temos os testes ? E pior, quando temos um código que é impossível testar ? Ai é pior ainda, porque para criar os testes teríamos que refatorar o sistema primeiro (!). O risco envolvido nisto é insano. E como disse Einstein, insanidade é repetir a mesma coisa e esperar resultados diferentes. Portanto, deixar o sistema sem testes e esperar que ele não vai dar problema é tão insano quanto criar um sistema impossível de testar.

Quanto a só usar sistemas com testes, o argumento é uma falácia logo no inicio. Os testes não são para proteger o cliente e o usuário, são proteger o investimento e a equipe de desenvolvimento. O cliente simplesmente mudar de sistema se ele dá problema ou processa a empresa por danos. Ou seja, é risco. Os testes servem para mitigar risco no desenvolvimento, não para salvar o usuário.

#33

[quote=peerless]unit test, tdd, bdd, caixa preta, branca, azul, rosa, etc. é tudo um conceito, gente. Quem aplica a técnica com autoridade sabe que a grande utilidade disso não é em apenas diminuir bugs ou melhorar o design, mas sim encorajar o programador a alterar/refatorar o código lá na frente, visto que o mesmo possui o “escudo” dos testes para evidenciar qualquer erro causado por determinada alteração. Testes = facilitar alterações. Como tu vai fazer isso? Não importa, desde que seja possível executar a bateria de testes de forma prática e evidente. Testar no main das classes e/ou testes de interface é muito instável. Então eu considero que pessoas que não escrevem testes para partes críticas do sistema ou não sabem ou são preguiçosos.

Minha opinião.

[/quote]

TDD é pouco eficaz para reduzir bugs e melhorar design, não é a toa que a proposição mudou para “facilitar a vida de quem precisa alterar o sistema no futuro e não é o autor original do software”.

Pelo menos agora é útil para empresas que não conseguem reter seus profissionais por muito tempo.

#34

sergiotaborda

Acredito que sobre o tema de testes, unitários ou não, e TDD você foi o que trouxe mais enriquecimento à esta thread.

A discussão que iniciei aqui não é técnica, é social. Uma ironia a respeito de uso de software sem testes unitários. Mas que obviamente foram testados pelo programador por várias situações que você conseguiu traduzir em alguns parágrafos, quando citou sobre experimentos.

Acredito que ninguém tenha interpretado mal a resposta do Patrick, mas o fato de você traduzir para pt_BR foi uma iniciativa boa.

Eu não evangelizo ninguém, cada um tem o céu e o inferno que merece.

Sem escrever muito:

Você acha correto um programador criticar um projeto livre que não possui testes persistidos em meios magnéticos e/ou não possuem o formato mercadológico atual ?

É disso que estou falando quando criei essa thread.

#35

tnaires

Não estudei por causa do mercado, um amigo que estava fazendo mestrado em IA estava tentando me ensinar complexidade algorítmica, digo tentando por 2 motivos: o primeiro que eu até então não havia colocado os pés na faculdade e o segundo que ele estava estudando para uma prova e aquilo , segundo ele, o ajudaria a passar na prova.

Depois em 2001 foi que comecei a entender o mercado e o que a plataforma java representava neste meio.

Mas acredito que você tenha uma % boa de razão, o capitão crunch só estudou telefonia a fundo depois que viu o mercado de telefonia aflorar e imaginou N possibilidades…

#36

[quote=heliofrota]
Sem escrever muito:

Você acha correto um programador criticar um projeto livre que não possui testes persistidos em meios magnéticos e/ou não possuem o formato mercadológico atual ?

É disso que estou falando quando criei essa thread. [/quote]

Sim. Acho correto que o projeto seja criticado por falta de testes codificados que possam ser executados e adicionados. E entenda que tenho um projeto destes que, como disse tem poucos testes.
O mesmo vale para projetos não-livres.

O ponto é que em projetos livres você perde o direito de criticar a partir do momento a que se recusa a ajudar.
Se estava ruim não é culpa sua. Se continua ruim, a culpa é sua.( regra do bom escuteiro) Porque não participou e ajudou. Se a culpa é sua não adianta criticar. Tem que ajudar. Não quer ajudar ? Então não reclame.

Eu nunca criticaria os projetos linux, ou o jdk ou qq projeto livre por falta de testes porque eu não faço a mínima ideia de como ajudar.

È diferente para projetos fechados. Que como falei antes o problema está no risco. Tem também a ver com a vida util. Se vcvai jogar o software fora em um ano, não adianta muito criar um super esquema de teste, mas se vc comanda um produto que irá viver 10 anos ou mais ( como o linux ou o jdk , etc…) é bom para si que tenha os testes. O Cliente simplesmente pode usar outro produto.

#37

Ah, as maximas!!! As maximas!!!

TDD é muito eficaz para reduzir bugs e melhorar design. Ele, bem aplicado, reduz a quantidade de bugs de um sistema porque cria uma bateria de testes automaticos que validam se todo o seu sistema continua funcionando da forma como voce espera. E TDD, melhora muito o design, porque voce nao consegue testar um design ruim.

Acho que esse nem eh o ponto da discussao. O que o Helio reclama, e eu tenho que dar razao a ele, é do fato de quererem tornar TDD obrigatório e dizerem que quem não faz não sabe programar.

E, para concluir, gostaria de saber qual autor assumiu pra si a responsabilidade de alterar a proposição da forma como você sugeriu. Para mim ela nunca foi alterada.

Quando for emitir a sua opinião, procure sempre deixar claro que ela é a sua opinião, pois muita gente que está começando costuma ler este fórum e tais afirmações podem confundi-las.

Ao invés de dizer “TDD é pouco eficaz para reduzir bugs e melhorar design”, diga "eu acho TDD pouco eficaz… " e de preferência explique porque.

Acho que até pode criticar, mesmo projetos livres, desde que faça com respeito.

O grande problema está em ridicularizar o trabalho dos outros, principalmente trabalho que é feito de forma voluntária e que não espera compensação financeira.

#38

[quote=heliofrota]A sua opinião é completamente válida, porque é sua.

A minha opinião é que eu iria ficar puto se você escrevesse aqui informando que não usa software que não tem teste unitário vi que você usa o wordpress

Acessei o código fonte e não vi testes unitários do wordpress isso seria contradição sua, entendeu onde quero chegar ?

http://core.svn.wordpress.org/

Eu acho o wordpress uma excelente ferramenta, se não tiver nenhum teste unitário, continuo achando uma excelente ferramenta.

Este tópico é sobre abrir as mentes e formar opinião, não sobre denegrir testes unitários ou metodologias.

Ler a terceira frase que escrevi no post inicial :

[/quote]

Sim, eu entendi seu ponto. Uma coisa é o software que eu uso, a outra é o software que eu construo para os outros usarem. Uma coisa é um erro no wordpress a outra é no sistema de folha de pagamentos da empresa que eu trabalho, e por ai vai. Certamente não seria um lunático para verificar se o que eu uso possui testes (salvo algumas excecoes, como frameworks e outras ferramentas de trabalho open-source que precisam ser alteradas), no mais… são contextos completamente diferentes.

Outra questão… em nenhum momento eu disse que teste é requisito primário para se construir software - pessoas que preferem assim, o fazem - sem problemas. Acho que em nenhum lugar está escrito isso. A questão é: com suites de testes o desenvolvimento torna-se mais confiavel, visto que tu tem evidencias para capturar rapidamente erros incluidos devido a alteracoes - eu prefiro não arriscar - não confiar - e ter certeza que um problema incluido por qualquer um do time possa quebrar o build o quanto antes, ponto. Posso estar viajando, mas isso aqui parece com um projeto de testes do wordpress, isso aqui uma iniciativa de testes automatizados para o kernel do linux, e por ai vai.

Conclusão: cada um faz software como acha melhor, o resultado (o software) é uma coisa, pode ser entregue sem testes (que é o caso dos softwares proprietários, onde tu nao tem nem acesso a fontes). Eu uso testes para me proteger, é uma técnica. Testes lhe fornecem uma metodologia mais séria e barata para desenvolvimento comunitário (caso dos projetos open-source).

#39

[quote=NickGaspar][quote=peerless]unit test, tdd, bdd, caixa preta, branca, azul, rosa, etc. é tudo um conceito, gente. Quem aplica a técnica com autoridade sabe que a grande utilidade disso não é em apenas diminuir bugs ou melhorar o design, mas sim encorajar o programador a alterar/refatorar o código lá na frente, visto que o mesmo possui o “escudo” dos testes para evidenciar qualquer erro causado por determinada alteração. Testes = facilitar alterações. Como tu vai fazer isso? Não importa, desde que seja possível executar a bateria de testes de forma prática e evidente. Testar no main das classes e/ou testes de interface é muito instável. Então eu considero que pessoas que não escrevem testes para partes críticas do sistema ou não sabem ou são preguiçosos.

Minha opinião.

[/quote]

TDD é pouco eficaz para reduzir bugs e melhorar design, não é a toa que a proposição mudou para “facilitar a vida de quem precisa alterar o sistema no futuro e não é o autor original do software”.

Pelo menos agora é útil para empresas que não conseguem reter seus profissionais por muito tempo.
[/quote]

Fonte disso?

Pessoas chamam o que quiserem de TDD. É necessário uma boa experiencia para aplicar TDD na medida exata a qual ele lhe dará o seu melhor benefício: design. Analogicamente a construcao com TDD seria assim:

Problema: colocar um tijolo dentro de um copo

com TDD: existe o tijolo, constrói-se o copo já com o tijolo dentro.
sem TDD: existe o copo, adapta-se o tijolo para caber dentro.

#40

YvGa

Só um alinhamento: Eu não reclamo do mercado exigir TDD, já usei essa metodologia. No atual emprego não uso, não preciso mentir, se a situação ou a liberação dos releases se modificar
de alguma forma, pode ser que use TDD ou simplesmente adicione uma cobertura ou não faça nada disso.

Em casa codificando algumas coisas , hora uso TDD hora não uso.

Usei mais TDD no emprego anterior do que no atual (a mais ou menos 2 anos atrás)

Agora a parte que você falou sobre “Quem não utiliza esta metodologia não sabe programar” sou realmente contra, assim como vários são.

Tem profissionais excelentes aqui no GUJ que provavelmente aprenderam essa metodologia uns 3 anos pra cá, e começaram a trabalhar a uns 15 anos atrás por exemplo, logo esses caras só aprenderam a programar os 3 últimos anos ? Os 12 foram para o lixo ? Isso seria ridículo, é um rótulo apenas.