Por que os desenvolvedores não fazem testes de unidade e integração?

A 27ª Mesa Redonda DFTestes teve como tema “Por que os desenvolvedores não fazem testes de unidade e integração?”. A discussão gerou 8 respostas e 7 pessoas participaram, sendo elas: eu, Janaina Trilles, Sarah Pimentel, Maria Meire, Edwagney Luz, Felipe Silva e Bruno Augusto.

Abaixo segue um resumo da discussão, baseado nas duas perguntas principais da mesa redonda. Quem quiser acessar a discussão na íntegra, pode acessar por meio deste link.

Por que os desenvolvedores não fazem testes de unidade e integração?

A Sarah Pimentel deu a sua resposta baseada na sua experiência, dizendo que:

Alguns casos que vivenciei era mais uma questão de conversar não com os desenvolvedores, mas com os gerentes. Nem sempre é “má vontade” dos desenvolvedores, em alguns casos é falta de tempo mesmo. O gerente não prevê a criação/execução de testes unitários e se o desenvolvedor aumentar a estimativa dele de desenvolvimento para englobar os testes unitários o gerente vai cair em cima e cortar o tempo da estimativa.

A aplicação de testes, de uma forma geral, não só os unitários, mas também os de sistema, está sempre envolta em muitas questões culturais.

O Edwagney fez um comentário bem interessante sobre a questão, colocando que a acomodação é um dos motivos para que os desenvolvedores não realizem testes de unidade e integração.

Esse é um tema bastante interessante e um grande indício de que o ser humano é sim acomodado e gosta de entrar numa zona de conforto e para não sair de lá jogar a culpa no tempo. Explico!

As tecnologias de hoje permitem ganhar muito mais tempo com desenvolvimento do que anos atrás. Quem foi desenvolvedor nas décadas de 80 e 90 sabem do que estou falando. Nessa época não tínhamos ainda o conceito de teste formal de software, como temos hoje e TODA a execução do teste era feito pelos próprios desenvolvedores. Já ouviram falar em “teste de mesa”? Para quem nunca ouviu falar disso, esse é um teste que era feito “à mão” usando papel e caneta onde os desenvolvedores simulavam a entrada de dados nas suas estruturas condicionais e de repetição, e verificavam se essa estrutura iria funcionar da forma como eles imaginavam para o desenvolvimento.
Esse era o teste unitário. Ele era feito por qualquer bom desenvolvedor. Era a forma de garantir que ao menos as principais funcionalidades estavam funcionando de forma isolada.

Esse método também era bastante usado nos testes de integração, onde os próprios desenvolvedores se viam na necessidade de testar seus módulos de forma integrada. O ambiente era direcionado a esse teste. Quem faria isso? Ninguém… Éramos nós mesmos.

Quando começaram a surgir as novas tecnologias, reduzindo o tempo de desenvolvimento e os conceitos de teste, os desenvolvedores entraram em uma tamanha acomodação que hoje nem mesmo os testes básicos eles fazem mais. Como assim? Há não… Vou perder meu tempo testando pra quê, se existe uma equipe só pra fazer isso?

Minha reflexão em relação a tudo isso é, existe culpa dos desenvolvedores por não mais executarem os testes?

Penso que atribuir culpa a alguém ou a alguma área é a forma mais fácil de taparmos o sol com a peneira. Não é assim que funciona. Antes de botar culpa em alguém façamos algumas reflexões:

Qual a política de testes foi adotada pela empresa? Todos na organização conhecem essa política? Todos a conhecem e sabem falar dela para outras pessoas (com propriedade)?

Essa política atribui papéis e responsabilidades bem definidos? A equipe de desenvolvimento sabe exatamente qual teste é executado pela equipe de teste?

O que aconteceu com os desenvolvedores que os fizeram a não executarem mais testes é simples. ACOMODAÇÃO.

De novo, culpa deles, não. Isso é natural do ser humano. Os desenvolvedores se acomodaram, pelo fato de acharem que, se existe uma equipe de teste, eles VÃO executar todos os testes no software. Só que em nenhum momento falaram para eles que não é bem assim. Cada um tem o seu escopo e sua participação no processo, isso É OBRIGAÇÃO DA ORGANIZAÇÃO em comunicar todos e todas as areas na empresa.

Para o Felipe Silva vários fatores contribuem para que o desenvolvedor não realize tais testes:

