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

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

O melhor da semana 20/09 a 26/09

Pessoal,

Segue abaixo, os links para o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

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

6º Encontro do Guru-SP – Eu fui!

Em pleno sabadão, num dia lindo acordo antes das 07:00, e não é para ir para a praia ou coisa do tipo, e sim para ir ao 6º Encontro do Guru-SP. 😀

Mas que “diacho” de encontro é esse Fabrício? Você foi consultar um guru espiritual?

Guru Ram Das, o 4º Guru da religião Sikh

Não, não (rsrs). O Guru-SP é esse daqui:

GURU SP

Hmmm… agora entendi. Mas o que você foi fazer num encontro de usuários de Ruby? Você programa em Ruby?

Não (mas depois de hoje fiquei com mais vontade ainda de aprender).

Um dos motivos para ter ido ao encontro foi o tema “Testes Automatizados” dele. Não tem jeito, colocar a palavra “teste” no tema de um evento, é mais efetivo do que falar que vai ter coffee break, para me fazer participar.

rsrs… que atitude nerd, perder um dia lindo desse, para ir num evento só por causa que vai falar sobre testes.

Que isso, olha o preconceito. Não é todo dia que você tem a oportunidade de participar de um evento sobre testes, onde que ia falar não atua na área de Teste de Software ou QA, e sim o pessoal do “lado negro da força” (“brincadeira minha, não é falando mal!”).

Interessante mesmo! Quem organizou o evento?

O 6º Encontro do Guro-SP foi organizado pelo Rafael Rosa, com o apoio da GoNow (local do encontro), Voice Technology (empresa na qual trabalho), O’Reilly e Ruby Inside Brasil, além é claro do Grupo de Usuário Ruby de SP.

E como foi o formato do encontro?

Foi no formato de mesa redonda (muito bom!), o pessoal da mesa ia falando sobre vários temas, que foram votados antes pelo pessoal que participou do encontro. Os debatedores foram:

  • Anderson Leite
  • Cássio Marques
  • Diego Carrion (não pode comparecer)
  • Fabio Kung (não pode comparecer)
  • Jorge Diz (o Jorge será o palestrante do 6º Encontro Mensal da ALATS-SP, a ser realizado nessa quarta-feira)
  • Ricardo Yasuda
  • Thiago Scalone

E o encontro foi dividido em duas partes, a primeira estimado das 10:00 ao 12:00 e a segunda das 12:30 às 15:00.

Da hora, a primeira parte como foi?

Ela começou com quase uma hora de atraso, com o Rafael Rosa falando sobre o encontro e como seria feito esse. Logo após, o pessoal já começou a “descer a lenha” falando sobre “Por que testar”, e pude perceber que a galera é bem comprometida como a realização dos testes, eles levam a sério mesmo e entendem as razões de porque testar.

Os debatedores também contaram experiências que tiveram fazendo BDD com o Cucumber e realizando testes de interface com o Selenium, por exemplo. Esse foi um ponto muito positivo do evento, ficou claro que os debatedores fazem o que eles falam, e puderam compartilhar experiências bem interessantes com o público. E a interação do público foi muito boa também, várias pessoas contaram os cenários que vivem, e também algumas dificuldades que tem em realizar os testes:

  • Tempo: projetos com prazos para ontem. Na minha opinião, realizar testes, principalmente na fase de desenvolvimento é uma prática que gera efeitos não tão bons a curto prazo, mas que a médio e longo prazo, se mostra essencial! Porém, como vivemos numa geração imediatista, muitas vezes as pessoas tem dificuldade em entender isso.
  • Complexidade: a criação de testes em sistemas complexos é um desafio maior ainda, às vezes pode ser mais difícil do que a própria implementação.
  • Sistemas legados: se dá uma manutenção em um sistema legado já é uma missão de embrulhar o estômago, imagine só criar testes para ele. Uma solução legal, comentada pelo pessoal e colocada em prática é realizar testes em nível de sistema, utilizando o Selenium por exemplo.

O Jorge Diz lembrou que a área de Teste de Software, costuma vir no reboque quando se usa metodologias frágeis (tradicionais). Mas usando metodologias ágeis o Teste de Software é incentivado, as novas técnicas já trazem na sua essência o pensamento de testar. Aliás, um exemplo disso é o uso de programação em par, onde uma pessoa já está revisando o código (lembrando que revisar é uma forma de testar).

Sobre o uso de BDD e TDD, o Anderson Leite disse que antes de partir para o uso delas, as pessoas precisam primeiro adquirir o hábito e prática de testar, só depois que já tiverem maduras podem começar a usar o BDD e TDD.

O Cássio Marques contou um pouco da sua experiência com linguagens de comparação, comparando no quesito de facilidade de testar. E disse que escrever testes em C e C++ é bem difícil, em Java também é meio enrolado. Já em Ruby é bem mais fácil. Podemos dizer que Ruby tem uma melhor “testabilidade”, que as outras, ou seja, se você é desenvolvedor Ruby e não testa, então você tem uma desculpa a menos para usar. 🙂

