Casos de teste de sucesso e falha do grupo

Os testes podem ser documentação. Para isso, ajude outros desenvolvedores a entender rapidamente como seu código não deve apenas funcionar, mas também como deve falhar.

Imagine que você tem um trecho como este. É Objective-C, mas a lógica deve ser fácil de transferir para outro lugar.

- (void)storeMagicNumber:(int)num
{
    if (num == 42)
    {
        [self storeNumber:num];
    }
    else
    {
        @throw [NSException exceptionWithName:@"MagicNumber" reason:[NSString stringWithFormat:@"%i is not a magic number.", num] userInfo:nil];
    }
}

O código acima aceita qualquer número inteiro, mas irá gerar um erro se não for 42. Se você fornecer o número mágico, ele o embaralhará para algum método auxiliar para armazená-lo.

Seus testes devem ser semelhantes aos abaixo. Estou usando a sintaxe Kiwi , mas, novamente, a lógica deve ser transferível para outros testes.

describe(@"storeMagicNumber:", ^{
    context(@"Success, ^{
        it(@"should ask to store the supplied number if it's the magic number", ^{
            ...
        });
    });

    context(@"Failure", ^{
        it(@"should throw an error if magic number not supplied", ^{
            ...
        });

        it(@"should have the supplied number in the exception message", ^{
            ...
        });
    });
});

Apenas um pouco de agrupamento simples permite a digitalização mais rápida e agrupamento de configuração e desmontagem para casos específicos. Esse último detalhe se torna extremamente útil quando você começa a fazer uso mais intenso de stub, especialmente em torno de coisas como solicitações de rede, pesquisas de banco de dados e chamadas assíncronas.

Vá em frente, organize-se de acordo e faça seus colegas desenvolvedores felizes!