1. Penso na primeira como sendo a desvalorização de tais testes primeiramente por quem cobra os desenvolvedores (aquele que fica pondo pressão) e consequentemente pelos desenvolvedores (que se mostrarem baixo desempenho – por estarem testado tudo que supostamente deveriam testar – podem acabar perdendo o emprego),
2. O segundo ponto é a cultura de trabalho reativo acomodada na organização, que sem perceber (as vezes por que se negam a aceitar que isso ocorre sempre) preferem fazer duas vezes do que fazer o certo na primeira vez,
3. O terceiro ponto é os desenvolvedores não saberem que o processo de testes é composto por vários testes e que a equipe de teste não faz todos (não ainda), se eles não sabem disso é porque não deram condições para isso.

Em nenhum dos 3 casos eu os culpo (desenvolvedores) por isso, pois acho que a coisa começa em cima e reflete em baixo.

Na minha opinião alguns motivos para que o desenvolvedor não realize testes unitários e de integração são:

• Existe uma rede de proteção chamada equipe de Testes;
• Não tem
  • motivação;
  • conhecimento sobre testes;
  • noção do quanto dos benefícios de ter testes de unidade e integração;
• São uns bundões e/ou imaturos;
• Auto-confiança em excesso, “para que testar fui eu que desenvolvi”;
• Dão manutenção em sistemas legados;

O grande problema é quando dois ou mais motivos juntam, o que é comum.

O que podemos fazer para incentivar/ajudar os desenvolvedores a realizar tais testes?

A Janaina Trilles compartilhou a sua dificuldade, que acredito que também seja a de muitos, mas acredito que o caminho seja tendo persistência mesmo, tentando ir mudar aos poucos.

Eu tenho grande dificuldade de fazer os desenvolvedores ter a cultura dos testes unitários, é sempre um problema na empresa .Não sei como eu posso mudar esse conceito, já falei que fazendo isso dimínui bastante defeitos e gera menos retrabalho.

Segundo o Felipe Silva, podemos ajudar sim, mas é algo que irá dá trabalho e demorará, uma vez que o problema muitas vezes está na cultura da equipe/empresa.

1. Ter no cronograma condições de se fazer estes testes, e fazer sem ser atropelado. Ter essas condições no cronograma não necessariamente significa aumenta o tempo do cronograma, pode-se pensar em N soluções para otimizar o tempo gasto em certas tarefas ou automatizar as que forem possíveis,
2. A organização, precisa ser “testadora”, digo, ser do mesmo time que nós, não somos “aqueles que apontam os defeitos”, somos “um de nós”, somos amigos do sucesso organizacional (pois tais testes ajudam tanto a ter melhor qualidade no produto entregue quanto ajuda reduzir o tempo gasto com testes funcionais), isso aqui não é da noite pro dia, mas tem que ser trabalhado incansavelmente a nível macro (todos envolvidos no projeto).
3. Alguma estratégia de divulgação da cultura de testes, do dia a dia, do que é feito e o que não é feito pelos testadores, seja por treinamento ou por qualquer outra forma que consiga atingir o objetivo de levar os opressores (líderes) e oprimidos (desenvolvedores) ao conhecimento do efeito negativo de se trabalhar reativamente.

Fácil falar e trabalhoso e não tão rápido de se conseguir, pois é humano, é cultural, é organizacional, envolve métricas, envolve dinheiro, envolve o cliente, envolve o emprego de cada um.

Eu penso, que podemos ajudar divulgando conteúdos relacionados ao assunto, dá uma palestra na empresa sobre esses testes, etc.

Se você tiver conhecimento/domínio sobre alguma linguagem de programação, pode conversar com o desenvolvedor para combinar um dia de sentar junto para tentar escrever alguns testes de uma funcionalidade que ele for implementar.

Realmente, introduzir testes unitários e de integração no desenvolvimento é um processo que costuma ser demorado, não é fácil mudar a cultura dos desenvolvedores, principalmente, pelo fato que eles têm que sentir que testes são importantes, pois é algo que terá que ser mantido, caso contrário, iremos ver a teoria das janelas quebradas na prática.

Bem pessoal é isso. Até a próxima! 🙂

Fique por dentro das novidades, assine o feed do QualidadeBR.

Teste Ágil, como implementar?

A segunda Mesa Redonda DFTestes teve 10 participantes: eu, Wagner Duarte Júnior, Felipe Silva, Cibele, Elias Nogueira, Ralph Montelo, Marcelo Andrade, Aderson Bastos (um dos autores do livro Base de Conhecimento em Teste de Software), Robson Agapito e o José Correia.

