Quem faz o desenvolvimento orientado a testes?

Eu tenho trabalhado no espaço corporativo nos últimos 4 anos e meio e percebi que, de um modo geral, as empresas não são ambientes propícios ao estilo de desenvolvimento do primeiro teste. Os projetos geralmente são de custo fixo, cronograma fixo e estilo cascata. Qualquer teste de unidade, se feito, geralmente vem após o desenvolvimento na fase de controle de qualidade e realizado por outra equipe.

Antes de trabalhar para uma empresa, consultei muitas empresas de pequeno e médio porte, e nenhuma delas estava disposta a pagar por um projeto de desenvolvimento de estilo de teste. Eles geralmente queriam que o desenvolvimento fosse iniciado imediatamente, ou após um curto período de design: ou seja, algo mais parecido com o Agile, embora alguns clientes desejassem que tudo fosse mapeado de maneira semelhante à cascata.

Com que tipos de lojas, empresas e clientes o desenvolvimento orientado a testes funciona melhor? Que tipos de projetos tendem a favorecer o TDD?

Cada linha de código que escrevo está usando desenvolvimento orientado a testes. Se a gerência não está de acordo com os testes de escrita primeiro, não digo à gerência sobre isso. Sinto fortemente que o desenvolvimento orientado a testes é um processo melhor.

Meu chefe me deu um bom presente hoje, acho que vou roubá-lo como se ele estivesse roubando de outra pessoa.

"Você esperaria que um carpinteiro medisse o quadro antes que ele o cortasse?"

Tive aulas de carpintaria no ensino médio e trabalhei na construção até a escola. Nosso mantra era sempre "meça duas vezes, corte uma vez", seguido pelo sarcástico "eu cortei e cortei novamente e ainda era muito curto!"

Se você testar depois, criará um retrabalho, pois o código que você escreverá será difícil de testar. Quando você testar primeiro, ou mesmo testar um pouco-no-meio-mas-antes-de-confirmar o software que você criar, será mais fácil testar. Uma empresa que cria testes de unidade após a gravação do código de produção para satisfazer uma lista de verificação está desperdiçando esforço.

A integração com o software difícil de testar existente também criará um esforço adicional, pois você precisará criar costuras de teste para poder controlar as dependências que seu novo e brilhante código orientado a testes consome. Em alguns casos, como em estruturas que fazem uso pesado do estado global e dos objetos divinos, isso pode ser muito difícil de alcançar. A dificuldade percebida do desenvolvimento orientado a testes geralmente se resume a uma combinação de inexperiência na escrita de bons testes e na tentativa de testar códigos fortemente acoplados.

Você pode testar o código de unidade, mesmo em um projeto em cascata, é uma disciplina de engenharia e não uma técnica de gerenciamento de projetos.

Eu não sou um fanático por TDD, mas ele ensina muito sobre design de software.

Tenha paciência comigo, pois isso terá um sabor distintamente .Net: p

No que diz respeito aos tipos de projetos que são passíveis de abordagem do primeiro teste, algumas coisas que eu procuraria:

• você está lidando com uma base de código existente? Muitas vezes, é proibitivamente caro modernizar a suíte de testes. Tenha uma idéia de quanta dívida técnica herdada existe
• certas plataformas e estruturas são inerentemente hostis ao teste. Experiência recente que está na minha mente - o SharePoint, por exemplo, é muito difícil (mas não impossível) para TDD. Para coisas como essa, talvez você precise recorrer a um produto isolador comercial, como o TypeMock pode ajudar.
• certas abordagens de implementação se prestam melhor ao TDD do que outras. Por exemplo, ASP.Net com code-behinds - não é tão testável. ASP.Net MVC - testável. Silverlight com code-behinds - não é tão testável. Silverlight com MVVM - testável.

