Como você faz o teste de unidade \ usa métodos TDD para projetos de ETL e relatórios?

Projetos ETL são projetos criados usando uma ferramenta ETL (Extract - Transform - Load), como SSIS, PowerCenter, etc.

Normalmente, eles envolvem a leitura de dados de uma fonte externa, o carregamento em um banco de dados intermediário, a execução de determinadas transformações e o carregamento em um banco de dados final.

Um exemplo simples seria usar o SSIS para ler arquivos do Excel fornecidos por professores usando o SSIS e carregá-los em um banco de dados. Em seguida, escreva procedimentos armazenados ou mais pacotes SSIS para calcular as notas de cada aluno e carregar esses dados em um data mart \ warehouse

Em seguida, você cria procedimentos armazenados no topo do mercado para gerar saída usada pelas ferramentas de relatório (SSRS \ Excel \ etc) para gerar visualizações.

Estou tentando entender como executar o TDD e o teste de unidade adequado nesse cenário. Os testes para ETLs consistem principalmente em garantir que os dados carregados nas tabelas de preparação correspondam ao subconjunto certo dos dados da origem. Portanto, a implementação de um teste leva à implementação de uma mini versão do ETL. A saída dos SPs do relatório depende dos dados nas próprias tabelas, portanto, não é possível ter um conjunto estável de dados de saída sem um pesadelo de manutenção, mesmo se você criar um banco de dados contendo dados de teste limpos

Exemplo:

Sprint 1: A tabela de alunos contém Nome, Idade, Nível

Você cria dados de teste para esta tabela e testes de unidade com base nesse

Sprint 2: um campo de gênero é adicionado à tabela.

Agora, se você atualizar os dados no campo do aluno para preencher o atributo de gênero, os casos de teste serão invalidados desde que os dados foram alterados. E se não, você não poderá criar casos de teste que exijam a coluna de gênero

O que eu fiz no passado é usar o Desenvolvimento Orientado a Testes de Aceitação . O código ETL é frequentemente distribuído por diferentes estágios / idiomas e tecnologias E fortemente acoplado. A maioria dos processos de ETL depende da sequência de transformações no pipeline.

O risco de usar o teste de unidade apenas no ETL é que ele não cobre as integrações. A sequência de transformações é uma parte igual às transformações reais em muitos ETLs. Se eu estiver gastando recursos na criação de um conjunto de testes automatizado, garantiria que também abrangesse o seqüenciamento.

Eu focaria no TDD para cada sequência de transformação exclusiva ou pelo menos incluiria esses testes em um conjunto de testes maior. Se houver muitas combinações, talvez seja necessário escolher quais sequências testar. A idéia é validar o pipeline ETL para o (s) conjunto (s) de dados em que será usado. Além de garantir a cobertura do teste em todo o seu código.

O ETL pode ser feito com TDD e testa de maneira semelhante à maioria dos projetos, ou seja,

escreva um teste que falhe (vermelho) corrija a falha (verde) faça com que o código seja perfurado e sustentável (refatorado)

Portanto, para ETL, pode ser:

• escreva um script para carregar 1 registro
• falha (nenhuma fonte de dados definida)
• definir fonte [verde]
• sem necessidade de refatorar
• escreva um teste para carregar 1 registro com apenas 1 campo preenchido
• falha (nenhum código escrito para esse campo)
• definir detalhes do código para esse campo
• refatorar
• definir testes com falha que procuram atributos com valores válidos [vermelho]
• etc