Como puderam notar, grandes nomes da comunidade brasileira de Teste e Qualidade de Software participaram da Mesa Redonda, e todos com o mesmo objetivo, discutir sobre “Teste Ágil, como implementar?”. 😀

Vamos então para o resumo dessa discussão que teve 17 respostas.

A discussão teve um desafio a mais dessa vez, pois o tema é bem recente, tanto que há apenas um livro focado nele, o Agile Testing da Lisa Crispin e Janet Gregory. E o no Brasil há pouquíssimo material sobre o assunto. Então, acredito que o grande objetivo da discussão foi tentar desmitificar um pouco o que é Teste Ágil e como podemos implementá-lo na nossa empresa, não trazendo fórmulas mágicas ou receitas de bolo (até porque isso não existe em projetos de software), e sim experiências vivenciadas pela comunidade e conhecimentos adquiridos, que possam orientar como dar os primeiros para a agilidade no Teste de Software.

Afinal o que é Teste Ágil?

Como de praxe em uma discussão sobre agilidade, é bom apresentar os princípios ágeis do Manifesto Ágil, que também norteiam o Teste Ágil:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Lembrando que os itens da esquerda são mais valorizados do que os da direita, mas isso não que dizer que os da direita sejam ignorados.

O Wagner apresentou de forma muito clara o que se espera quando dizemos que algo é ágil:

Sou um grande apreciador da qualidade. Por isso, acredito que tenhamos realmente que tornar o nosso trabalho cada vez mais ágil, porém, não podemos nos esquecer da qualidade, que é o forte da nossa área.  Vejo então, que devemos unir com sabedoria, essas duas vertentes. Um processo relativamente simples, que possa ser executado com grande facilidade e agilidade, cobrindo o maior número de riscos, com uma qualidade que seja apreciada e valorizada pelo usuário final. Um processo sem muitas “firulas” e com a qualidade esperada pelo cliente ou ainda, superando as expectativas do mesmo.

Na minha opinião, Teste Ágil é um conjunto de práticas que proporcionam a diminuição do tempo entre o erro e a sua descoberta, baseada no contexto ágil e nos princípios do manifesto ágil.

Para o Elias Nogueira Teste Ágil:

É uma abordagem de teste que está aderente ás práticas de agilidade descritas no manifesto ágil;

É a área de teste sendo mais pró-ativa do que reativa;

É integrar/relacionar os testes as metodologias de desenvolvimento ágil (TDD, XP, FDD, BDD, etc…).

O que muda do Teste Tradicional para o Teste Ágil?

As considerações feitas pelo Elias Nogueira deixaram claro que o Testador passa a ser um profissional muito mais dinâmico:

• Testadores serão mais pró-ativos, tendo participação direta com o cliente;
• Testadores terão um foco mais técnico, pois estarão trabalhando como par de desenvolvedores;
• Testadores precisam saber automatizar, para poder manter o ciclo de entrega dos testes sempre no mesmo tempo/sprint.

Para mim as mudanças são as seguintes:

• Acredito que a principal mudança é em como você exerce o seu papel, as técnicas a serem utilizadas para a criação dos testes e todas as outras teorias provenientes, podem te auxiliar a entender e exercer melhor as suas tarefas de uma forma mais ágil e efetiva;
• O que vejo que muda muito, é que os desenvolvedores também testam, e testam pra valer, tanto que devem haver mais testes de unidade e integração do que testes de sistema e aceitação;
• O Teste de Software se torna mais preventivo, práticas como o TDD e a Programação em Par, contribuem para melhorar a qualidade do software que está sendo desenvolvido, e evitar a inserção de erros;
• O time de teste não precisará focar nos testes que validam se o sistema está sendo de acordo com o cliente solicitou, e não se preocupam em cobrir verificações básicas, como cobertura de desvios;
• A automação é essencial para o Teste Ágil, é o ingrediente que fará o teste ser realmente ágil;
• Os testes manuais existem, mas são mais para os tipos de testes que realmente não tem como automatizar, como por exemplo: usabilidade;
• O time de teste passa a participar de forma mais efetiva e integrada com o time de desenvolvimento, não espaço para rivalidade, pois ambos trabalham focando o mesmo objetivo, entregar um produto com qualidade;
• Os testes tornam-se rotina, não é mais uma tarefa feita só no final do desenvolvimento do software.

Como podemos implementar o Teste Ágil no nosso dia-a-dia?