Um ponto importante discutido foi que se você testa, você não pode se dar ao luxo de deixar de testar uma funcionalidade, pois poderá resultar na velha história da janela quebrada.

Para terminar a primeira parte, houve uma demonstração do uso do Cucumber pelo Anderson. A minha primeira impressão foi que pareceu mágica o que ele fez (rsrs), ele escreveu os testes usando TDD e gerou o código usando o Scaffold de um cadastro de participante que tinha os campos nome e e-mail. Achei bem legal a demonstração, o Cucumber é uma ferramenta muito legal, nela você cria o teste como se estivesse criando uma caso de teste, segue abaixo um exemplo:

Exemplo de teste feito para o Cucumber

O Cucumber utiliza por default o Webrat, porém também é possível realizar o teste usando o Selenium RC, basta passar como parâmetro. O interessante do uso do Webrat é que diferente do Selenium, ele simula o navegador, rodando em background, ou seja, é muito mais rápido que o Selenium RC, porém tem a limitação de não conseguir testar javascript.

E depois do “rango”,  a segunda parte foi no mesmo nível que a primeira?

Depois do excelente coffee break, o Jorge Diz passou vários slides explicando a teoria de testes, abordando desde as escolas de teste até sobre os tipos de dublês. Essa parte fugiu um pouco do formato de debate, mas logo o Rafael Rosa retomou o formato, estimulando uma discussão sobre mocks e o perigo de “engessar muito” utilizando eles.

Do debate sobre mocks, o pessoal chegou a seguintes conclusões:

  • Se você está “mockando” muito, pode ser um sinal que a sua classe está fazendo mais do que ela deveria fazer. Então REFATORE;
  • Sempre tente modularizar ao máximo a sua aplicação, nada de ter uma classe “sistema”;
  • Os dublês em geral, devem ser usados sempre para resolver uma dependência.

Um assunto interessante abordado na apresentação do Jorge, foi como deve ser a pirâmide dos testes, de acordo com o nível:

TestingPyramidMas o que ocorre, geralmente, sem essa cultura de que desenvolvedor também testar, é uma inversão dessa pirâmide, ou seja, não há quase nenhum teste de unidade e integrado realizado, e muitos testes de sistema feitos pelo pessoal de Teste de Software.

E ainda houve mais duas práticas, uma com o Thiago Scalone mostrando o Selenium IDE e o RC. E depois mais uma com o Anderson apresentando o RSpec (o JUnit do Ruby)

E o que você achou? Pelo jeito deve ter sido ótimo, afinal além de falar de testes deve coffee break na faixa.

Excelente encontro! Comprovou que é mito essa história que desenvolvedor não testa, eles testam sim, e até melhor do que muito testador que tem por aí. E Ruby é uma linguagem que oferece uma “testabilidade” incrível, as ferramentas que existem são muito boas, e ajudam desde o teste de nível unitário até o teste de nível de aceite. E essa brincadeira que faço sobre “lado negro da força”, em breve ficará sem sentido, pois os testes estão se tornando cada vez mais uma tarefa inerente ao desenvolvimento.

Para encerrar o post, parabéns a todos que participaram, e principalmente, ao Rafael Rosa, pela excelente organização!

Para saber mais sobre o 6ºEncontro acesse a wiki do Guru-SP:

http://guru-sp.com/index.php/Sexto_Encontro

E para saber sobre os próximos encontros acompanhe o Ruby Inside Brasil:

http://www.rubyinside.com.br/

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

guru espiritual

Como testamos o Basix? – Introdução

Após mais de 100 posts escritos, chegou a hora de falar um pouco sobre algumas experiências que passei, de forma mais detalhada. 😀

E para começar nada melhor do que contar uma das mais interessantes e desafiadoras: o Basix (em japonês aqui).

Assistindo o vídeo abaixo, já dá para perceber um pouco, porque disse que é um desafio e também irá facilitar o entendimento do post 😉

Agora vamos analisar melhor o cenário e as características do projeto, com a visão de Teste de Software:

  • Em 2005 o mundo era diferente: o projeto teve início em 2005, e naquela época não tinhamos nenhum time de testes na empresa (eu nem trabalhava na Voice), além disso, na época Teste de Software não era tão comentado como é hoje, mal haviam publicações brasileiras sobre a área, para ter idéia nem o DFTestes existia;
  • É uma solução IP-Centrex: contratar pessoas para testar um sistema Web é uma coisa, agora contratar pessoas para testarem um PABX IP, utilizando SIP e num ambiente Linux, é algo muito mais complicado;
  • A complexidade do projeto é muito alta: como foi dito no vídeo “O Basix faz tudo que um PABX comum faz”, mas na verdade o Basix faz muito mais do que um PABX faz. Além das funcionalidades de call control, há um sistema Web, onde é possível realizar as configurações do sistema. Isso sem falar sobre a parte de alta disponibilidade e performance, essa merece um post exclusivo;
  • Se testar já é difícil, imagine gerenciar: gerenciar a área de testes não é uma missão fácil por vários motivos:
    • Prazos apertados;
    • Falta de conhecimento dos integrantes do time;
    • Versões em paralelo;
    • Versões com muitas funcionalidades e correções.
  • Ambiente de teste: o ambiente da produção possui equipamentos muito caros, que não são possíveis de ser adquiridos para o ambiente de teste, além disso, há diferenças entre a infra-estrutura dos dois sites (Brasil e Japão);
  • Automatização dos testes: automatizar os testes é a atitude ideal para as características do projeto, porém qual ferramenta eu posso utilizar para automatizar uma transferência cega com REFER, por exemplo?
  • O desenvolvimento do projeto é incremental: nada de testar só no final do projeto, o time de testes começa a trabalhar desde as primeiras reuniões de definições do escopo;
  • Alta qualidade: a Brastel, parceira e cliente, é uma empresa japonesa, e o fato de ter sido fundada por brasileiros, não alivia nem um pouco a expectativa e cobrança pela qualidade do Basix.

