Desenvolvendo testes de dependências (Conferindo pré-requisitos do software)

Todo o software tem dependências, bibliotecas, pacotes, programas ou outras “coisas” da qual a aplicação depende.

Quando o software começa a ser instalado em diversos clientes, queremos que esses pré-requisitos estejam de acordo e precisamos de uma forma automatizada de garantir um mínimo de garantias de funcionamento.

É nesse ponto que entra o conceito de “Testes de dependências”, criamos via software, uma interface que verifica (“checa”) todas as dependências possíveis via software.

Em uma classe criamos um método que lista todas as verificações que serão feitas:

public function listDependency()
{
    $list[] = array('gdInstalled',          'Gd (Image library)');
    $list[] = array('yazInstalled',         'Yaz installed (used by Z3950)');
    $list[] = array('ldapInstalled',        'LDAP installed');
    $list[] = array('filePermission',       'Default file permission');
    $list[] = array('logPermission',        'Log write Permission');
    $list[] = array('linkedFiles',          'Gnuteca files that must be inside miolo/html/');
    $list[] = array('emailConfigured',      'Email is configured and sending');
    $list[] = array('printerSocket',        'Printer using socket system');
    $list[] = array('gCron',                'GCron');
...

Cada sub-array com a função e o nome do teste é montado nesta função, que retorna a listagem completa dos testes a serem efetuados.

O nome do teste é usado no formulário para mostrar os testes de forma mais amigável

Seguindo a ideia criaremos cada uma das funções de verificação,  no caso abaixo a função gdInstaled faz exatamente isso, verifica se a biblioteca de edição/criação de imagens está instalada.

/**
* Verifica se a biblioteca de imagen GD está instalada.
*
* @return <boolean>
*/
public function gdInstalled()
{
    $this->setMessage( GD_VERSION );
 
    return extension_loaded ('gd') && function_exists ('gd_info');
}

A funcionalidade abaixo mostra uma mensagem com a versão do GD (só irá aparecer caso exista um valor na constante) em seguida utilizamos a verificação extension_loaded, passando como parâmetro “GD“, isso retornará que a extensão do PHP está instalada, para termos certeza absoluta, verificamos através da função function_exists se a função “gd_info” existe, essa função é básica da biblioteca, se ela existe e a extensão está carregada a chance muito grande de tudo estar funcionando corretamente.

Podemos notar que essa função (gdInstalled) chama a função setMessage, que nada mais faz do que definir a propriedade message da classe, o corpo do método seria:

public function setMessage($message)
{
    $this->message = $message;
}

Um getMessage() também foi implementado.

Seguindo a linha de raciocínio exemplificamos com mais uma função, neste caso verificaremos se o formato do banco de dados (no caso Postgres), está definida corretamente.

/**
* Verifica se o estilo da data do banco de dados está definido corretamente
*
* @return <boolean>
*/
public function dateStyle()
{
    $bus        = new GBusiness(); //classe genérica de regras de negocio do Gnuteca, permite a execução de SQLs.
    $result     = $bus->executeSelect( "SELECT setting from pg_settings where name = 'DateStyle';"); //executamos o SQL especificado.
    $confirm    = 'ISO, DMY'; //string que verifica o datestyle correto
 
    //caso a string de confirmação aparece no primeiro item do resultado quer dizer que o estilo da data está correto.
    $ok = stripos(  ' ' . $result[0][0] ,$confirm ) > 0 ;
 
    if ( !$ok )
    {
 
        //caso o estilo não está correto informamos o usuário como corrigir
        $this->setMessage( "Execute no banco de dados: ALTER DATABASE :DBNAME SET DateStyle TO 'ISO, DMY';");
    }
 
    return $ok  ; //retornamos o resultado do teste
}

Como pode ser notado pelos comentários, obtemos a classe que permite a execução de SQLS (GBusiness), executamos um select e comparamos o resultado com uma string que temos certeza que está correta.

É importante mostrar uma solução possível caso seja uma resolução simples, como este caso uma simples execução de um select resolve o problema. É interessante notar que o dateStyle do banco não é exportado junto com o dump do postgres, em função disto o teste deve confirmar.

No caso do teste do GD não retornamos uma solução pois a instalação de uma extensão de PHP  pode mudar drasticamente em cada sistema operacional.

No formulário (conforme imagem abaixo), obtemos a listagem de testes e um simples foreach chamando a função especifica resolve o nosso problema.

$dependency = new GDependency();
 
$list = $dependency->listDependency();
 
if ( is_array($list))
{
    foreach ( $list as $line => $info)
    {
        $function = $info[$line][0]; //obtem o nome da função
        $result[] = $dependency->$function();
    }
}

No caso do Gnuteca os testes são executados de forma assincrona via ajax, mas o código acima deve ser o suficiente.
De posse do array de resultado imprimimos-o na tela.

A mágica está no trecho abaixo:

$dependency->$function();

Magicamente o PHP intepreta o nome da variável e executa a função, maravilhas de linguagens de script.

Para o usuário/instalador o resultado abaixo é apresentado:

Resultado da execução de testes de dependências

O que tem acontecido na prática do dia a dia, é que os testes de dependências tem evitado muitas dores que  cabeça que tínhamos em versões anteriores do software, e quando detectamos algum novo teste que merece ser feito (devido a feedbacks dos clientes e avaliações da equipe) acrescentamo-lo a listagem de dependências.

Resumindo: na versão 3.2 (Release Oficial do Gnuteca) temos cerca de 20 testes, já na atual versão de desenvolvimento ( não pronta) já constamos mais de 40 testes, quanto mais testes, mais certezas teremos de que tudo funciona como o esperado e menos problemas os clientes ( e nós ) teremos, por fim resultado diretamente na qualidade da aplicação.

P.S.: Testes de dependências não ter nada a ver com testes unitários, que são basicamente testes que visam evitar erros do programador, devido a mudança de codigo, você faz um refactor no código e o teste unitário “garante” que isso não resultará em impactos negativos no sistema. Trataremos de testes unitários em outro artigo.