Fala ai Radizeiros e Radizeiras, tudo bem com vocês?
Para que possamos ter um software de fácil manutenção e implementação, devemos ter códigos de alta qualidade, dominar conceitos básicos e boas práticas de programação, deixar o código limpo legível e fácil de ser mantido, se cercar de ferramentas adequadas para avaliação e manutenção dessa qualidade durante e após o desenvolvimento do código, entender e dominar princípios de qualidade na aplicação de padrões em seus projetos.
Se todas as vezes que você tem que fazer alguma manutenção em seu software é uma dor de cabeça, ou todas as vezes que outro programador vai mexer no código que você fez, ele não consegue compreender o que está sendo feito, não é por que ele não sabe, é porque o seu código não está legível, não segue as boas práticas da programação.
Toda nova implementação no software parece um parto, e quando você consegue o realiza os testes, e coloca em produção, cliente liga reclamando que depois da atualização ocorreu problemas em outras parte do software, e a analisar você se depara com outras implementações que estão ligadas a sua nova implementação, esses são diversos problemas em softwares que não usam as boas praticas da programação.
Realizar testes em seus software é de extrema importância, não devemos só ter algumas pessoas que possam testar, mas em nosso software tem que existir rotinas que fazem testes e não deixe que nós venhamos publicar sem ao menos passar pelos testes.
Por este motivo estou aqui mostrando em mais um post de como usar o DUnit em seus software e automatizar as rotinas de testes e reduzir significativamente os erros em seu software.
Irei falar sobre as diretivas usadas no Assert do DUnit, falei um pouco dessa diretiva em outros posts aqui no blog.
Se você repara dentro do Assert existem diversos tipos de testes que ele pode ser feito, uns são muito usados e outros praticamente não utilizados, você com dois ou três dele você consegue implementar os testes que você precisa.
Irei mostra agora no post mais dois deles.
Na nossa classe TPessoas, iremos criar uma property Nome do tipo String.
Type
TPessoa = class
private
FNOME : String;
procedure SetNome(const Value : String);
published
function TratarCPFCNPJ(aValue : String) : String;
property NOME : String read FNOME write SetNome;
end;
Agora vamos ao nosso caso de teste e iremos criar um novo teste chamado ValidaNome.
type
[TestFixture]
TMyTestObject = class(TObject)
private
FPessoa : TPessoa;
public
[Setup]
procedure Setup;
[TearDown]
procedure TearDown;
[Test]
procedure TesteTratarCPFCNPJ;
[Test]
[TestCase('CaseCPF','123.123.123-12,12312312312')]
[TestCase('CaseCNPJ','12.123.123/0001-12,12123123000112')]
procedure TratarCPFCNPJ(aValue : String; aResult : String);
[Test]
procedure ValidaNome;
end;
Nesse método que criarmos, iremos verificar se o nome é nulo ou não, não iremos usar IF para isso e sim as funcionalidades do DUnit, usando sempre as boas praticas na programação.
procedure TMyTestObject.ValidaNome;
begin
FPessoa.NOME := 'Thulio';
Assert.IsNotEmpty(FPessoa.NOME, 'TPessoa.NOME está retornando vazio');
end;
Observe que no Assert passamos o teste IsNotEmpty e definimos aonde iremos verificar, em caso de erro ele irá nos retornar a mensagem que TPessoa.NOME está vazia.
Do jeito que está ai ao rodar nosso caso de teste ele não irá simular o erro neste método.
Se observar que todos os testes passaram.
Você tem diversas funcionalidades no Assert, no mesmo jeito que eu testo se ele não é vazio, posso testar se é igual ou não, por exemplo, no método de TratarCPFCNPJ.
procedure TMyTestObject.TratarCPFCNPJ(aValue, aResult : String);
begin
Resultado := FPessoa.TratarCPFCNPJ(aValue);
Assert.AreEqual(Resultado, aResult);
end;
Observe que o AreEqual está fazendo a comparação com o resultado que estou esperando.
Ao rodarmos o nosso caso de teste, ele não irá resultar em nenhum erro.
Mas para que possamos simular um erro vamos na classe TPessoa no método que estamos fazendo o teste e acrescentar algo para que você possa observar o teste funcionando.
function TPessoa.TratarCPFCNPJ(aValue : String) : String;
begin
for I := 1 to Length(aValue) do
begin
if aValue[I] in ['0'..'9'] then
Result := Result + aValue[I];
end;
Result := Result + 'x';
end;
Observe que no retorno do método eu acrescentei uma letra, vamos rodar nosso teste agora.
Eu não especifiquei uma mensagem de erro como foi feito na primeira mensagem de erro.
O que fiz foi chamar diretamente a função AreEqual, ela está verificando se as duas variáveis são iguais, como elas não são vai dar erro, observe o segundo erro, ele tem uma variável com x no final e que não é igual a outra variável.
Ele mostrou a entra e a sai e tem como saber em qual foi o caso de uso, e basta ir lá no método ajustar e validar.
Show de bola né?
Viu como podemos tratar erros de uma forma automatizada?
Chega de ficar colocando um monte de if no seu código para fazer testes, usar teste unitários é de extrema importância, não podemos deixar de lado todas as funcionalidades e ferramentas que temos no mercado para nos auxiliar nas melhorias dos nossos softwares.
Lembrando que para implementar esses caso de testes você deve ter um código limpo, seguindo as boas praticas da programação.
Esse post faz parte de um dos meus treinamentos a CERTIFICAÇÃO ESPECIALISTA EM CLEAN CODE E BOAS PRÁTICAS DE PROGRAMAÇÃO.
A Certificação Especialista em Clean Code e Boas Práticas de Programação dará a você a oportunidade de melhorar seu software, otimizar o seu tempo e te dar a possibilidade de atender melhor os seus clientes. Conhecer a fundo essas técnicas e utilizar todos os seus benefícios irá facilitar muito a sua vida quando houver necessidade por parte de um cliente de um update rápido ou resolver um problema.
CLIQUE AQUI PARA SABER MAIS SOBRE A CERTIFICAÇÃO ESPECIALISTA EM CLEAN CODE E BOAS PRÁTICAS DE PROGRAMAÇÃO
