Prodis a.k.a. Fernando Hamasaki de Amorim

Eu compartilho da opinião de Jimmy Bogard, que diz que os nomes dos testes precisam descrever o que e o porque, a partir da perspectiva do usuário, onde o desenvolver possa ler o nome do teste e claramente entender o comportamento que é esperado.

Um teste unitário nada mais é que um método em uma classe, e tanto em C# como Java, existem convenções de nomenclatura de métodos.

Em C#, nome de métodos são declarados utilizando Pascal Case:

[TestMethod]
public void ProductShouldHaveAtLeastOneCategory()
{
  //Test implementation.
}

Já em Java, convencionou-se escrever métodos utilizando Camel Case:

@Test
public void productShouldHaveAtLeastOneCategory() {
  //Test implementation.
}

Muitas vezes, o nome desses testes (métodos) ficam um tanto longos, como os exemplos acima. Dessa forma, a legibilidade não é muito boa.

Seguindo um dos conselhos de Neal Ford, em sua apresentação 10 Ways to Improve Your Code, você pode deixar de lado as convenções de nomenclatura da linguagem em favor da legilidade dos nomes dos seus testes. Escreva o nome do teste como se fosse uma frase, nada de letras maiúsculas para cada palavra, e use “_” (underscore) para separar as palavras.

Veja como fica o exemplo acima em C#:

[TestMethod]
public void Product_should_have_at_least_one_category()
{
  //Test implementation.
}

E agora em Java:

@Test
public void product_should_have_at_least_one_category() {
  //Test implementation.
}

Não há nenhum mal em se desprender das convenções de nomenclatura de C# e Java em prol da legibilidade dos nomes dos testes. Afinal, testes são uma documentação executável e nós queremos uma documentação clara para nosso código.

TDD Boas Práticas, C#, Convenções, CSharp, Java, Nomenclatura, TDD, Testes

Quando você tiver um método em que o retorno é algum tipo de coleção, ou seja, qualquer classe que implemente IEnumerable ou uma de suas interfaces filhas, nunca retorne null.

Quando a lógica do seu método não tiver elementos para serem colocados na coleção de retorno, você deve retornar uma lista vazia, com zero elementos. Essa boa prática vai facilitar a vida do código que irá consumir seu método.

Vamos ver um exemplo de um método que retorne uma coleção:

public class BookService
{
    public IList<Book> FindBooksByTitle(string startsWith)
    {
        //Alguma lógica que não encontra nenhum livro.
        return null;

        //Código restante.
    }
}

E o código que consome o método FindBooksByTitle:

BookService bs = new BookService();

foreach (var book in bs.FindBooksByTitle("The history"))
{
    //Faz alguma coisa com a variável book.
}

Do jeito que está, se nenhum livro for encontrado de acordo com o critério passado, o valor retornado será null. Consequentemente, na linha 3 do código consumidor será gerada uma exceção do tipo NullReferenceException, pois tentará iterar através do foreach em uma variável nula.

Como resolvemos isso? Ah, basta colocar uma verificação se o retorno do método é nulo:

BookService bs = new BookService();
IList<Book> books = bs.FindBooksByTitle("The history");

if (books != null)
{
    foreach (var book in books)
    {
        //Faz alguma coisa com a variável book.
    }
}

Errado! O código que consome o método não pode ficar responsável por fazer esse tratamento. Senão, todo código que consumir o método FindBooksByTitle precisará fazer essa verificação de retorno nulo antes de iterar na coleção. Essa responsabilidade tem de ficar dentro da classe BookService e não fora dela.

Consertando o exemplo para retornar uma lista vazia:

public class BookService
{
    public IList<Book> FindBooksByTitle(string startsWith)
    {
        //Alguma lógica que não encontra nenhum livro.
        return new List<Book>();

        //Código restante.
    }
}

Agora o código consumidor pode iterar sem erros, mesmo que não seja encontrado nenhum livro:

BookService bs = new BookService();

foreach (var book in bs.FindBooksByTitle("The history"))
{
    //Faz alguma coisa com a variável book.
}

.NET .NET, Boas Práticas, Coleções, IEnumerable

Vou aproveitar o embalo do post sobre Automatização que o Erich colocou no blog de Tecnologia da Locaweb, onde ele fala que Neal Ford, no seu último livro “The Productive Programmer“, escreveu um capítulo inteiro sobre o assunto.

No último mês de novembro, estive na QCon San Francisco 2008 e tive o privilégio de assistir à palestra
“10 Ways to Improve Your Code” apresentada por Neal Ford.

São elas:

1. composed method
2. test-driven development, test-driven design
3. static analysis
4. good citizenship
5. yagni: you ain’t gonna need it
6. question authority
7. slap: single level of abstraction principle
8. polyglot programming
9. every nuance
10. anti-objects

Você pode assistir à palestra que agora está disponível no site da InfoQ:
http://www.infoq.com/presentations/10-Ways-to-Better-Code-Neal-Ford

Baixe também os slides da apresentação em PDF neste endereço:
http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//NealFord_10_Ways_to_Improve_Your_Code.pdf

Apresentações, Arquitetura, TDD Apresentações, Boas Práticas, OOP, Programação Orientada a Objetos, QCon, TDD, XP