Não, bugs que aparecem no final são geralmente coisas pequenas, pois envolve pouco do que mexemos durante a sprint, tudo que é mexido e impactado durante a sprint são feitos ou alterados testes durante a própria implementação de cada história, então já existe uma boa parcela de garantia a cada término de uma história. E no final de tudo só aparecem erros inesperados, tipo algo que o designer mexeu no CSS e quebrou algum jquery ou algo genérico que impactou outra coisa que esqueceram de prever, etc. Geralmente bugs pequenos em telas jamais mexidas diretamente e que normalmente só pegaríamos quando estivesse em produção. E o deploy também é uma “história” (entra na gordura), tem postits rotineiros, ou algo de atenção, e entre eles “rodar os testes” e dependendo do resultado distribuir pra equipe resolver os imprevistos. E tudo é repeitado dessa forma por ter dado mais certo até então, não que seja o melhor pra todo caso, cada equipe trabalha da melhor forma que as pessoas se sintam produzindo melhor no momento e daí vai evoluindo, sem ditadura.
[quote=marioareias]
E em relação a infra, tu não consegue controlar a infra de Web Service de terceiros, por exemplo. Outra coisa é que dependendo do porte do teu software não tem como tu manter um ambiente igual ao de produção no teu de testes. É simplesmente muito caro e complicado demais para fazer. Em software pequenos isso é plenamente acessível, mas em softwares muto grandes, muitas vezes, não é não.[/quote]
Sim vai depender do caso, falei de um caso particular, nesse caso a infra é na própria empresa que tem o setor de desenvolvimento, mas os sistemas são grandes e a empresa também. Já em sistemas menores que as vezes pego por fora não faço testes automatizados nenhum, por não ter investimento mesmo para isso.
Ah, e outra coisa, Selenium não exclui os testes unitários, não sei se interpretou assim, pois são dois níveis de teste.
Concordo com você. Esse cara tem muito pouca experiencia com TDD, desde o conceito até a prática. Ok, tudo que você sabe que precisa ser testado, você saberá fazer certo. Correto?
Não, não é correto, pois como disse alguem lá nos próprios comentários do post dele, se fosse assim não haveria bugs em software. E eles existem aos montes. Então sim, os pontos que sabemos ser problemáticos precisam obrigatoriamente ser testados. O ponto é como.
Nós podemos largar tudo nas costas de testadores, com testes funcionais manuais pra encontrar bugs em um sistema já pronto. Que ainda é a prática comum hoje. Mas nós podemos também prevenir a entrada de bugs através de testes automatizados. Acho que até aqui ninguem discorda, certo?
Nós podemos automatizar testes funcionais nos caminhos principais com ferramentas como o Selenium. Isso ajuda bastante, vamos descobrir o bug antes do que se esperarmos a turma da qualidade chegar, mas dificilmente saberemos onde exatamente está o problema sem que tenhamos que apelar para grandes sessoes de debug. Os erros podem não se repetir em todas as circunstancias, pode não acontecer em todas as configuracoes, para todos os clientes, para todas as versoes. E em cada cenario desse, se quisermos cobertura para eles, precisamos ter testes.
Manter testes nessas ferramentas é muito mais custoso do que simples testes unitarios, em todos os aspectos. Só que já trabalhou com eles sabe. Alterar um teste de uma funcionalidade no selenium pode ser bem complicado, além de que um mesmo problema pode fazer com que inumeros testes se quebrem. Testes unitarios são mais simples e específicos, quando algo quebra, quebra poucos testes. Os cenarios sao mais faceis de montar e de manter. Ou seja, exigem menos esforço.
Bugs existem e TDD não te livra deles, mas te livra sim de bugs recorrentes. Além de ajudar muito a não introduzir novos. Lógico algo pode acabar escapando, mas nunca pela segunda vez.
Nós não temos o direito de usar a física tradicional nas nossas aplicações, como podem os engenheiros, então nós deviamos criar a física da nossa aplicação. Validar regras de negócio automaticamente é uma forma de colocar constraints “físicas” aos nossos processos e ter certeza que continuam de acordo com o que queremos. Eu ainda não conheço nenhum forma melhor de fazer isso do que através de testes unitários. Se alguem tiver que a traga, pelo menos a proposta, que eu a recebo de braços abertos, ao menos para avaliá-la.
Só não tentem me convencer de que não existir leis regendo nossas aplicações é uma coisa boa e que tê-las em nada me ajuda.
No mundo da física uma pessoa ao cair não passa do chão, não deve passar e assim deve ser. No mundo do software eu preciso garantir que ele não passará e verificar sempre se ela continua garantindo para não ter inconsistencia. Então eu preciso sim de um teste automatico que me dê a segurança de que ao fazer uma alteração na lei da gravidade e não esteja, sem querer, permitindo que alguem caia e vá alem do chão.
As vezes meus comentarios se tornam repetitivos através de vários posts diferentes, mas não consigo não reagir aos ataques a uma tecnica que mudou da agua pro vinho a qualidade das aplicacoes que eu faço. Então quem anda tentando e está desanimado, insista por que o problema pode estar em sua pouca experiência e não no TDD. Não que eu seja um expert, mas já consigo tirar bastante proveito.
Podemos chegar a conclusão então de que TDD não é feito com a intenção de detectar todos os tipos de bugs no código mas sim de criar um código legível e que siga o principío do SOC (Separation of concerns)?
Ou seja, quem escreve bons código não precisa do TDD para se prevenir de bugs, mas quem ainda não tem experiência pode se valer do TDD para ajudar a escrever bons códigos?
Podemos chegar a conclusão então de que TDD não é feito com a intenção de detectar todos os tipos de bugs no código mas sim de criar um código legível e que siga o principío do SOC (Separation of concerns)?
Ou seja, quem escreve bons código não precisa do TDD para se prevenir de bugs, mas quem ainda não tem experiência pode se valer do TDD para ajudar a escrever bons códigos?
Abs[/quote]
TDD pega alguns bugs sim, mas não pega todos. Aliás, nenhum tipo de teste pega todos os bugs. O único método infalível de pegar todos os bugs é chamado de Usuário. Ele com certeza vai achar todos
Me apresentar o programador que escreve código sem bugs que eu preciso aprender com ele. E não é só quem não tem experiência que usa TDD, muito desenvolvedor bom que eu conheço usa TDD. E carinhas bem fraquinhos como Kent Beck, Uncle Bob, Michael Feathers usam TDD também rs
Podemos chegar a conclusão então de que TDD não é feito com a intenção de detectar todos os tipos de bugs no código mas sim de criar um código legível e que siga o principío do SOC (Separation of concerns)?
Ou seja, quem escreve bons código não precisa do TDD para se prevenir de bugs, mas quem ainda não tem experiência pode se valer do TDD para ajudar a escrever bons códigos?
Abs[/quote]
eu considero que a filosofia de testes unitários vai além disso, uma das coisas que eu acho bem legal é que você também tem nos seus testes automatizados a garantia de que o bug não voltará, por que teoricamente você terá um teste que dará o erro e evidenciará caso o bug aconteça, sendo assim caso alguém acabe por inserir novamente algum bug no código em manutenção (não vou questionar os motivos, seriam muitos), ao executar os testes você terá a evidencia disso, o que aumenta a confiabilidade do software.
considero que tem seus pontos negativos também, aumenta uma camada de complexidade mas, por outro lado melhora no sentido da garantia da qualidade e da organização… como todo o resto use com moderação, saiba o que está usando e não terá problemas.
Podemos chegar a conclusão então de que TDD não é feito com a intenção de detectar todos os tipos de bugs no código mas sim de criar um código legível e que siga o principío do SOC (Separation of concerns)?
Ou seja, quem escreve bons código não precisa do TDD para se prevenir de bugs, mas quem ainda não tem experiência pode se valer do TDD para ajudar a escrever bons códigos?
Abs[/quote]
TDD pega alguns bugs sim, mas não pega todos. Aliás, nenhum tipo de teste pega todos os bugs. O único método infalível de pegar todos os bugs é chamado de Usuário. Ele com certeza vai achar todos
Me apresentar o programador que escreve código sem bugs que eu preciso aprender com ele. E não é só quem não tem experiência que usa TDD, muito desenvolvedor bom que eu conheço usa TDD. E carinhas bem fraquinhos como Kent Beck, Uncle Bob, Michael Feathers usam TDD também rs
[/quote]
pior que nem chamando o usuário…
de repente ele pega a maioria dos de negócio… mas mesmo isso ainda é bem relativo…
de repente ele pega a maioria dos de negócio… mas mesmo isso ainda é bem relativo…[/quote]
Se ele não achar o bug, é porque ele não tá usando. Se ele não tá usando, o código nem deveria ter sido feito. Se o código não deveria ser feito, não deixa de ser um problema
Podemos chegar a conclusão então de que TDD não é feito com a intenção de detectar todos os tipos de bugs no código mas sim de criar um código legível e que siga o principío do SOC (Separation of concerns)?
Ou seja, quem escreve bons código não precisa do TDD para se prevenir de bugs, mas quem ainda não tem experiência pode se valer do TDD para ajudar a escrever bons códigos?
Abs[/quote]
TDD pega alguns bugs sim, mas não pega todos. Aliás, nenhum tipo de teste pega todos os bugs. O único método infalível de pegar todos os bugs é chamado de Usuário. Ele com certeza vai achar todos
Me apresentar o programador que escreve código sem bugs que eu preciso aprender com ele. E não é só quem não tem experiência que usa TDD, muito desenvolvedor bom que eu conheço usa TDD. E carinhas bem fraquinhos como Kent Beck, Uncle Bob, Michael Feathers usam TDD também rs
[/quote]
Eu não quis dizer que só quem não tem experiência usa TDD, eu acho que quem não tem experiência pode se valer do TDD para escrever bons códigos
de repente ele pega a maioria dos de negócio… mas mesmo isso ainda é bem relativo…[/quote]
Se ele não achar o bug, é porque ele não tá usando. Se ele não tá usando, o código nem deveria ter sido feito. Se o código não deveria ser feito, não deixa de ser um problema :)[/quote]
muito pelo contrário, ele pode estar usando e dependendo do bug ele não encontrar (na verdade não somente dependendo do bug… dependendo do usuário também…rs)
isso é plenamente… normal…
inclusive se fosse assim não existiriam mais bugs no windows (clássico exemplo), usuário desse istema operacional é o que não falta, tem gente usando, por que que ainda se encontra bug então, ainda nos dias de hoje? editando para explicar melhor… por que que ja não foram todos encontrados? muitas vezes muitos bugs passam batido, isso é a coisa mais normal do mundo…
muito pelo contrário, ele pode estar usando e dependendo do bug ele não encontrar (na verdade não somente dependendo do bug… dependendo do usuário também…rs)
isso é plenamente… normal…
inclusive se fosse assim não existiriam mais bugs no windows (clássico exemplo), usuário desse istema operacional é o que não falta, tem gente usando, por que que ainda se encontra bug então, ainda nos dias de hoje? editando para explicar melhor… por que que ja não foram todos encontrados? muitas vezes muitos bugs passam batido, isso é a coisa mais normal do mundo…[/quote]
Cara, tu não entendeu o que eu falei. Meu ponto é se teu usuário não acha bug em determinado lugar de um software, ele é porque ele não está usando esse determinado lugar do software. Exemplo é o Word com toneladas de funcionalidades, com certeza devem ter alguns pequenos bugs que ninguém nunca viu, porque ninguém precisou usar. Se não tem usuário usando aquele funcionalidade, ela nem deveria ter sido feita. Foi dinheiro e tempo desperdiçado, o que por si só já um problema.
Não concordo com isso de ser plenamente normal. Aliás, acho isso muito fora do normal. Se um usuário usa uma determinada funcionalidade e a funcionalidade tá bugada, ele VAI achar o bug. Ponto.
Nao creio que seja o caso porque para extrair o melhor do TDD é preciso bases sólidas dos conceitos OO. Se não nascem as macarronadas que acabam causando péssima impressão em quem herda uma bateria de testes mal feita. Se você se refere a alguem sem experiência, mas sendo assistido eu concordo.
Concordo também com o Mário, quanto a bugs não encontrados. Se algo não é usado é porque não é necessário e foi gasto tempo/dinheiro em algo desnecessário.
Bom se todo o problema fosse esse. Mas há algo ainda mais sério e eu vivo isso na pele atualmente.
Existe um calculo de correção de valor na aplicação na qual trabalho que em determinadas circunstancias pode ser obtida através de um índice, cujo cálculo é beeeem mais complexo do que o normal. Há pouco tempo eu descobri que ele não é usado, nunca foi usado por essa versão, foi criado porque havia a necessidade nos tempos de inflação altissima (que já se foi há mais de vinte anos). Mas ele está lá, para o caso de alguem precisar um dia.
E eu não consigo convencer o pessoal de negócios a tirar o maldito cálculo. “Frescura”, eles dizem, “se já está pronto, deixa ele lá”. Quem lê pode pensar que eles têm razão, mas sou eu que tenho que ficar desviando aquele trem o tempo todo, testando a funcionalidade quando preciso alterar, cuidando para que os testes dela não quebrem. E pior ainda, arrumar quando eles pegam algo errado.
Seria muito mais simples jogar aquilo fora e reimplementar quando for o caso, mas não o fazem por preciosismo.
Caso clássico de otimização prematura. Até fiz um blog post sobre isso. Muitos clientes tem esse tipo de pensamento vai que alguém um dia talvez precise. Realmente é um problema.
Como mencionei no post de abertura desse tópico, testes unitários exigem uma arquitetura muito desacoplada onde tudo precisa ser testável isoladamente. Qualquer herança que não seja de classe abstrata se torna um crime e o cara precisa abusar do pattern decorator (composição com delegate) criando 10 níveis de boneca russa e implementações “do nothing” das interfaces para quando ele quiser desativar uma funcionalidade. Minha experiência prática: é um LIXO. Nem o “open call hierarchy” funciona direito porque a implementação pode ser uma das 1000 existente e vc não tem como saber no compile time.
Esse é apenas um dos efeitos colaterais do extremismo com testes unitários e patterns: too many moving parts, complexity, dificuldade para fazer qualquer alteração no código, a coisa fica engessada, uma pentelhação para evoluir, etc.
A minha experiência com TDD é beeeeem diferente da sua. Pelo contrário, o TDD faz o meu código ficar mais simples, legível e sem essas camadas todas aí que você citou. Na minha experiência o TDD ajuda muito para contribuir com o Emergent Design. Ele aponta falhas muito facilmente. Se o design fica como você falou com tantas camadas e complexidade é porque quem fez, não soube reconhecer isso e alterar na hora certa.
Na minha opinião, quem faz design ruim com TDD, faz design ruim sem TDD. Quem faz design bom sem TDD, faz ainda melhor com TDD. E quando se está trabalhando em equipe, é sempre bom encontrar uns testes que te mostram como determinada classe funciona e que te ofereçam uma certa proteção na hora de alterar.
Concordo plenamente que testes bagunçados, difíceis de dar manutenção são horríveis e mais atrapalham do que ajudam. Mas quem fez esses testes também cria classes ruins, com design ruim.
TDD não faz milagre, é uma técnica que te ajuda em alguns pontos. Mas no final das contas, quem faz o código ser bom ou não é o desenvolvedor. Tem muito desenvolvedor bom que não gosta de TDD (como o saoj) e muito desenvolvedor que coloca a culpa no TDD pelos erros que comete todo dia. E nem tentam melhorar.
TDD (assim como qualquer outra coisa) não é unanimidade, tem quem defenda, tem quem ataque. Mas com certeza facilita o meu trabalho
Existe teste unitário com TDD e teste unitário sem TDD. Acho que o cara estava falando do último. Eu nunca experimentei fazer um sistema usando TDD, então não tenho como opinar. O ponto é que algumas pessoas usam os testes unitários para justificar a zona da arquitetura: “é uma zona mas eu consigo testar tudo de forma independente”. O pior é que muitas vezes eles nem sabem que está uma zona, pois nunca viram a coisa limpa. Acham que complexidade é um “efeito colateral inevitável” e que programação é coisa pra gente inteligente mesmo, logo se o cara não entende ou tem dificuldade é porque ele é burro. Faz o cara que fez a coisa se sentir “cool”. Taí a separação republicano x democrata na área de programação: simplicidade x complexidade.
Não estou falando que é o seu caso, Mario. Mas é o que eu já vi por aí.
[quote=saoj]Como mencionei no post de abertura desse tópico, testes unitários exigem uma arquitetura muito desacoplada onde tudo precisa ser testável isoladamente. Qualquer herança que não seja de classe abstrata se torna um crime e o cara precisa abusar do pattern decorator (composição com delegate) criando 10 níveis de boneca russa e implementações “do nothing” das interfaces para quando ele quiser desativar uma funcionalidade. Minha experiência prática: é um LIXO. Nem o “open call hierarchy” funciona direito porque a implementação pode ser uma das 1000 existente e vc não tem como saber no compile time.
Esse é apenas um dos efeitos colaterais do extremismo com testes unitários e patterns: too many moving parts, complexity, dificuldade para fazer qualquer alteração no código, a coisa fica engessada, uma pentelhação para evoluir, etc.
Foi o que o cara falou:
Eu concordo com cada carácter dessa afirmação.
[/quote]
Sergio, voce conseguiria detalhar um exemplo disso? Eu confesso que não consigo entender o porque de voce ter essa impressão. Você tem algo mais concreto pra exemplificar?
[quote=saoj]Existe teste unitário com TDD e teste unitário sem TDD. Acho que o cara estava falando do último. Eu nunca experimentei fazer um sistema usando TDD, então não tenho como opinar. O ponto é que algumas pessoas usam os testes unitários para justificar a zona da arquitetura: “é uma zona mas eu consigo testar tudo de forma independente”. O pior é que muitas vezes eles nem sabem que está uma zona, pois nunca viram a coisa limpa. Acham que complexidade é um “efeito colateral inevitável” e que programação é coisa pra gente inteligente mesmo, logo se o cara não entende ou tem dificuldade é porque ele é burro. Faz o cara que fez a coisa se sentir “cool”. Taí a separação republicano x democrata na área de programação: simplicidade x complexidade.
Não estou falando que é o seu caso, Mario. Mas é o que eu já vi por aí.
[/quote]
Penso a mesma coisa, e existe sim esse negócio de ser cool porque fez uma coisa extremamente complexa.
Me dá arrepios quando ouço um programador dizendo: “Cara, eu sou foda.” Pode saber que ele fez uma gambiarra monstruosa.
[quote=YvGa]
Sergio, voce conseguiria detalhar um exemplo disso? Eu confesso que não consigo entender o porque de voce ter essa impressão. Você tem algo mais concreto pra exemplificar?[/quote]
Eu trabalhei em dois lugares diferentes que faziam a mesma coisa e um era totalmente zoneado e o outro era a coisa mais bela e limpa que eu já vi. Não por coincidência o zoneado adorava teste unitário e o limpo ignorava os mesmos.
Agora eu realmente queria encontrar um exemplo open-source de arquitetura boneca russa. O cara só percebe a zona quando ele trabalha a fundo com o código fonte e começa a ver quão difícil é fazer as coisas ou entender o flow. Se um dia eu encontrar algo assim open-source eu te aviso. Com certeza deve ter…
[quote=saoj][quote=YvGa]
Sergio, voce conseguiria detalhar um exemplo disso? Eu confesso que não consigo entender o porque de voce ter essa impressão. Você tem algo mais concreto pra exemplificar?[/quote]
Eu trabalhei em dois lugares diferentes que faziam a mesma coisa e um era totalmente zoneado e o outro era a coisa mais bela e limpa que eu já vi. Não por coincidência o zoneado adorava teste unitário e o limpo ignorava os mesmos.
Agora eu realmente queria encontrar um exemplo open-source de arquitetura boneca russa. O cara só percebe a zona quando ele trabalha a fundo com o código fonte e começa a ver quão difícil é fazer as coisas ou entender o flow. Se um dia eu encontrar algo assim open-source eu te aviso. Com certeza deve ter…[/quote]
Pois é, existem casos que não é necessário usar, senão vira burocrático, vai atrapalhar mais do que ajudar. O simples é genial.
