="FONT-SIZE: 10pt; FONT-FAMILY: 'Verdana','sans-serif'"> Neste artigo veremos

·         Como automatizar alguns testes do sistema;

·         Como implementá-los utilizando o DUnit;

·         Como utilizá-los em nosso dia a dia através de exemplos práticos.

Qual a finalidade?

·         Garantir a qualidade de uma aplicação Delphi.

Quais situações utilizam esses recursos?

·         Todo e qualquer sistema pode e deve passar pela fase de testes unitários para garantir sua integridade.

 

Resumo do DevMan

         A qualidade de um software deve ser garantida durante seu ciclo de vida, mesmo em períodos de constantes alterações. Como podemos assegurar que novas implementações não venham quebrar algum código já existente?Aplicando testes unitários. Os testes unitários pode verificar as rotinas de um sistema de forma automática, desde que o sistema ofereça uma arquitetura que permita sua aplicação.

Neste artigo veremos como é essa arquitetura e como criar e utilizar os testes utilizando o framework DUnit, em uma aplicação simples, mas que é bem próxima do dia-a-dia do desenvolvedor Delphi. 

 

Durante o desenvolvimento de um software vários requisitos podem ser alterados exigindo que o sistema também se adéqüe.  O quão difícil, ou fácil, será implementar os ajustes em um sistema já em funcionamento que depende da estrutura/arquitetura utilizada. A utilização de testes automáticos pode funcionar como uma espécie de seguro que pode garantir a estabilidade do seu código durante uma fase de alterações. Tudo isso para evitar a situação do famoso ditado: em time que está ganhando, não se mexe.

Esse artigo trata de como aplicar testes unitários em uma aplicação comum que possua o mínimo de arquitetura.

Pensando em arquitetura

Todo sistema informatizado encapsula uma série de lógicas de programação. Essas lógicas por sua vez podem ser agrupadas, divididas em partes distintas umas das outras. Temos regras para exibição de dados, regras que determinam como esses dados devem ser salvos e por fim, temos a regra do negócio propriamente dita. Sendo assim, podemos dizer que um sistema pode possuir camadas e observando seu conteúdo chegamos à Figura 1.

Figura 1. Camadas de software

 

·         Camada de apresentação: É através dela que os usuários interagem com o sistema. Não importa se é Desktop ou WEB. É responsável em saber como apresentar os dados, como permitir sua entrada e como exibir adequadamente as respostas do sistema. Interage com a camada de serviço;

·         Camada de serviço: Disponibiliza ações que representam as funcionalidades do sistema, como Busca de clientes por Nome ou Impressão do relatório de vendas. Esta por sua vez se comunica com a camada de negócios;

·         Camada de negócios: Aqui é onde suas entidades estão organizadas. Temos classes que representam o seu negócio, como Cliente, Produto, Venda, etc. Todos os dados necessários são obtidos da camada de dados;

·         Camada de dados: Esta camada é responsável por fazer o acesso ao banco de dados, recuperando e atualizando informações. Tudo que diz respeito a banco de dados deve ser centralizado nessa camada.

 

A comunicação necessária entre as camadas ocorre sempre de cima para baixo. Por exemplo, a camada de dados não precisa, e nem é recomendável, saber algo sobre a camada de apresentação. Pensando em um exemplo mais aplicado à realidade, por que que em seu DataModule existiria uma referência ao formulário principal do sistema? Aplicar corretamente essa separação não é um trabalho difícil, visto que mesmo separadas as camadas são ligadas entre si pelos Design Patterns.

 

Nota do Devman

Os padrões de projeto são soluções para problemas recorrentes que surgem no desenvolvimento de sistemas. Foram inicialmente catalogados pela GoF (Gang of Four). Quatro autores, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, que lançaram o livro mais famoso sobre o assunto: Design Patterns: Elements of Reusable Obejct-Oriented Software. ...

Quer ler esse conteúdo completo? Tenha acesso completo