Por fim, enquanto "a organização" pode fazer muito para apoiar a mudança para o primeiro teste, a principal mudança que precisa acontecer está na mente dos desenvolvedores. Desisti da abordagem "escreverás primeiro os teus testes" e, em vez disso, procuro momentos de aprendizado.

+1 no comentário de mpenrow sobre não informar ao mgmt se eles têm algum problema: p

Sua situação não mudará rapidamente, e a chave para superá-la é fazer parte de sua disciplina pessoal e ser bom nisso, antes de tentar empurrá-la para os outros. Se você pode ser o exemplo disso, seus gerentes devem ver benefícios objetivos.

Você também pode criar bons casos de negócios:

• O TDD pode ser simplesmente resumido como "especificação com a qual o sistema pode verificar-se automaticamente". Não está programando de maneira diferente, não está criando um produto diferente.

• O teste de unidade é realmente apenas uma forma de teste automatizado; que apenas permite que o computador faça por si mesmo o que a empresa provavelmente está pagando aos engenheiros do setor de carnes para fazer manualmente. Os testes automatizados são executados com mais rapidez, consistência e, quando bem escritos, fornecem feedback, descrições e orientações rápidas, concisas e precisas, além de orientações para o problema

• O TDD, quando é feito por alguém que sabe o que está fazendo, produz resultados tão rapidamente quanto o primeiro código. Haverá uma curva de aprendizado / treinamento (e, se seus engenheiros pertencerem a um grupo menor de talentos, isso poderá acabar com suas chances de pressionar o TDD - nesse caso, o melhor que você pode fazer é continuar a defendê-lo. e faça a gerência questioná- los em vez de TDD)

• O TDD é muito importante para pensar na tarefa em questão antes de iniciá-la. É como "medir duas vezes, cortar uma vez" - a medição extra acrescenta uma quantidade marginal de tempo à tarefa, mas evita desperdiçar seu recurso mais precioso - horas de desenvolvimento).

... e lembre-se; a coisa mais importante que você pode fazer é liderar pelo exemplo. Se você é duro no TDD, invista algumas horas extras para se tornar melhor. Quando você for proficiente, comece a fazê-lo no trabalho (seus gerentes realmente se queixariam de que você escreve testes?). Lute uma batalha de cada vez e dê passos em direção a ela. Ir para todo o shebang provavelmente resultará em fracasso e a culpa cairá sobre você se você se esforçar muito por isso.

Eu faço. É a minha maneira preferida de desenvolvimento, e trabalho para uma grande empresa financeira, feliz em trabalhar da maneira que achar melhor, desde que cumpra os prazos e produza código de qualidade. Feito corretamente, o primeiro desenvolvimento de teste não precisa levar mais tempo que o teste após o desenvolvimento e não vamos esquecer as outras recompensas do primeiro desenvolvimento de teste, com menos defeitos do teste do sistema posteriormente.

A chave para fazer o TDD é apenas fazê-lo como parte da escrita do seu código e, se necessário, você não diz a ninguém que está fazendo isso. Não é necessário explicar tudo o que você está fazendo. Seu resultado final é um código de trabalho.

Se você explicar "Estou escrevendo testes", os Poderes que podem dizer "Oh, nós podemos eliminar isso!" Mas se você não contar a ninguém, ainda terá os testes como resíduo do processo de codificação.

Programar é mais do que digitar declarações de trabalho em um editor. Se as pessoas não conseguem lidar com isso, proteja-as desta verdade até que estejam prontas para lidar com isso. "Pronto para lidar com isso", neste caso, significa quando você tem um ou dois projetos concluídos, concluídos dentro do prazo com um código sólido e confiável e, sim, veja, você também tem testes de unidade.

É triste dizer que eu não tive a chance de usá-lo no sentido verdadeiramente clássico do primeiro teste, então não posso dizer "eu! Eu! Faço!". Estou assumindo que a pergunta está perguntando "que indústrias / empresas usam TDD de maneira geral" em vez de "alguém pode infiltrar o TDD em suas vidas diárias?". Concordo que um desenvolvedor individual pode totalmente fazer TDD sem forçar todo o grupo a fazê-lo, só não acho que esse foi o ponto da questão.

