Algumas instalações do PostgreSQL, devidamente instaladas e inteiramente funcionais, podem "falhar" em alguns testes de regressão por causa de algumas particularidades específicas da plataforma, como a representação diferente do ponto flutuante ou do suporte à zona horária. Atualmente a avaliação dos testes é feita simplesmente usando o programa diff, para comparar os resultados obtidos pelos testes com os resultados produzidos no sistema de referência e, portanto, os testes são sensíveis a pequenas diferenças entre sistemas. Quando for relatado que o teste "falhou", sempre deve ser examinada a diferença entre o resultado esperado e o resultado obtido; pode-se descobrir que as diferenças não são significativas. Ainda assim, são feitos esforços para manter os arquivos de referência idênticos entre todas as plataformas suportadas, portanto deve-se esperar que todos os testes seajm bem-sucedidos.
As saídas produzidas pelos testes de regressão ficam nos arquivos do diretório src/test/regress/results. Os scripts dos testes utilizam o programa diff para comparar cada arquivo de saída produzido com a saída de referência armazenada no diretório src/test/regress/expected. Todas as diferenças são salvas em src/test/regress/regression.diffs para poderem ser inspecionadas (ou pode ser executado o programa diff diretamente, se for preferido).
Alguns testes de regressão envolvem, intencionalmente, valores de entrada inválidos. As mensagens de erro podem ser originadas pelo código do PostgreSQL, ou pelas rotinas do sistema da plataforma hospedeira. No último caso, as mensagens podem variar entre plataformas, mas devem conter informações semelhantes. Estas diferenças nas mensagens resultam em testes de regressão que "falham", mas que podem ser validados por inspeção.
Se os testes forem executados em um servidor já instalado, que foi inicializado com uma ordem de classificação das cadeias de caracteres (LC_COLLATE) em uma localização diferente de C, então podem haver diferenças por causa da ordem de classificação e falhas de continuação. O conjunto de testes de regressão é configurado para tratar este problema mediante arquivos de resultado alternativos, que juntos podem tratar um grande número de localizações. Por exemplo, para o teste char o arquivo esperado char.out trata as localizações C e POSIX, e o arquivo char_1.out trata várias outras localizações. O condutor do teste de regressão pega, automaticamente, o melhor arquivo para fazer a comparação quando verifica se foi bem-sucedido, e para computar as diferenças da falha (Isto significa que os testes de regressão não conseguem detectar se os resultados são apropriados para a localização configurada. Os testes simplesmente pegam o arquivo de resultado que melhor se adequar).
Se por alguma razão os arquivos esperados existentes não incluírem alguma localização, é possível adicionar um novo arquivo. O esquema de nomes é nomedoteste_dígito.out. O dígito utilizado não tem importância. Lembre-se que o condutor do teste de regressão considera todos os arquivos deste tipo como sendo resultados de teste igualmente válidos. Se os resultados do teste forem específicos para alguma plataforma, em vez dessa abordagem deve ser utilizada a técnica descrita na Seção 26.3 .
Umas poucas consultas do teste horology [1] falham se forem executadas no dia de início ou de fim do horário de verão, ou no dia seguinte aos mesmos. Estas consultas esperam que os intervalos entre a meia-noite do dia anterior, a meia noite do dia, e a meia-noite do dia seguinte, sejam de exatamente vinte e quatro horas — o que não acontece se o início ou o fim do horário de verão ocorrer neste intervalo.
Nota: Uma vez que são utilizadas as regras de horário de verão (daylight-saving time) dos EUA, este problema sempre ocorre no primeiro domingo de abril, no último domingo de outubro, e nas segundas-feiras seguintes, não importando quando o horário de verão começa ou termina onde se vive. Deve ser observado, também, que este problema aparece ou desaparece à meia-noite do Horário do Pacífico (UTC-7 ou UTC-8), e não à meia-noite do horário local. Portanto, a falha pode ocorrer no sábado ou durar até terça-feira dependendo de onde se vive.
A maior parte dos resultados de data e hora são dependentes da zona horária do ambiente. Os arquivos de referência são gerados para a zona horária PST8PDT (Berkeley, Califórnia), havendo falhas aparentes se os testes não forem executados com esta definição de zona horária. O condutor do teste de regressão define a variável de ambiente PGTZ como PST8PDT, o que normalmente garante resultados apropriados. Entretanto, o sistema operacional deve prover suporte a zona horária PST8PDT, ou os testes dependentes da zona horária falham. Para verificar se a máquina possui este suporte, digite:
env TZ=PST8PDT date
# Resultado no Fedora Core 3 (N. do T.)
# (GMT-8) - (GMT-3) = -5 horas
Sáb Fev 26 03:23:45 PST 2005
$ date
Sáb Fev 26 08:23:45 BRT 2005
O comando acima deve retornar a hora corrente do sistema na zona horária PST8PDT. Se a zona horária PST8PDT não estiver disponível, então o sistema pode retornar a hora em UTC. Se a zona horária PST8PDT não estiver presente, podem ser definidas as regras de zona horária explicitamente:
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
Parece haver alguns sistemas que não aceitam a sintaxe recomendada para a definição explícita das regras de zona horária local; pode ser necessário utilizar uma definição diferente de PGTZ nestas máquinas.
Alguns sistemas que utilizam bibliotecas antigas de zona horária falham ao aplicar as correções do horário de verão em datas anteriores a 1970, fazendo com que as horas PDT anteriores 1970 sejam mostradas em PST. Este problema ocasiona diferenças localizadas nos resultados do teste.
Alguns testes incluem cálculos com números de ponto flutuante de 64 bits (double precision) a partir de colunas das tabelas. Foram observadas diferenças nos resultados quando estão envolvidas funções matemáticas aplicadas a colunas do tipo double precision. Os testes float8 e geometry são particularmente propensos a apresentar pequenas diferenças entre plataformas, ou devido a opções diferentes de otimização do compilador. São necessárias comparações utilizando o olho humano para determinar se estas diferenças, que geralmente estão dez casas à direita do ponto decimal, são significativas.
Alguns sistemas mostram menos zero como -0, enquanto outros mostram simplesmente 0.
Alguns sistemas sinalizam erros das funções pow() e exp() de forma diferente da esperada pelo código corrente do PostgreSQL.
Podem ser encontradas diferenças onde as mesmas linhas são mostradas em uma ordem diferente da que aparece no arquivo de comparação. Na maior parte das vezes isto não é, a rigor, um erro. Os scripts de teste de regressão, em sua maioria, não são tão refinados a ponto de utilizar a cláusula ORDER BY em todos os comandos SELECT e, portanto, a ordem das linhas do resultado não é bem definida, de acordo com o texto de especificação do padrão SQL. Na prática, uma vez que se está examinando as mesmas consultas sendo executadas nos mesmos dados pelo mesmo programa, geralmente são obtidos resultados na mesma ordem em todas as plataformas e, por isso, a ausência do ORDER BY não se torna um problema. Entretanto, algumas consultas apresentam diferenças na ordem das linhas entre plataformas (Diferenças na ordem das linhas também podem ser ocasionadas pela definição de uma localização diferente de C).
Portanto, se houver diferença na ordem das linhas isto não é algo com que devamos nos preocupar, a menos que a consulta possua uma cláusula ORDER BY que esteja sendo violada. Mas, por favor, informe de qualquer forma para que possamos adicionar a cláusula ORDER BY a esta consulta em particular e, com isso, eliminar a falsa "falha" nas próximas versões.
Deve-se estar querendo saber porque não se ordena explicitamente todas as consultas dos testes de regressão imediatamente, para acabar com este problema de uma vez e para sempre. A razão é que isto torna os testes de regressão menos úteis, e não mais úteis, porque vão tender a utilizar tipos de plano de consulta que produzem resultados ordenados, prejudicando os planos que não o fazem.
Existe pelo menos um caso no script de teste random que tem por finalidade produzir resultados randômicos. Isto faz com que random falhe no teste de regressão de vez em quando (talvez uma a cada cinco ou dez tentativas). Ao ser digitado
diff results/random.out expected/random.out
deve ser mostrada uma ou poucas linhas diferentes. Não há necessidade de se preocupar, a menos que o teste random sempre falhe em tentativas sucessivas (Por outro lado, se o teste random nunca informar falha, mesmo após muitas execuções dos testes de regressão, então provavelmente você deve se preocupar).
| [1] |
horology — A ciência da medição do tempo, ou os princípios e a arte da construção de instrumentos para medir e indicar porções do tempo, como relógios, cronômetros, etc. Webster's Revised Unabridged Dictionary (1913) (N. do T.) |
| Anterior | Principal | Próxima |
| Testes de regressão | Acima | Arquivos de comparação específicos de plataformas |