Portus -> LogOne: Dados em grande volume para testes

Durante as duas semanas passadas trabalhamos com a montagem de uma base de dados para teste com volume suficiente para criar indicadores de performance da operação portuária. Atualmente estamos desenvolvendo os módulos 9 e 10 do LogOne, que se referem ao planejamento e avaliação de performance da operação, ou seja: monta-se o planejamento anual da operação e compara-se posteriormente o que foi planejado com o que foi realizado.
O primeiro desafio desses módulos foi a criação de um modelo de domínio que comportasse tanto os indicadores 'padrões' (horas trabalhadas, disponibilidade de equipamentos, etc.) quando indicadores específicos do ambiente de cada porto (consumo de água, custo da operação,...) e a criação de indicadores 'derivados', baseados em fórmulas criadas livremente pelos usuários. O segundo desafio foi a criação de uma base de dados de teste onde pudéssemos testar essa visão de planejado X realizado.
A questão da modelagem foi resolvida como deve ser, com bastante reflexão e discussões. Na questão dos dados de teste o buraco foi mais embaixo...

Dados em grande volume para testes

O fato é que existe uma diferença considerável entre dar carga de um volume pequeno de dados para suportar testes manuais ou exploratórios (ou unitários automatizados) e dar carga em um volume grande de dados com o objetivo de extrair dados consolidados que reflitam realmente a operação do sistema.
É fantasia pensar que é possível criar tais tipos de dados na mão em arquivos .xml ou scripts de banco e carregar o banco diretamente.
A complexidade do modelo de domínio é tal que ao tentarmos fazer isso incorremos em dispêndio excessivo de tempo resolvendo conflitos de integridade e corremos o risco de simplificar os dados, tirando a veracidade da base e desqualificando os testes.
A solução que encontramos no nosso caso foi simular a entrada de dados no sistema usando os testes automatizados. Criamos então um conjunto de planilhas que reproduziam os dados do ponto de vista do usuário, ou seja: elas contém os dados muito parecidos com os que o usuário digitará nos formulários do sistema em uma operação normal... e o mecanismo de testes funcionais (baseado no JUnit+Selenium) preenche as telas a partir do conteúdo dessas planilhas.

Exemplo de planilha de testes

No final das contas esse mecanismo funcionou tão bem que estamos considerando migrar todos os dados de testes para planilhas.
Ideia semelhante já é, até um certo grau, defendida por partidários das tabelas de decisão e existem implementações tais como o Fitnesse, por exemplo. O que não me agrada no Fitnesse (e outros mecanismos semelhantes) é o caráter rígido do uso de tabelas. No nosso caso por exemplo o teste da verificação do processamento ficou no código Java/JUnit, ao invés de estar na própria planilha. Até penso que em alguns casos pode ser prático colocar a verificação na planilha, mas em casos mais complexos certamente o código Java dá mais flexibilidade.