O Aderson Bastos vez uma interessante consideração sobre Teste Ágil em metodologias não ágeis:

É possível testar de forma ágil com qualquer tipo de metodologia de desenvolvimento, obviamente algumas metodologias privilegiam este tipo de abordagem. RUP, XP, Scrum, FDD, etc, são ótimas referências para elaborarmos uma boa metodologia, mas nenhuma delas garantirá agilidade. Não somos ágeis porque utilizamos Scrum e/ou XP, por exemplo, – lembrem-se do manifesto ágil: “indivíduos e interações mais que processos e ferramentas”!!! – somos ágeis porque pensamos e agimos assim; porque quando somos eficazes no uso de todo o conhecimento (técnicas, boas práticas…) que temos.

A Cibele listou importantes fatores que nos ajudam a saber se a implementação de uma metodologia ágil será uma boa ou não:

Onde será aplicada;

Tipo da empresa;

Maturidade de processos e dos profissionais;

Cliente;

Time;

Tipo de sistema a ser desenvolvido e várias outras coisas.

E a Cibele ainda fez importantes considerações, sobre a implementação de metodologias ágeis e Teste Ágil, com base em experiências vivenciadas:

Não basta só implantar o processo ágil, é preciso checar se há ambiente propício para isso. E mais importante, começar devagar, pegar um projeto pequeno como piloto e ter pessoas na equipe que conheçam o processo muito bem. Fica mais fácil de analisar a evolução e corrigir erros.

Não há uma receita de bolo a seguir. É preciso conhecer o processo ágil muito bem, assim como a cultura da empresa e a maturidade dos seus colaboradores e em cima disso, montar uma estratégia de implantação do processo ágil. Pelo que presenciei nesta empresa, o teste ágil está dentro do processo ágil. Mas é possível adotar práticas ágeis em testes em qualquer tipo de processo ou metodologia.

O Elias Nogueira fez as seguintes sugestões para a implementação do Teste Ágil:

• Trazendo o cliente para perto e fazendo com que ele entenda as atividades de teste e que ele entenda que ele mesmo é o principal fator de sucesso;
• Alterar nossa Cultura Organizacional (todos devem ser ágeis, da tia do café ao presidente da empresa);
• Manter a equipe atualiza e ter feedbacks constantes para todos os stakeholders;
• Estudar e implantar mais testes caixa-branca junto aos desenvolvedores;
• Prover formas automatizadas para a execução de testes em todos os níveis.

O Robson Agapito relatou como ele está começando a implantar Teste Ágil:

O primeiro passo que estamos trabalhando é treinar a equipe de desenvolvimento para estar aptos a realizar testes unitários, após isso implantado e assimilado por toda a equipe creio que será mais fácil de mudar a metodologia para alguns projetos.

Para o José Correia:

O ideal é convencer sua organização a fazer um piloto e a partir dessa experiência ir aperfeiçoando. A primeira vez não vai ser incrível. Não existem metodologias mágicas, é necessário aprender com erros e acertos, acreditar, medir, ajustar e comprovar progressivamente os ganhos.

Na minha opinião, precisamos implementá-lo de uma forma incremental, e de preferência iniciando com os testes no desenvolvimento do software:

• Antes de tudo, é preciso estudar e entender o motivo pelo qual o Teste Ágil existe;
• Implantar de forma gradativa;
• Antes de criar um teste, pensar se ele pode ser automatizado, e se vale a pena automatizá-lo;
• Lembre-se que o Teste Ágil, causa uma inversão na pirâmide dos testes, ou seja, ao invés de temos muitos testes de sistema e aceitação, teremos mais testes de unidade e integração. Então, e a responsabilidade da criação de tais testes é em primária instância do desenvolvedor;
• Atue perto do cliente, afinal você deverá ter pleno conhecimento sobre o que ele está esperando do sistema;
• Querer criar testes de unidade e integração para sistemas legados, é quase impraticável, porém para as novas funcionalidades e manutenções, por que não criar?

Quais são as maiores dificuldades para implementar-lo?

Segundo o José Correia o mercado ainda tem resistência em experimentar as metodologias ágeis:

Nos projetos  que acompanho, o uso de práticas ágeis é elegível apenas quando o número de horas totais do projeto é inferior a 1000 horas. Alguns clientes são mais conservadores e estabelecem um teto de 640 à 800 horas. Projetos acima são tocados dentro das práticas do RUP, modelos CMMI/MPS.br e os testes complementados com base no Syllabus/ISTQB, CBOK/QAI, normas ISO e IEEE.

