Quebrar o "build" porque houveram erros nos testes unitários

O Elliot Rust Harold comentou em seu blog sobre o problema que pode acontecer quando todo o build e geração de artefatos de um projeto são parados por causa da falha de um teste unitário. Segundo Elliot, um teste que não passa não seria motivo suficiente para fazer com que um projeto simplesmente não seja liberado.

Go Ahead. Break the Build!

Qual é o perigo de fazer com que um sistema que tem testes que realmente não passam vá pra produção? Já saber do que o seu cliente vai reclamar na próxima vez que ligar?

Acho que se o teste não passa, realmente não se deve lançar uma versão nem liberar nada. Primeiro se resolve o problema, depois se pensa nisso.

Realmente software é um tipo raro de produto que vc compra consciente dos defeitos. Também acho irresponsabilidade liberar o produto com testes falhando. Por que simplesmente não para e corrige o problema? Afinal isso precisa ser feito mesmo.

valeuz...

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

O que o Elliot disse é o seguinte:

A tendência é você acabar não incluindo no seu build os testes que quebram bugs conhecidos mas difíceis de resolver, justamente porque quebram o build.
E o que acontece é que a solução desses bugs acaba sendo postergada.

Mas será que não tem como evitar de adicionar esses features que estão bugados?

Nesse caso específico dele, que a coisa não funciona no MacOS realmente é complicado, mas eu acho que isso é a exceção da exceção.

Eu juro que nao entendi qual eh a discussao aqui...

cv wrote:Eu juro que nao entendi qual eh a discussao aqui...

A discussão é, você entrega ou não um sistema com testes unitários que estão falhando para um cliente?

Não. Simples assim.

Se o teste foi criado é porque tem que passar, e se esta falhando, sua aplicação não está funcionando como deveria, logo, não está atendendo à necessidade do cliente.

Ou entao: que tal ser honesto com o cliente e perguntar? As vezes a funcionalidade que ele quer usar AGORA esta funcionando direitinho e ele nao se importa.

Mas, claro, se vc quiser fazer a coisa direito, o build nao deveria falhar nunca - e pra isso que existe integracao continua.

Dependendo da falha, pode ser um detalhe que o cliente nem se importaria, como algum comportamento estranho caso alguem informe um sobrenome com 3 ç juntos. Nesses casos alguem deve assumir "bom, não vou corrigir isso agora pq ninguem vai deixar de comprar o sistema MEGAPLUS 2.0 por causa desse errinho besta". Por que se o cliente perceber e se queixar, o custo de corrigir isso será bem mais caro.

É uma questão de responsabilidades.

peczenyj wrote:Dependendo da falha, pode ser um detalhe que o cliente nem se importaria, como algum comportamento estranho caso alguem informe um sobrenome com 3 ç juntos. Nesses casos alguem deve assumir "bom, não vou corrigir isso agora pq ninguem vai deixar de comprar o sistema MEGAPLUS 2.0 por causa desse errinho besta". Por que se o cliente perceber e se queixar, o custo de corrigir isso será bem mais caro.

É uma questão de responsabilidades.

Mais uma vez, não. Se o seu build falhar por causa de um sobrenome com ç, nesse caso é seu build que está com problema. Se a verificação de "ççç" não é importante pra você, ela não deveria estar lá.

Se a verificação de "ççç" não é importante pra você, ela não deveria estar lá.

Não disse que não é importante. Disse q no "fligir dos ovos" alguem pode tomar a decisão de ignorar um erro desses arcando com as consequências desta atitude. Se bem q é mais provavel q isso ocorra pro fim da qualificação, afinal a desculpa mais usada é 'não da tempo de corrigir, vai assim mesmo'

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