Aniche Mauricio - Test-Driven Development: Teste e Design no Mundo Real com .NET стр 13.

Шрифт
Фон

{

public String Nome { get; private set; }

public double Salario

{ get; private set; }

public Cargo Cargo { get; private set; }

public Funcionario(String nome, double salario, Cargo cargo)

{

this.Nome = nome;

this.Salario = salario;

this.Cargo = cargo;

}

}

Repare que um funcionário possui nome, salário e cargo. O cargo é representado

por uma enumeração. Nesse momento, a enumeração contém apenas desenvolvedor,

testador e DBA. Em uma situação real, essa enumeração seria maior ainda; mas com

esses 3 já gera uma boa discussão.

As regras de negócio são as seguintes:

Desenvolvedores possuem 20% de desconto caso seu salário seja maior do que

R$ 3000,0. Caso contrário, o desconto é de 10%.

DBAs e testadores possuem desconto de 25% se seus salários forem maiores

do que R$ 2500,0. 15%, em caso contrário.

4.2

Implementando da maneira mais simples possí-

vel

É hora de implementar essas regras.

Uma primeira ideia é criar uma classe

CalculadoraDeSalario, que recebe um Funcionario e retorna o salário do fun-

cionário com o desconto já subtraído.

34

Casa do Código

Capítulo 4. Simplicidade e Baby Steps

O primeiro cenário a ser testado será o de desenvolvedores com salários menor

do que R$3000,0. Sabemos que o desconto é de 10%. Portanto, se o desenvolvedor

ganhar R$1500,00, seu salário menos desconto deve ser de R$ 1350,00 (1500 * 90%):

[TestFixture]

public class CalculadoraDeSalarioTest

{

[Test]

public void

DeveCalcularSalarioParaDesenvolvedoresComSalarioAbaixoDoLimite()

{

CalculadoraDeSalario calculadora = new CalculadoraDeSalario();

Funcionario desenvolvedor = new Funcionario

("Mauricio", 1500.0, Cargo.DESENVOLVEDOR);

double salario = calculadora.CalculaSalario(desenvolvedor);

Assert.AreEqual(1500.0 * 0.9, salario, 0.00001);

}

}

Hora de fazer o teste passar. Mas lembre-se que a ideia é fazer o teste passar da

maneira mais simples possível. Veja o código abaixo:

public class CalculadoraDeSalario

{

public double CalculaSalario(Funcionario funcionario)

{

return 1350.0;

}

}

É possível ser mais simples do que isso? O código retorna diretamente o valor

esperado pelo teste! Isso é aceitável, pois o código ainda não está finalizado.

Vamos agora ao próximo cenário: desenvolvedores que ganham mais do que R$

3000.0. O teste é bem similar ao anterior:

[Test]

public void

35

4.2. Implementando da maneira mais simples possível

Casa do Código

DeveCalcularSalarioParaDesenvolvedoresComSalarioAcimaDoLimite()

{

CalculadoraDeSalario calculadora = new CalculadoraDeSalario();

Funcionario desenvolvedor = new Funcionario

("Mauricio", 4000.0, Cargo.DESENVOLVEDOR);

double salario = calculadora.CalculaSalario(desenvolvedor);

Assert.AreEqual(4000.0 * 0.8, salario, 0.00001);

}

Novamente, fazemos o teste passar da maneira mais simples possível. Veja o

código abaixo:

public double CalculaSalario(Funcionario funcionario)

{

if(funcionario.Salario > 3000) return 3200.0;

return 1350.0;

}

Um simples if que verifica o salário do funcionário e retorna os valores espera-

dos.

O próximo teste agora garante que DBAs com salários inferior a R$1500,00 re-

cebem 15% de desconto:

[Test]

public void deveCalcularSalarioParaDBAsComSalarioAbaixoDoLimite()

{

CalculadoraDeSalario calculadora = new CalculadoraDeSalario();

Funcionario dba = new Funcionario

("Mauricio", 500.0, Cargo.DBA);

double salario = calculadora.CalculaSalario(dba);

Assert.AreEqual(500.0 * 0.85, salario, 0.00001);

}

Para fazer esse teste passar da maneira mais simples, basta novamente colocar

um outro if :

36

Casa do Código

Capítulo 4. Simplicidade e Baby Steps

public double CalculaSalario(Funcionario funcionario)

{

if(funcionario.Cargo.Equals(Cargo.DESENVOLVEDOR))

{

if(funcionario.Salario > 3000) return 3200.0;

return 1350.0;

}

return 425.0;

}

Repare que, se

for desenvolvedor, continuamos usando aquele código simples

que escrevemos. Caso contrário, retornamos 425.0, que o valor esperado para o sa-

lário do DBA.

Mas agora, antes de continuarmos, precisamos discutir sobre o processo utili-

zado até agora.

4.3

Passos de Bebê (ou Baby Steps)

A ideia de sempre tomar o passo mais simples que resolva o problema naquele mo-

mento (e faça o teste passar) é conhecido pelos praticantes de TDD como baby steps.

A vantagem desses passos de bebê é tentar levar o desenvolvedor sempre ao código

mais simples e, por consequência, mais fácil de ser compreendido e mantido poste-

riormente.

O problema é que a ideia dos passos de bebê é muito mal interpretada por muitos

praticantes. Por exemplo, veja que ao final, tínhamos 3 testes, 2 para as regras do

desenvolvedor e 1 para a regra do DBA, e a implementação final gerada até então

era:

public double CalculaSalario(Funcionario funcionario)

{

if(funcionario.Cargo.Equals(Cargo.DESENVOLVEDOR))

{

if(funcionario.Salario > 3000) return 3200.0;

return 1350.0;

}

return 425.0;

}

Repare que, a cada teste, nós implementamos a modificação mais simples (TDD

37

4.3. Passos de Bebê (ou Baby Steps)

Ваша оценка очень важна

0
Шрифт
Фон

Помогите Вашим друзьям узнать о библиотеке