Usando o tSQLt para desenvolvimento de data warehouse orientado a testes (TDWD)

Usando o tSQLt para desenvolvimento de data warehouse orientado a testes (TDWD)

Identifying potential objects in test-driven data warehouse development with tSQLt (concept)
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Esta é a segunda parte de um artigo conceitual para profissionais e entusiastas de dados interessados ​​em trabalhar em um
    conceito de desenvolvimento de data warehouse orientado a teste usando tSQLt, uma estrutura de teste de unidade SQL reconhecida pela indústria.

Este artigo leva você para a próxima etapa na prova de conceito de desenvolvimento de data warehouse orientada a teste, adicionando mais
    valor ao esforço que investimos quando a iniciativa foi tomada.

Além disso, os leitores deste artigo experimentarão a tremenda capacidade do tSQLt quando confrontados
    prova de conceito em vez de um cenário tradicional de teste de banco de dados.

Próxima etapa Pré-requisitos

Antes de pularmos para a próxima etapa, é melhor revisar os pré-requisitos para que seguir as etapas à frente se torne mais fácil.

É altamente recomendável percorrer a primeira parte do artigo O conceito de desenvolvimento de data warehouse orientado a teste (TDWD) com o tSQLt para entender completamente os conceitos e
    siga as orientações.

Este artigo pressupõe que os leitores já passaram pelas seguintes etapas:

  1. Conhecimento da prova de conceito, incluindo as estratégias

  2. O escopo do trabalho foi definido e entendido

  3. A estratégia de mapeamento foi selecionada e entendida

  4. Os requisitos de negócios são totalmente compreendidos

  5. O conceito de ambiente Sandbox foi entendido

  6. Banco de dados de amostra SQLDevArticlesV5 ja esta marcado

  7. Armazém de Dados de Amostra SQLArticlesV5DW ja esta marcado

  8. O tSQLt foi instalado nos dois bancos de dados de amostra

  9. O objeto AthorsReport foi escolhido

  10. Os requisitos de negócios são conhecidos e também a razão por trás do trabalho no desenvolvimento de data warehouse orientado a testes
            prova de conceito

  11. O teste tSQLt para verificar o AuthorsReport foi gravado e executado com sucesso

Verificação do sandbox do desenvolvedor

Criamos um ambiente de sandbox quando começamos este trabalho (na primeira parte do artigo) consistindo no
    bancos de dados de amostra mencionados acima com instalação tSQLt nos dois bancos de dados de amostra, seguidos por um teste de unidade SQL para
    verifique se o objeto desejado existe (no armazém de dados).

Vamos executar novamente o primeiro teste de unidade SQL para verificar se o objeto ainda existe executando o script a seguir no armazém de dados SQLArticlesV5DW:

Verifique se a sua saída de teste deve ser a mesma mostrada abaixo:

Verificação do sandbox do desenvolvedor

Em outra nota, alguém poderia pensar que realmente precisamos executar o teste de unidade SQL para ver se o objeto existe ou não
    quando podemos verificá-lo na pasta de banco de dados relacionada no Pesquisador de Objetos como é óbvio na captura de tela acima.

A resposta é muito simples: estamos executando o teste de unidade SQL principalmente para verificar se o objeto existe ou não, mas também para verificar o seguinte:

  1. O tSQLt está instalado e funcionando

  2. Não há outros testes de unidade SQL dos quais não temos conhecimento

  3. O desenvolvimento de data warehouse orientado a teste está em operação

Portanto, a verificação da caixa de areia (ambiente) foi concluída, estamos passando para a próxima etapa, mas você pode adivinhar qual é a
    próximo passo será?

Detalhamento da funcionalidade do objeto AuthorsReport

Se eu disser que o próximo passo é verificar se o objeto está funcionando corretamente ou não, isso faz sentido. Um passado
    O teste de unidade SQL confirma que o objeto AuthorsReport existe, mas isso não é suficiente, pois agora precisamos verificar se o
    O objeto mostra o relatório dos autores ou não e este é o começo da próxima etapa.

No entanto, existem coisas mais importantes antes de verificarmos a funcionalidade do objeto.

Na verdade, é aqui que as coisas ficam um pouco mais complexas e o caminho do desenvolvimento de banco de dados orientado a testes parece
    ser separado do desenvolvimento de data warehouse orientado a teste.