Minha impressão ao escutar o setor é que é mais provável que você veja TDD na maioria dos grupos de desenvolvimento de uma empresa em situações em que:

• Não existe uma grande base de códigos existente antes do início do TDD

• A empresa não é enorme e, portanto, não possui muitas das contrariedades "sempre fizemos o contrário".

• A empresa não possui uma enorme adesão ao processo formalizado. Isso não quer dizer que você não possa implementar o TDD em, por exemplo, uma empresa certificada pelo CMMI - mas se você tivesse um processo que não seja TDD, obter todos os processos que você monitora com o CMMI atualizado pode ser um grande investimento.

• Os testes podem ser executados por script - essa é a base de código mais complexa, pois mesmo que você não consiga criar facilmente a camada mais próxima do usuário, é possível criar scripts de alguns dos elementos internos. Porém, vejo situações com opções bem desenvolvidas para automação de testes como os locais mais agradáveis ​​para TDD, já que é baseado em reexecutar e não quebrar toda uma bateria de testes em que você precisa de feedback rapidamente. Meu pensamento é que um aplicativo Web independente é um bom alvo de TDD, um sistema com grande integração ou entrada de COTS que não seja baseada em GUI pode ser complicado.

• Sistemas em um estado não prototipado. Idealmente, a próxima grande versão após o protótipo - onde a prova de conceito é finalizada e o projeto é financiado, mas todo mundo sabe que a próxima tentativa precisa ter qualidade.

• Partes interessadas que são investidas no processo.

Tentei sempre que possível - mas acho que é realmente o ambiente corporativo em que você se encontra. Trabalhei na indústria de jogos por muitos anos (como artista entre artistas) e não havia conceito de TDD - apenas uma abordagem de controle de qualidade de força bruta. Mudei para o desenvolvimento web e ainda não trabalhei em uma agência com nenhum reconhecimento formal (ou conhecimento de ...) testes de unidade / TDD. O mesmo vale para a maioria dos meus colegas do setor, que trabalham em uma ampla variedade de disciplinas.

Em uma agência focada nas vendas, a TDD oferece muito pouco retorno sobre o investimento ( ROI) de curto prazo para o cliente, e, portanto, é difícil vender para os gerentes de linha ao definir o escopo de um projeto. Quanto maior o projeto, no entanto, mais convincente ele se torna.

Dado que livros como a Marcha da Morte apontam para um fenômeno predominante, ou seja, uma indústria atormentada pelo desenvolvimento impulsionado pela "crise" e pelo "marco" - aposto que o TDD é provavelmente raro fora de startups bem financiadas ou lojas corporativas monolíticas. Não é que as pessoas não acreditem no valor do TDD - mas é abstrato demais para vender a seus clientes.

Estou tentando entrar no TDD. Eu acho que, desde que você siga as rotas que você já conhece (o dia a dia do trabalho), é bastante simples. Mas eu simplesmente não consigo entender os testes para as partes da interface do usuário ou quando você precisa criar uma nova solução para algum problema que você não encontrou antes. Ou usando uma estrutura que você não conhece.

Então, acho que você precisa fazer algum tipo de LearningTests, separar provas de conceitos e reescrevê-las depois etc. etc. ou estou errado?

E (eu sei que é antigo, mas ainda não vi uma boa resposta): como você codifica algoritmos usando TDD (quando os resultados podem ser complexos para realmente "afirmar" com facilidade)?

Eu realmente posso ver os lados positivos do TDD e estou no barco, mas é muito difícil para iniciantes quando o código que você escreve leva quase o dobro do tempo (e você tem colegas que não vêem os profissionais e zombam de você com RAD)

