Dicas para os dados de teste de aplicativos legacy intensivo

Question

Eu estou trabalhando em um aplicativo muito grande legado, uso intensivo de dados. Tanto a base de código e banco de dados são enormes em escala. Uma grande parte da lógica de negócios está espalhada por todos os níveis, incluindo em procedimentos armazenados.

Alguém tem alguma sugestão sobre como começar a aplicar testes "Unit" (tecnicamente testes de integração, porque eles precisam de teste em níveis para um único aspecto de quase qualquer determinado processo) para a aplicação de forma eficiente? A arquitetura atual não é fácil suportar qualquer tipo de injeção ou de zombaria. Novo código está sendo escrito para facilitar os testes, mas que sobre o código legado? Devido à forte dependência dos próprios dados e lógica de negócios no banco de dados, eu estou usando atualmente em linha sql para encontrar dados para usar para testes, mas estes são demorados. vista a criação e / ou procedimentos armazenados não será suficiente.

Que abordagens você tomou (se aplicável)? O que funcionou? O que não e por que? Todas as sugestões serão apreciadas. Obrigado.

Answer 1

Obter uma cópia de trabalhar efetivamente com Legacy Code por Michael Feathers. Ele é cheio de conselhos úteis para trabalhar com grandes bases de código, não testados.

Outro bom livro é objeto Padrões de reengenharia Oriented . A maior parte do livro não é específico para software orientado a objetos. O texto completo está disponível para download gratuito em formato PDF.

De minha própria experiência: tente ...

• automatizar a criação e implementação
• Obter o esquema de banco de dados no controle de versão, se ele ainda não é. Normalmente, os bancos de dados incluem dados de referência que as necessidades de código transacionais de existir antes que ele possa trabalhar. Obter este controle de versão sob também. Ferramentas como dbdeploy pode ajudá-lo a reconstruir facilmente um esquema de referência e dados a partir de uma seqüência de deltas.
• Instale uma versão do banco de dados (e quaisquer outros serviços de infra-estrutura) para o seu desenvolvimento estação de trabalho. Isso permitirá que você trabalhar no banco de dados sem continuamente ter que passar por DBAs. É também mais rápido do que usar um esquema em um servidor compartilhado em um centro de dados remoto. Todos os principais servidores de banco de dados comerciais têm versões gratuitas (como a cerveja) de desenvolvimento que trabalham no Windows (se você está preso na situação nada invejável de desenvolvimento em Windows e implantando no Unix).
• Antes de começar a trabalhar em uma área do código, testes end-to-end de gravação que aproximadamente cobrem o comportamento da área que você está trabalhando. Um teste end-to-end deve exercer o sistema de fora -, controlando sua interface de usuário ou interagindo através de serviços de rede - assim você não vai precisar alterar o código para colocá-lo no lugar. Ele vai atuar como um (imperfeita) de testes de regressão e dar-lhe mais confiança para refatorar os internos do sistema para uma estrutura que é mais fácil de teste de unidade.
• Se há planos de teste manuais, lê-los e ver o que pode ser automatizado. A maioria dos planos de testes manuais são quase totalmente roteirizada e por isso são de baixo pendurado frutas para automação
• Uma vez que você tem a cobertura testes end-to-end, refatorar o código em unidades mais baixo acoplamento como você modificar e / ou estendê-lo. Cercar essas unidades com testes de unidade.

coisas para evitar:

• Copiar dados do banco de dados de produção para o ambiente que você usa para testes automatizados. Isso fará com que seus testes imprevisível. Claro, executar o sistema com uma cópia dos dados de produção, mas o uso que para o teste exploratório, não testes de regressão.
• operações de rolamento de volta no final dos testes para testes do isolado a partir de uma outra. Isso não vai testar o comportamento que só acontece quando as transações são confirmadas, e vai jogar fora de dados que é valioso para o diagnóstico de falhas nos testes. Em vez disso, os testes devem garantir o banco de dados está em um estado inicial conhecido quando eles começam.
• criação de uma "pequenas" conjunto de dados para testes para executar contra. Isso faz com testes difíceis de entender porque eles não podem ser lidos como uma única unidade. As "pequenas" conjunto de dados em breve cresce muito grande como você adicionar testes para diferentes cenários. Em vez disso, os testes podem inserir os dados na base de dados para configurar o teste-fixação.

Answer 2

“Application Testing Legado Modernização”, destaques:

1. visão geral de alto nível de como os testes são criados em AscentialTest

2. maneiras de converter os objetos legados para a nova plataforma Componentes de definição de objeto

3. Como garantir que a versão modernizada da aplicação produz os mesmos resultados

Para obter mais detalhes sobre o uso do aplicativo de legado testar, fazer check aqui:

http: //-gerenciamento de aplicativos .cioreview.com / whitepaper / testando-legacy-application-modernização-wid-529.html