De acordo com o desenvolvimento do banco de dados orientado a teste, precisamos escrever um teste de unidade usando tSQLt para verificar se o objeto
    (AuthorsReport) está funcionando corretamente, mostrando a saída necessária ou não e, no nosso caso, a saída
    é o relatório dos autores.

Escrever esse teste de unidade exige que façamos muitas coisas em segundo plano e é isso que é orientado por testes
    o desenvolvimento do armazém de dados se baseia na perspectiva da prova de conceito.

Se não entendermos essa falha de funcionamento, estamos quase perdidos na prova de conceito.
    focado nesta passagem do artigo, tanto quanto possível.

Em vez de criar um teste de unidade SQL imediatamente, precisamos primeiro pensar em seu protótipo para que ele se torne
    É mais fácil escrever, testar, refatorar e testar novamente conforme o desenvolvimento de banco de dados orientado a teste.

Consulte Fundamentos do desenvolvimento de banco de dados orientado a testes (TDDD) com teste de unidade tSQLt se você não tiver certeza do motivo pelo qual estamos falando.
    escrevendo o teste de unidade SQL antes de adicionar a funcionalidade ao objeto.

Vamos chamar o objeto AuthorsReport como objeto principal e detalhar a funcionalidade do objeto primário (AuthorsReport) em um estilo de engenharia reversa da seguinte maneira:

  1. Estamos focados em um objeto chamado AuthorsReport, que deve mostrar o relatório dos autores

  2. O relatório dos autores não pode ser mostrado se não houver tabela Autor no armazém de dados

  3. A tabela Autor não é útil se não houver dados nela

  4. Os dados não podem ser armazenados na tabela Autor se não puderem ser extraídos da fonte desejada

  5. Os dados não podem ser extraídos da origem se não houver nenhum processo ETL (Extract-Transform-Load) em operação

  6. O processo ETL não pode ser executado se não houver objeto GetAuthorExtract

  7. GetAuthorExtract não pode extrair os dados da fonte se não houver tabela Autor na fonte

  8. A tabela Autor na origem não pode ser usada para extrair os dados se não houver dados nela

Sim, é um colapso giratório, mesmo que eu esteja sentindo os efeitos, mas temos que prosseguir, já que, em última análise, é um
    requisito comercial que precisa ser atendido (como estamos visualizando a pressão sobre a equipe de desenvolvimento enquanto
    trabalhando neste projeto / protótipo).

Detalhamento da funcionalidade do objeto AuthorsReport

Se você entende esse ponto, entende todo o conceito, porque esse é o gatilho em nossa prova de
    conceito e deve ser totalmente compreendido, embora isso seja revisto ainda mais.

Lembre-se de que os objetos podem ser facilmente manipulados pelo tSQLt.

Objeto secundário (GetAuthorsExtract)

Agora, uma coisa é clara: precisamos de pelo menos mais um objeto para continuar nossa prova de conceito, e esse objeto é GetAuthorsExtract.

Também identificamos o objeto secundário e isso significa que nosso conceito de desenvolvimento de data warehouse orientado a teste agora se baseia nos seguintes objetos:

  1. AuthorsReport
  2. GetAuthorsExtract

Objeto terciário (TransformLoadAuthorsExtract)

Estamos falando de uma perspectiva típica de data warehouse, em que ocorrem extrações temporárias e cargas de transformação.
    Como um lembrete, a extração de preparação captura os dados da origem e os coloca em um ambiente de preparação e transforma a carga e processa esses dados para colocá-los em tabelas de BI para geração de relatórios e análises.

Portanto, temos os três objetos a seguir agora:

  1. GetAuthorsExtract (para obter os dados do banco de dados de origem)
  2. TransformLoadAuthorsExtract (para transformar dados do preparo em BI)
  3. AuthorsReport (mostra dados com base na tabela Autor)

Identificando objetos em potencial no desenvolvimento de data warehouse orientado a teste com o tSQLt (conceito)

Instalamos o tSQLt nos bancos de dados de origem e de data warehouse na primeira parte deste artigo, porque o segundo objeto (secundário) será testado por unidade no banco de dados de origem.

Agora temos outro objeto sólido GetAuthorsExtract e mais razões para avançar, mas com cautela.

Três testes de unidade SQL para verificar três objetos

Sabemos que o relatório dos autores pode ser mostrado se os três objetos acima estiverem presentes e funcionando corretamente.

Conforme o desenvolvimento do data warehouse orientado a testes, criaremos testes de unidade SQL com a estrutura de ajuda tSQLt para verificar se eles existem.

Já criamos um desses testes de unidade SQL, portanto, vamos criar o restante dos testes.

