Assertions é uma boa prática


Assertions auxiliam o programador no desenvolvimento e depuração do código, sendo a primeira linha de defesa contra bugs.

Unsplash image Photo by Andrew Ruiz on Unsplash

Quando estamos desenvolvendo, é comum executar o programa várias vezes, digitar alguma entrada de dados “falsa”, e seguir adiante, afim de testar outras funcionalidades.

Assim, vamos construindo um protótipo.

Um protótipo pode ser codificado muito rapidamente, sendo comum codificarmos várias funcionalidades apenas para visualizarmos como seria o sistema real.

Como um protótipo pode ser alterado inúmeras vezes, vários bugs podem aparecer.

Aqui entram as Assertions.

De acordo com a Wikipedia:

In computer programming, an assertion is a statement that a predicate (Boolean-valued function, i.e. a true–false expression) is expected to always be true at that point in the code. If an assertion evaluates to false at run time, an assertion failure results, which typically causes the program to crash, or to throw an assertion exception.

Então, uma Assertion sempre deve ser verdadeira ou uma exceção EAssertionFailed será gerada e o sistema será abortado, retornando o código 227

No entanto, se a unit SysUtils for declarada em algum lugar do código, é possível verificar mais informações da exceção como a linha e a unit onde o erro foi gerado, além da mensagem opcional que o desenvolvedor pode utilizar para cada Assertion.

Uma Assertion funciona dessa forma:

procedure TForm1.Button1Click(Sender: TObject);
var
  I: Integer;
begin
  I := 0;
  Assert(I = 1, 'The I variable is not 1');
  ShowMessage(I.ToString);
end;

No código acima, temos um Form com um botão. No evento desse botão o Assert irá verificar se a variável I é igual a 1.

O resultado será falso e uma exceção será gerada.

Na minha IDE eu vejo essa mensagem:

The I variable is not 1 (unit1.pas, line 34).

Eu compilei o projeto sem informações de debugger. Mesmo assim, é possível ver a linha onde a validação ocorreu, tornando muito útil o uso de Assert para identificar onde e por quê um erro ocorreu.

Entretanto, as Assertions não deve ser utilizadas em produção. Suas informações técnicas só deveriam ser vistas por programadores, não usuários finais.

Por esse motivo nós devemos desabilitar as Assertions quando fizermos o deploy do sistema para o usuário final.

Para desabilitar Assertions, o compilador tem uma diretiva de compilação global.

Há duas opções:

$ASSERTIONS ON/OFF (long form)
$C +/- (short form)

Mas isso pode ser definido diretamente na IDE, na sessão de debugger nas opções do projeto, sem haver necessidade de escrever uma linha de código.

Quando as Assertions estão desabilitadas, as verificações não são executadas. Isso libera o sistema de todo overhead das verificações no produto final.

Finalmente, Assertions não substituem Testes de Unidade ou Teste de Integração, sendo apenas mais um tipo de ferramenta para testar o código na fase de desenvolvimento.

Até logo.

Posts Relacionados

  • Memória Segura Utilizando Instâncias de Interfaces

  • Classes Mutáveis vs Objetos Imutáveis

  • Implementando Interfaces Utilizando Diferente Assinaturas de Métodos

  • Usando Paths ao invés de Diretivas de Compilação

  • Trabalhando com Exceções em Requisições HTTP

  • Tipo object Continua Vivo

  • Array de Objetos

  • Variáveis Locais Deveriam ter Nomes Curtos

  • Como Dividir e Organizar o Código em Formulários com Muitos Widgets

  • Pascal Deveria ser Modernizado?