Adversarial / emparelhamento Naive com TDD: Como é que é eficaz?

Question

Um amigo meu estava explicando como eles fazem ping-pong emparelhamento com TDD em seu local de trabalho e ele disse que eles tomam uma abordagem "contraditório". Isto é, quando a pessoa mãos teste de escrita do teclado para o implementador, as tentativas implementador para fazer o (coisa e às vezes errado) mais simples nua para fazer o teste passar.

Por exemplo, se eles estão testando um método GetName () e as verificações de teste para "Sally", a implementação do método GetName seria simplesmente:

public string GetName(){
    return "Sally";
}

Qual seria, é claro, passar no teste (ingenuamente).

Ele explica que isso ajuda a eliminar testes ingênuos que verificam valores específicos enlatados em vez de testar o comportamento real ou estado esperado de componentes. Ele também ajuda a impulsionar a criação de mais testes e, finalmente, uma melhor concepção e menos erros.

Parecia bom, mas em um curto sessão com ele, parecia que levou muito mais tempo para obter através de uma única rodada de testes do que de outra forma e eu não sinto que um monte de valor extra foi adquirida.

Você usa esta abordagem, e se assim for, você já viu isso compensa?

Answer 1

É baseado na personalidade da equipe. Cada equipe tem uma personalidade que é a soma de seus membros. Você tem que ser não tomar cuidado para praticar implementações passivo-agressivo feito com um ar de superioridade. Alguns desenvolvedores estão frustrados com implementações como

return "Sally";

Essa frustração levará a uma equipe bem-sucedida. Eu estava entre o frustrado e não vê-lo pagar. Eu acho que a melhor abordagem é a comunicação mais oral, fazendo sugestões sobre como um teste pode ser melhor implementada.

Answer 2

Pode ser muito eficaz.

Isso força você a pensar mais sobre o que testar você tem que escrever para obter o outro programador para escrever a funcionalidade correta que você precisa.

Você constrói o pedaço de código por peça passando o teclado com freqüência

Pode ser muito cansativo e demorado, mas eu descobri que a sua rara que tive de voltar e corrigir um erro em qualquer código que foi escrito assim

Answer 3

Eu usei essa abordagem. Ele não funciona com todos os pares; algumas pessoas são apenas naturalmente resistente e não vai dar-lhe uma oportunidade honesta. No entanto, ele ajuda você a fazer TDD e XP corretamente. Você quer tentar e adicionar recursos para sua base de código lentamente. Você não quer escrever um enorme teste monolítica que vai levar um monte de código para satisfazer. Você quer um monte de testes simples. Você também quer ter certeza de que você está passando o teclado e para trás entre seus pares regularmente, de modo que ambos os pares estão envolvidos. Com o emparelhamento contraditório, que está fazendo as duas coisas. Testes simples levar a implementações simples, o código é construído lentamente, e ambas as pessoas estão envolvidas em todo o processo.

Answer 4

Eu gosto dele por algum tempo - mas não use esse estilo o tempo todo. Atua como uma boa mudança de ritmo, às vezes. Eu não acho que eu gostaria de usar o estilo de todos os tempos.

Eu achei uma ferramenta útil com iniciantes para introduzir como os testes podem conduzir a implementação embora.

Answer 5

(Primeira, fora, Adversarial TDD deve ser divertido. Ele deve ser uma oportunidade para o ensino. Não deve ser uma oportunidade para rituais de dominância humanos. Se não houver espaço para um pouco de humor, em seguida, deixar a equipe . Desculpe. a vida é curta para desperdiçar em um ambiente negativo.)

O problema aqui é mal chamado testes. Se o teste ficou assim:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

Então eu aposto que ele foi nomeado "testGetNameReturnsNameField". Este é um nome ruim, mas não imediatamente óbvio assim. O nome adequado para este teste é "testGetNameReturnsSally". Isso é o que ele faz. Qualquer outro nome é embalando-lo em uma falsa sensação de segurança. Assim, o teste é mal nomeado. O problema não é o código. O problema não é nem mesmo o teste. O problema é o nome do teste.

Se, em vez disso, o testador tinha nomeado o teste "testGetNameReturnsSally", então ele teria sido imediatamente óbvio que este é provavelmente não testar o que queremos.

Por isso, é dever do implementador para demonstrar a má escolha do testador. É também o dever do implementador para escrever somente o que os testes exigem deles.

Assim, muitos erros na produção ocorre não porque o código foi menor que o esperado, mas porque ele fez mais. Sim, houve testes de unidade para todos os casos esperados, mas não havia testes para todos os casos de ponta especiais que o código fizeram porque o programador pensou "É melhor eu só faço isso também, provavelmente vamos precisar que" e depois esqueceu isto. É por isso que TDD funciona melhor do que test-depois. É por isso que nós jogamos código embora depois de um pico. O código pode fazer todas as coisas que você quer, mas provavelmente faz algumas coisas que você pensou que necessário, e depois esqueceu.

Força o escritor de teste para testar o que eles realmente querem. Apenas escrever código para fazer testes passam e nada mais.

RandomStringUtils é seu amigo.