Criar classe de teste de unidade SQL para o segundo objeto

Esse teste de unidade SQL será criado no banco de dados de origem (SQLDevArticlesV5) e é por isso que instalamos o tSQLt no
    fonte e data warehouse no início (primeira parte do artigo) da prova de conceito.

Vamos criar uma nova classe de teste AuthorsReportTets no banco de dados de origem:

Criar teste de unidade SQL para o segundo objeto

Crie um teste de unidade com tSQLt no banco de dados de origem SQLDevArticlesV5 para verificar se o objeto
    GetAuthorsExtract existe da seguinte maneira:

Execute testes de unidade SQL para o segundo objeto

Agora, execute todos os testes de unidade SQL no banco de dados de origem emitindo o seguinte comando tSQLt:

A aplicação dos princípios de desenvolvimento de banco de dados orientados a teste e a falha do teste são os esperados:

Teste com falha esperado, pois o objeto não existe

Crie um segundo objeto (GetAuthorsExtract)

Crie o stub de objeto desejado (marcador de posição) no banco de dados de origem SQLDevArticlesV5:

Execute novamente o (s) teste (s) de unidade SQL no banco de dados de origem

Por favor, execute os testes de unidade SQL no banco de dados de origem:

A saída é a seguinte:

Teste de unidade SQL passou

Criar teste de unidade SQL para o terceiro objeto

Temos que escrever outro teste de unidade SQL para o terceiro objeto no banco de dados do armazém de dados desta vez, da seguinte maneira:

Execute testes de unidade SQL para o terceiro objeto

Hora de executar os testes de unidade SQL no banco de dados do Data Warehouse usando o mesmo script:

A saída é a seguinte:

O teste de unidade SQL falhou porque TransformLoadAuthorsExtract não existe

A saída mostra claramente que o segundo objeto precisa ser criado enquanto o primeiro objeto existe no banco de dados
    e os testes unitários dos dois objetos devem passar para que possamos prosseguir.

Crie um terceiro objeto (GetAuthorsExtract)

De acordo com as regras de desenvolvimento de banco de dados orientadas a teste, basta criar o objeto sem sua funcionalidade, da seguinte maneira:

Execute novamente os testes de unidade SQL no data warehouse

Execute novamente os testes de unidade SQL para ver como a saída mudou agora:

Os dois testes de unidade SQL passaram

Os dois testes passaram agora e todos os três objetos existem em nosso ambiente de sandbox.

Parabéns, nossa prova de conceito provou seu valor, mostrando os resultados no início deste enorme
    projeto.

Consulte o artigo Extratos de Data Warehouse de Teste de Unidade SQL com tSQLt, que podem ajudá-lo a prosseguir por conta própria com a prova de conceito, se você
    atenha-se aos conceitos principais deste artigo.

Conclusão

Neste ponto, podemos dizer que os objetos em potencial necessários para atender aos requisitos de negócios (para mostrar aos autores
    ) foram identificados e desenvolvidos com sucesso, com exceção de sua funcionalidade, desde que a unidade SQL
    testes para verificar se eles existem são todos aprovados.

Essa é a beleza do desenvolvimento de banco de dados orientado a testes, pois mantém você focado em mini objetivos primeiro
    compreendendo o total de objetos necessários para atingir o objetivo e incentivando você a escrever testes para verificar
    se eles existirem antes mesmo de você começar a criar esses objetos.

Outra vantagem da abordagem orientada a testes é que você faz apenas o que deveria fazer e trabalha apenas com aqueles
    coisas com as quais você deveria trabalhar, como no nosso caso, todo o projeto gira em torno de apenas três objetos.

Eu sei que ainda é um longo caminho, mas esta é uma sessão de degustação, pois esses tipos de artigos ficam bastante complicados
    à medida que avançamos e quanto mais você avança, mais conhecimentos são necessários, mas até agora fizemos um ótimo
    identificando os objetos e testando a abordagem proposta (desenvolvimento de data warehouse orientado a teste).

Pode ser possível que alguns dos artigos a seguir se refiram à nossa área restrita de desenvolvimento, onde a deixamos e
    podemos começar a incorporar a funcionalidade para observar os benefícios mais práticos do uso do tSQLt com este novo
    metodologia proposta e desafiadora.

Haroon Ashraf
Últimas mensagens de Haroon Ashraf (ver todos)

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Leia Também  Carta aberta ao PASS - Uma dose de SQLEspresso