Iniciando novo projeto com TDD

Estou estudando TDD e li que também ajuda a definir o design do aplicativo, correto?

Então, decidi começar a criar um novo projeto para me ajudar a entendê-lo melhor.

Quero criar um sistema de registro de usuário simples que solicite seu nome, endereço de e-mail, país (escolherá um da lista) e número de telefone.

Então a questão é ...

Criei uma nova solução no VS 2010, adicionei um novo projeto de teste e simplesmente não sei quais testes escrever!

Como isso me ajudará a definir o design, que testes eu poderia escrever aqui?

Obrigado por qualquer ajuda!

Ao escrever testes de unidade, você está testando o comportamento do seu aplicativo, portanto, a pergunta importante a ser feita é o que o seu aplicativo faz ? Aqui está um começo:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

Criar um projeto de teste e escrever alguns métodos de teste é um tipo de TDD, mas, na minha experiência, não ajuda muito, a menos que você esteja trabalhando em uma biblioteca em que haja uma API conhecida e chamadas de método correspondam diretamente a algo esperado pelo usuário. . Você precisa apresentar a lista correta de testes e, para um aplicativo não trivial, isso pode ser realmente difícil de fazer.

Eu recomendo tentar o SpecFlow - ele mantém a definição de testes bem separados da implementação e a estrutura dos arquivos de recursos obriga a pensar sobre o que você está realmente testando.

Quando você define um recurso, basta escrever algo como

When a user is saved
Then the user should exist

Como você não está em um arquivo de código neste momento, não fica tentado a pensar em detalhes da implementação, como qual método é chamado para criar um usuário ou até em qual classe ele está implementado. Você pode usar tags para escolher diferentes implementações, portanto, nesse nível, não importa se "o usuário está salvo" significa uma chamada para CreateUser ou abrir um navegador e enviar um formulário.

Depois de definir os recursos, todos os testes são gerados e começarão a passar à medida que você implementa as definições de etapas e o código do aplicativo real sendo testado.

Para um aplicativo simples, você pode apenas criar os arquivos de recursos, mas para algo mais complexo, é útil reunir previamente uma especificação mais completa. Eu uso um aplicativo de mapeamento mental do iPad para isso, mas você pode usar qualquer ferramenta com a qual se sinta mais confortável.

Comece com uma lista de recursos de alto nível, como "Registro do usuário". Eles tendem a ser muito amplos para escrever testes diretamente, portanto, divida-os em sub-recursos que podem ser claramente definidos e geralmente mapeiam para uma ação específica do usuário, como "Salvar usuário" ou "Exibir usuário existente".

Cada uma dessas subfunções precisará de uma lista de cenários que, juntos, definam completamente se o recurso está ou não funcionando, como "Pode salvar um usuário válido" e "Não é possível salvar um usuário com nome de usuário duplicado".

À medida que você cria essa lista, geralmente fica claro onde a estrutura precisa ser ajustada - se você não conseguir realizar nenhum teste de cenário para um recurso ou acabar com muitos em um recurso, esse recurso provavelmente será definido em o nível errado e precisa ser dividido ou alterado.

Achei bom fazer backup de meus primeiros experimentos em TDD com algumas leituras e também com o código de corte. O artigo da Wikipedia sobre o assunto é muito bom e o levará a uma ampla variedade de outros recursos. Procure coisas de Kent Beck em particular - mais ou menos o pai da TDD.

Outras coisas que podem ajudá-lo a entrar no clima são os katas - exercícios de treinamento simples e quase irracionais. Roy Osherove tem alguns bons.

Além disso, lembre-se das principais idéias do TDD - escreva um teste de cada vez e não continue até que todos os testes anteriores passem. Escreva apenas código suficiente para satisfazer o teste atual, evite a tentação de escrever mais. À medida que avança, pare de vez em quando e pense se você pode limpar o código ou os testes. Sempre desenvolva em um ciclo de refatoração vermelho (teste de falha), verde (teste de aprovação).

E para começar, talvez comece com o seu requisito de nome. Do que você vai precisar?

Você provavelmente precisará de uma aula. Faça um teste para isso (algumas pessoas ignoram isso, mas ao começar o fazem) e escreva a classe.

Em seguida, sua turma precisará armazenar um nome. Faça um teste provando que sua classe realmente pode. Em seguida, escreva novamente o código para fazer o teste passar.

Então talvez você tenha mais algumas regras de negócios. Talvez você queira que seu nome tenha um número mínimo de caracteres. Escreva o teste, veja falhar, escreva o código.

E assim por diante...

Eu acho que não é possível dar a você a idéia de TDD em uma resposta curta. Você precisa "ver" alguém praticando, para ter a sensação disso. O melhor recurso que eu já encontrei sobre esse tópico é http://pragprog.com/titles/achbd/the-rspec-book . Antes de me dizer, que Ruby não é sua língua: leia o prefácio do tio Bob! ;-)

Convém configurar um teste que tente adicionar vários valores diferentes no campo de email, sendo alguns válidos e outros não. Não pare de desenvolver até que todos os testes dêem o valor esperado. Coisas assim.

Como você descreveu o sistema, há apenas um teste no nível do aplicativo:

[Test] public void Save_and_retrieve_user (nome da string, email da string, ...) {// Salvar // Recuperar // Verificar}

Conforme você refina os requisitos, adicione mais testes.