Existem várias ferramentas de teste diferentes para PL/SQL por aí. Steven Feuerstein escreveu dois deles, utplsql e Quest Code Tester for Oracle (anteriormente QUTE). Eu sou um grande fã do utplsql, mas ele não tem mais uma comunidade de suporte ativa (o que é uma pena). Ele também tende a ser bastante detalhado, especialmente quando se trata de configurar equipamentos de teste. Ele tem o virtual cardeal de ser pacotes PL/SQL puros; o código-fonte é um pouco tortuoso, mas é FOSS.

O QCTO vem com uma GUI, o que significa - como outros produtos da Quest, ou seja, TOAD - é apenas Windows. Ele não automatiza exatamente a geração de dados de teste, mas fornece uma interface para suportá-la. Também como outros produtos da Quest, o QCTO é licenciado, embora haja uma cópia freeware.

Steven (divulgação, ele é um dos meus heróis Oracle) escreveu uma comparação de recursos de todas as ferramentas de teste PL/SQL. Obviamente, QOTC sai no topo, mas acho que a comparação é honesta. Confira.

Aconselhamento sobre dispositivos de teste em utplsql

Gerenciar dados de teste para testes de unidade pode ser uma verdadeira dor de cabeça. Infelizmente, o utplsql não oferece muito para arcar com o fardo. Então

• Sempre testar em relação a valores conhecidos :
  • Evite usar dbms_random;
  • Tente restringir o uso de sequências a colunas cujos valores não importam;
  • As datas também são complicadas. Evite datas codificadas:use variáveis ​​que são preenchidas com sysdate. Aprenda a apreciar add_months() , last_day() , interval , trunc(sysdate, 'MM') , etc.
• Isole os dados de teste de outros usuários. Construa-o do zero. Use valores distintos sempre que possível.
• Crie apenas os dados de teste necessários. O teste volumétrico é uma responsabilidade diferente.
• Ao testar procedimentos que alteram os dados, crie registros específicos para cada teste de unidade.
• Além disso:não confie na saída bem-sucedida de um teste para fornecer a entrada de outro teste.
• Ao testar procedimentos que simplesmente relatam os registros de compartilhamento de dados entre testes de unidade, quando apropriado.
• Compartilhe dados da estrutura (por exemplo, chaves primárias referenciadas) sempre que possível.
• Use campos de texto livre (nomes, descrições, comentários) para identificar qual teste ou testes usam o registro.
• Minimize o trabalho envolvido na criação de novos registros:
  • Atribua apenas os valores necessários ao conjunto de testes e às restrições da tabela;
  • Use os valores padrão o máximo possível;
  • Proceduralize o máximo possível.

Outras coisas a ter em conta:

• configurar um dispositivo de teste pode ser um exercício demorado. Se você tiver muitos dados, considere criar um procedimento para configurar os dados estáticos que podem ser executados uma vez por sessão e incluir apenas dados voláteis no ut_setup em si. Isso é especialmente útil ao testar a funcionalidade somente leitura.
• lembre-se de que criar dados de teste é um exercício de programação por si só e, portanto, propenso a bugs.
• usar todos os recursos do utplsql. utAssert.EqQuery , utAssert.EqQueryValue , utAssert.EqTable , utAssert.EqTabCount e utAssert.Eq_RefC_Query são todos recursos muito úteis quando se trata de inferir os valores de dados voláteis.
• ao diagnosticar uma execução de teste que não foi como esperávamos, pode ser útil ter os dados que foram usados. Portanto, considere ter um ut_teardown vazio procedimento e limpar os dados de teste no início de ut_setup .

Lidando com código legado

Comentar no post de Gary me lembrou de outra coisa que você pode achar útil. Steven F escreveu o ulplsql como uma implementação PL/SQL do JUnit, a vanguarda Java do movimento Test First. No entanto, as técnicas de TDD também podem ser aplicadas a grandes quantidades de código legado (neste contexto, código legado é qualquer conjunto de programas sem nenhum teste de unidade).

A principal coisa a ter em mente é que você não precisa colocar tudo em teste de unidade imediatamente. Comece de forma incremental. Crie testes de unidade para coisas novas, Teste primeiro . Crie testes de unidade para os bits que você vai alterar antes de aplicar a alteração, para que você saiba que eles ainda funcionam depois de fazer a alteração.

Há muito pensamento nesta área, mas (inevitavelmente se vergonhosamente) vem principalmente dos programadores OO. Michael Feathers é o principal. Leia seu artigo Trabalhando de forma eficaz com código legado . Se você achar útil, ele posteriormente escreveu um livro com o mesmo nome.