Por hoje é só pessoal. Contei por enquanto apenas os desafios, nos futuros posts irei falar como lidamos com eles, ou seja, a parte mais interessante. 🙂

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

O melhor da semana 13/09 a 19/09

Pessoal,

Segue abaixo, os links para o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

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

Teste de Software em 2050

Já ouvi várias pessoas dizerem que a área de Teste de Software começou a crescer e ser reconhecida depois do bug do milênio. Naquela época, eu cursava a 6ª série do ensino fundamental, mas lembro de ter ouvido e lido a respeito de tal bug, até lembro que tinha feito um teste (hehe) com o videocassete de casa, alterando a data para ver se ele seria afetado pelo bug do milênio ou não.

Bem, mas o intuito do post não é ser uma sessão nostalgia, e sim refletir sobre o momento em que ficou claro que testar um software é uma tarefa fundamental durante o desenvolvimento do mesmo, e também mostrar um vídeo que nos faz imaginar como serão os software em 2050, 50 anos após o bug do milênio.

Boa parte das pessoas tem a cultura de agir de forma reativa. Um bom exemplo, foi a insegurança existente na Fórmula 1 até 1994, que causou diversas mortes, e que só a morte de Ayrton Senna, vez com que os responsáveis pelo circo da F1 percebessem que a segurança do piloto é fundamental. E graças as mudanças ocorridas, melhorando a segurança das pistas e dos carros, depois daquele 1º de maio a F1 não teve mais nenhuma morte.

Outro bom exemplo, é o aquecimento global, que todo mundo já ouviu falar, muitos tem consciência de seus efeitos, mas poucos tomam medidas para ajudar a diminuí-lo. E infelizmente, só quando os efeitos forem mais fortes do que já são, iremos tomar providências para combater efetivamente esse problema.

Agora voltando ao mundo dos softwares…

Durante o desenvolvimento do software, testar não era uma tarefa muito comum. No entanto, a partir do ano 2000 essa história começou a mudar. Para evitar a ocorrência do bug do milênio, as empresas tiveram que gastar milhões, e ficou claro o quanto um software não testado ou mal testado está mais propenso a ter bugs e a gerar prejuízos. De lá para cá , houve um grande crescimento da área de Teste de Software, tanto que hoje é possível encontrar bons livros até em português, falando sobre essa área que antes só existia de forma informal nas empresas.

Para ter idéia da informalidade que existia nas empresas (ou talvez, ainda exista em algumas), um profissional de TI, com longa experiência na área, me disse uma vez, que antes quem testava o software era os estagiários de programação, e lá no final, quando o software já estava sendo finalizado.

Hoje, muitas empresas já tem profissionais capacitados e dedicados só para o teste de software e as suas atividades iniciam junto com as do desenvolvimento do software. Além disso, temos até fábricas de Teste de Software, mostrando que testar um software é uma tarefa que está sendo levada a sério por muitas empresas.

Para encerrar e justificar o título do post, deixo abaixo o vídeo (a inspiração para esse post), que mostra um teste de segurança, feito por um dos mais respeitados institutos de segurança automotiva do mundo, o IIHS dos Estados Unidos, comparando a segurança de um Chevrolet Bel Air 1959 (o primeiro aprovado pelos testes do IIHS), contra um Chevrolet Malibu 2009 (o mais recente avaliado):

E como dizem “toda ação tem uma reação” e a ação de testar tem a reação de garantir e melhorar a qualidade. E como com o passar dos anos ficamos mais exigentes, acabamos precisando de cada vez mais testes. Afinal, o que você acha mais fácil de testar um Motorola Microtac ou um iPhone?

Motorola - Microtac X Apple - IPhone

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

P.S.: Espero poder fazer, em 2050, um post relatando a melhoria na qualidade dos softwares alcançada com a ajuda dos testes, comparando com a do ano 2000. 😀

O melhor da semana 07/09 a 12/09

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

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

Certificação SEI Capability Maturity Model Integration (CMMI)