Eu tentei algumas vezes e funcionou muito bem. Infelizmente, na maioria das vezes, se eu posso testar manualmente meu aplicativo, adio os testes de unidade até me sentir entediado demais para implementar outra coisa ou há um erro que não consigo corrigir facilmente.

Eu faço. O progresso de nossas histórias de usuários é rastreado em um quadro Kanban, que possui um "Tem um teste?" coluna à esquerda (a montante) de Desenvolvimento.

Esse layout um tanto incomum torna uma política explícita: um teste de aceitação automatizado com falha (geralmente, alguns deles) deve existir. Ele deve ser rastreável a um requisito do cliente. Os testes de aceitação surgem de condições de satisfação , resultantes de conversas que começam com um cartão de história . Facilito oficinas regulares, onde discutimos requisitos, identificamos lacunas e identificamos os principais testes de aceitação que garantem que o valor do usuário seja entregue quando eles passam (a definição de concluído ). É uma atividade colaborativa que envolve programadores, analistas de negócios e, às vezes, testadores.

O ciclo de feedback dos testes de aceitação é longo: pode levar vários dias para concluir a história. O desenvolvimento possui seus próprios loops de feedback TDD mais curtos.

"[... sem estilo de teste primeiro ...] Mais parecido com o Agile ...."

Esta é uma deturpação completa do Agile. A definição de done é um componente-chave do Agile e um dos pilares em que se baseia é o teste de aceitação automatizado (o que eu descrevi acima é uma maneira de fazê-lo.) Se a programação extrema (XP) for usada como um método de implementação Agile, então ATDD / BDD e TDD são prescritos.

Sim, mas geralmente apenas para componentes que não são da interface do usuário, e quando eu sei que não consigo manter todo o algoritmo de um módulo em minha cabeça ao mesmo tempo, ou quando o módulo é uma nova parte de qualquer sistema em que estou trabalhando, portanto, não posso confiar na maioria das bibliotecas que estou usando para ter sido altamente depurada.

Essencialmente, eu faço isso quando a complexidade do requisito significa que eu poderia me perder no código.

É um hábito difícil de começar, e exige adesão da gerência, mas, quando seus testes começam a meio caminho do desenvolvimento, pode salvar a vida toda!

Eu queria fazer essa pergunta, para ver quantas empresas estavam realmente praticando TDD.

Nos 11 anos que tenho programado profissionalmente, apenas as duas últimas organizações estavam cientes do TDD (que dura quase cinco anos, antes do que o TDD não era tão popular quanto hoje). Vou direto ao assunto e responder à sua pergunta antes de entrar no meu discurso de vendas para o TDD :)

Na última empresa em que trabalhei (editora acadêmica on-line de humanidades e coleções de ciências), sabíamos que precisávamos praticar TDD, mas nunca chegamos lá. Em nossa defesa, tínhamos uma base de código de 250k; portanto, adicionar testes a uma base de código não testável desse tamanho parecia insuperável (me sinto culpado ao digitar isso agora!). Até os melhores de nós cometem erros .

Qualquer um que tenha feito até mesmo uma pequena quantidade de TDD sabe como os testes de retromontagem dolorosos podem ser um código não testável em campo marrom ... As principais causas são dependências implícitas (você não pode usar todas as alavancas para garantir resultados do código - você não pode zombar cenários) e violação do princípio de responsabilidade única (os testes são complicados, inventados, exigem muita configuração e são difíceis de entender ).

Aumentamos temporariamente nossa equipe de controle de qualidade (de uma, talvez duas pessoas para meia dúzia ou mais) para testar a plataforma antes de qualquer lançamento. Foi extremamente caro em termos de tempo e financeiramente, alguns lançamentos levariam três meses para concluir o 'teste'. Mesmo assim, sabíamos que estávamos enviando problemas, eles simplesmente não eram 'bloqueadores' ou 'críticos', apenas 'de alta prioridade'.