Algumas empresas que antigamente diziam usar “metodologia própria” para disfarçar a falta de um forma de trabalho estruturada, agora passaram a dizer que são “Ágeis” o que é péssimo para as empresas que realmente utilizam as práticas e fazem um trabalho sério. Ou seja, muitas empresas de grande porte, como diversos Bancos têm grandes restrições por experiências ruins com alguns desses fornecedores.

Para o Elias Nogueira podemos enfrentar as seguintes dificuldades:

• Cultura organizacional resistente;
• Equipe não multidisciplinar;
• Cliente não é ou não gosta de ser ágil;
• Conhecer agilidade e os conceitos no Manifesto Ágil;
• Participar reativamente como área de teste (esperar todos os documentos na mão).

Eu vejo que as maiores dificuldades, tem relação as pessoas, até porque Teste Ágil antes de tudo, é uma questão de atitude:

• É uma mudança de cultura, então costuma haver uma grande resistência;
• O time de teste é forçado cada vez mais a está pesquisando sobre novas ferramentas e saber programar, pois como disse antes, a automação é essencial;
• A mudança também afeta o cliente, ele também deverá ser tornar mais participativo e comprometido com o sucesso do sistema, e passar para o time de desenvolvimento as suas reais necessidades e opiniões do sistema.

Quais as vantagens de sua implementação?

Podemos obter diversas melhorias com a implementação do Teste Ágil, não apenas no processo, mas como também na motivação das pessoas:

• O número de bugs a ser encontrados pelo time de teste tende a ser bem menor, principalmente devido ao fato do grande foco na prevenção dos mesmos;
• O desenvolvimento do software torna-se sustentável, se for necessário fazer alguma mudança, os desenvolvedores não terão receio, pois poderão executar uma bateria de testes unitários para verificar se a mudança não quebrou nada;
• As entregas passam a ser mais rápidas;
• A participação do cliente de forma mais efetiva, faz com que o software tenha aquilo que realmente o cliente deseja;
• A automação torna a execução do testes mais rápida, ou seja, passar a ser mais econômica;
• O retrabalho e manutenção será muito menor, fazendo com o que o custo e o tempo para o desenvolvimento seja menor.

O Elias Nogueira levantou as seguintes vantagens:

• Maior velocidade na execução do projeto
• Maior rapidez no conhecimento do projeto
• Entregas mais focadas na necessidade do cliente
• Cliente se sentirá feliz e realizado em ver como estão as atividades e saber realmente o que será entregue
• Maior disseminação de conhecimento técnico e de negócio para a equipe

Durante a Mesa Redonda surgiu uma boa discussão, iniciada após o Ralph Montelo compartilhar as seguintes opiniões:

Sinceramente? “Teste Ágil” são duas palavras que (infelizmente!) não combinam. Mesma coisa que dizer “Inteligência Militar”. (!)

Métodos ágeis são ótimos quando o assunto é economia e agilidade na entrega. Quanto à qualidade, prefiro não comentar. Não consigo confiar 100% em uma metodologia que preza a “não-documentação”, pois continuo seguindo minha carreira utilizando a Regra 10 de Myers à risca. E não me arrependi em momento algum.

Em resposta o Wagner disse:

Vejo que o tempo tem se tornado cada vez mais curto, por isso põem-se interessante a idéia de agilidade com qualidade. Pois a partir do momento em que o foco se torna apenas a “agilidade”, não estamos mais falando de “Teste e Qualidade de Software”.

Temos que realmente unir o “útil (qualidade) ao necessário (agilidade)”.

E o Marcelo Andrade lembrou que ser ágil é buscar fazer direito na primeira vez e produzir documentação efetiva e útil:

Ágil combina menos com “pressa” e mais para fazer direito. (Da fábula da
lebre e a tartaruga, sem dúvida, o animal que melhor representa técnicas ágeis
é… a tartaruga). Se alguém acha que desenvolver de forma ágil é fazer com
pressa, com certeza não está fazendo ágil da forma correta.

É falso dizer que métodos ágeis prezam a “não-documentação”. O mito da
documentação é algo que incrivelmente as pessoas não entendem no manifesto
ágil. Ao contrário, se preza muito toda a documentação que seja efetiva e útil.
A propósito, artefatos de testes estão entre os melhores tipos de documentação
que existem. Sugiro a leitura deste artigo:

http://www.infoq.com/br/news/2009/08/agile-documentation

Pra fechar o resumo com chave de ouro, nada melhor, do que apresentar as 7 práticas para tornar o Teste de Software ágil, que nada mais são do que soluções de um profissional que buscou a melhoria contínua e agilidade, não porque está na moda, e sim porque tornaria o seu trabalho mais efetivo, todos os créditos ao Felipe Silva, que compartilhou as seguintes práticas:

1. Planejar uma sequência de testes a serem executados de forma que em um único fluxo se consiga validar o máximo de cenários possíveis, chamamos isto de “Overlap”, pois unimos o que seria mais de um Test Case em apenas um Test Case contendo os steps de todos;
2. Automatizar ou simplificar rotinas, por exemplo criando não apenas scripts para testes, mas também scripts, macros e programas que façam coisas que você faria manualmente;
3. Ter Casos de Testes claros e diretos, se sua equipe de testes não é formada por “um monte de mães” (como na discussão passada) pode-se pensar em escrever Casos de Testes que vão direto ao ponto, o step de validação e nada mais,;
4. Gerenciar manobras de riscos, para caso o test A pare, então o B já esteja na lista para ser executado, assim não tendo impacto no prazo do delivery e enquanto estiver testando B já estar providenciando a solução para que o A volte a ser testado;
5. Trabalhar em equipe e tirar uns 20 a 30 minutos para discutir um requisito entre os envolvidos do testes economiza horas de pessoas que tem medo ou vergonha de se expor dizendo que não entenderam ou não sabem e assim sendo sem perceber atrasam a entrega e correm o risco de não fazer um teste com qualidade;
6. Suporte do cliente é fundamental, na nossa equipe hoje temos uma pessoa alocada no cliente que faz o papel de gerente de testes e revisor de requisitos ao mesmo tempo, esta pessoa é a ponte inicial para todas as dúvidas e quase sempre tem todas as respostas que teriam que sair direto do cliente, é um profissional de testes (modelo indiano de gerencia);
7. Tornar os profissionais especialistas em partes do projeto, de modo que todo mundo saiba um pouco do projeto como um todo e você sempre terá 1 especialista em qualquer assunto do projeto, tendo assim na soma dos profissionais uma equipe especialista, as vezes sabendo mais que o próprio cliente do assunto, entendimento rápido do negócio gera processos ágeis para o teste, seja na criação ou na execução dos testes.

Se interessou pelo assunto, então confira a discussão na íntegra, acessando o DFTestes. E se quiser participar das próximas Mesas Redondas, é só fazer a sua inscrição no grupo.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Teste unitário com o SQL Developer

Acaba de ser lançada a versão 2.1 do Oracle SQL Developer. Para quem não conhece, o SQL Developer é uma IDE de banco de dados, focado em Oracle, disponível para Windows, Linux e MAC OSX. Mas também é possível conectar em outros bancos de dados, como por exemplo, MySQL. Por ela você pode gerenciar os objetos do banco de dados, rodar comandos e scripts SQL e editar e debugar comandos PL/SQL.

Na versão 2.1 há uma funcionalidade nova muito interessante: testes unitários.

Com ela é possível:

• Criar e atualizar testes;
• Adicionar suítes de teste;
• Gerar relatórios de teste (ex. cobertura do código);
• Gerenciar lookups;
• Gerenciar a preparação e limpeza do ambiente.

A funcionalidade de testes unitários prover um framework para teste de objetos PL/SQL, como por exemplo, funções e procedures, e ainda é possível monitorar os resultados.

O fluxo de criação dos testes é formado por informar os dados do que será testado e qual o resultado esperado, ou seja, muito parecido com o fluxo de qualquer criação de teste.

Interface da funcionalidade de teste unitário

Eu ainda não brinquei com esta nova funcionalidade, mas assim que puder informo vocês. Por enquanto, para quem se interessou e deseja saber mais, recomendo baixar o Oracle SQL Developer (é claro) e dá uma olhada neste tutorial (em inglês), explicando como realizar um teste unitário utilizando o Oracle SQL Developer. Segue os links:

Download do Oracle SQL Developer

Tutorial – Performing a Unit Test of Your PL/SQL in Oracle SQL Developer 2.1 (em inglês)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

What is SQL Developer? – Oracle

Oracle SQL Developer 2.1: New Feature List – Oracle

Imagem

Performing a Unit Test of Your PL/SQL in Oracle SQL Developer 2.1 – Oracle