Se você tiver uma experiência comercial de vários anos, perceberá que toda empresa assume tarefas críticas e inventa um nível de prioridade mais alto acima disso, e provavelmente um acima disso também - especialmente quando alguém de cima está pressionando um recurso / correção de bug. Eu discordo ...

Fico feliz em informar que estou praticando TDD em minha empresa atual (empresa de desenvolvimento de telecomunicações, web e aplicativos móveis), juntamente com o Jenkins CI para fornecer outros relatórios de análise estática (a cobertura de código é a mais útil após a aprovação da aprovação no conjunto de testes) . Os projetos em que usei o TDD são um sistema de pagamento e um sistema de computação em grade.

O discurso de vendas ...

Muitas vezes, pode ser uma luta difícil justificar testes automatizados para membros não técnicos da equipe. Escrever testes adiciona mais trabalho ao processo de desenvolvimento, mas ... o tempo que você investe em testes agora, economiza em esforços de manutenção mais tarde. Você está realmente apenas emprestando tempo . Quanto mais tempo o produto estiver em uso, maior será a economia - e isso ajudará a evitar a grande reescrita .

Teste primeiro significa que você está codificando sua intenção primeiro e, em seguida, confirmando que seu código cumpre essa intenção. Isso fornece foco e destila seu código para fazer apenas o que se destina e não mais (leia sem inchaço). É uma especificação e documentação executável ao mesmo tempo (se o seu teste estiver bem escrito, e os testes devem ser tão legíveis / limpos quanto o código do sistema, se não mais!).

Os não programadores (geralmente) não têm esse insight e, portanto, o TDD não tem muito valor para eles, e é visto como um atalho descartável para uma data de lançamento anterior.

A programação é o nosso domínio e, em minha opinião, isso torna nossa responsabilidade , como profissionais, aconselhar sobre as melhores práticas como o TDD. Não cabe aos gerentes de projeto decidir se isso é feito para reduzir o tempo de desenvolvimento, mas está fora de sua jurisdição . Da mesma forma, eles não informam qual estrutura, solução de cache ou algoritmo de pesquisa usar, não devem informar se você deve empregar testes automatizados.

Na minha opinião, o setor de desenvolvimento de software (no geral) está quebrado no momento, o fato de ter testes para o seu software NÃO é a norma.

Imagine isso em outras indústrias: médica, aviação, automóvel, cosméticos, brinquedos macios, bebidas alcoólicas etc. Pedi à minha noiva que nomeiasse uma indústria na qual eles não testam o produto e ela não podia!

Talvez seja injusto dizer que nenhum teste ocorre porque ocorre ... mas em empresas sem testes automatizados, é um processo muito manual / humano (leia-se desajeitado e geralmente propenso a erros).

Um ponto que eu argumentaria na sua pergunta ...

Eles geralmente queriam que o desenvolvimento fosse iniciado imediatamente, ou após um curto período de design. Mais parecido com o Agile.

Sendo "Agile" não prescreve procedimentos sem testes, o primeiro membro listado no agilemanifesto.org é Kent Beck , criador do XP e TDD!

Dois livros que eu recomendo se você estiver interessado em TDD, ou simplesmente não os leu e é um programador interessado (é todo mundo que está lendo isso certo?;)

Crescimento de software orientado a objetos guiado por testes

Código Limpo - Série Robert C Martin ("Tio Bob")

Esses dois livros se complementam e condensam muito sentido em poucas páginas.

Obrigado por fazer esta pergunta :)

Aqueles que implementam clones. Não consigo pensar em um processo melhor para desenvolver algo, que funciona exatamente como um programa existente.

Obviamente, este é um caso bastante incomum, mas os desenvolvedores do SQLite usam testes extensivamente. (Presumo que o processo de desenvolvimento deles seja primeiro de teste, embora não tenha certeza.)

• 73.000 linhas de código
• 91.378.600 linhas de código de teste

Consulte http://www.sqlite.org/testing.html