Rodar os testes com TestNG ou Junit? O dilema.

Se você trabalha com automação de teste, seja ele unitário ou funcional, já deve ter ouvido falar nesses 2 pequenos notáveis, Junit e TestNG. Junit é macaco velho na area e o TestNG vem mostrando  que é possível fazer as coisas melhores, mas… o que é realmente BOM para você que está começando e não sabe qual desses “trambolhos” deve usar?

Para nivelar o conhecimento, o Junit e TestNG são frameworks de teste unitário, ou seja, são plataformas que visa facilitar a execução sequenciada de rotinas de teste e ajudar na validação de eventos e strings  (assert’s da vida), os tornando indispensáveis  para automação de testes.

Junit

O Junit é um veterano de guerra. A plataforma é a mais utilizada por desenvolvedores que querem uma rotina mais rápida de implementar  e que  não precisam / não querem fazer muitas alterações e configurações para rodar seus testes.
Além de ser a mais utilizada por desenvolvedores, ela também está presente em diversas  ferramentas de apoio a desenvolvimento e teste funcional, como por exemplo o Marathon e o Selenium (what? sim,  as funções asserts do selenium são funções do junit baby )

Mesmo sendo tão popular, o ciclo de desenvolvimento do Junit está meio congelado.  Sua ultima versão estável, a 4.8.2 foi lançada em Abril de 2010, a mais de um ano atras! No começo deste ano foi lançada a versão 4.9 beta e os commits para esta versão estão bem devagar, dando cada vez mais espaço para o menino “novo” que vem levando o teste unitário para próxima geração.

TestNG

Com base no Junit e Nunit, a proposta do TestNG é simples:  Criar um framework mais robusto e flexivel.  O nome por trás do projeto é o  ex-googler (agora no linkdin) Cedric Beust,  desenvolvedor e entusiasta de teste. Com esse background do seu criador, o TestNG já está consquistando espaço em projetos mais complicados,  já tem plugins para IDE’s de desenvolvimento como Eclipse e vem crescendo a cada dia.
Com toda essa sinergia por trás do projeto, alguns podem perguntar:  “Por que dividir esforços em projetos diferentes? por que não focar e deixar o Junit melhor do que os 2 juntos?”
A ideia de juntar esforços é válida. Aconteceu isso com selenium e webdriver, porém como aqui a  proposta é outra, fiz um comparativo dos frameworks para que você possa verificar suas diferenças e utilizar aquele que mais se adapta ao perfil do seu projeto.

Comparativo

O comparativo a seguir é baseado na minha experiência com automação e pesquisa sobre as 2 ferramentas, ou seja, talvez possa ter alguma visão errada sobre algum ponto, visto que não faço automação unitária.

Configuração de Teste e Annotations:

O Junit é simples e direto, @After/ Before, @After/ BeforeClass simplificam sua vida. Se você quer um teste rápido e sem muita enrolação, os annotations de setup do Junit são a resposta.
Agora se você precisa de algo mais elaborado e não tem medo de muitas opções, o TestNG fornece  um leque de opções: @after/beforeSuite, @after/beforeGroup, @after/beforeTest, @After/BeforeMethod.  Com tantas opções de configuração de setup em cada etapa do teste, seus scripts ficam mais elaborados, deixando um arquitetura limpa e eficiente.

“Mas que diabos é  esse @After/BeforeGroups e @After/BeforeSuite?”

O TestNG possibilita uma configuração de teste mais eficaz e organizada, tanto pelos annotations, quanto por arquivos de configuração (XML), onde você pode definir quais classes de teste fazem parte de uma suite ou grupo de teste, ou seja, antes de determinado grupo ou de um suite, você inserir rotinas especificas para esses cenarios e também  pode definir prioridade e sequência  de execução baseado nesses grupos.

Você também pode fazer uma coisa totalmente diferente (e meio besta,rs) como  definir a sequência de teste e O QUE TESTAR,  através de uma planilha de excel.
Utilizando os métodos de  chamada do Testng, as classes de testes definidas no excel eram chamadas e seus métodos executados de acordo com a vontade do cliente.

Já  Junit não é possível criar grupos e suites de teste, e por favor, NÃO use dependência de teste no próprio código (chamar um métodos de teste dentro de outro métodos de teste) (#notcool).

invoking TestNG with xml (http://testng.org/doc/documentation-main.html#testng-xml)

Utilizando Massa de Dados:

Com o Junit você pode utilizar o @Parameters e @RunWith  porém ele é meio obscuro.
Você utiliza uma fonte de dados para classe inteira (@RunWith) e definir quem é quem nessa história fica complicado.
Outra coisa que senti desconforto ao utilizar foi o fato de somente poder ter um método que retorna massa de dados de uma classe, ou seja, geralmente a galera faz tudo dentro da mesma classe… o @runwith, @parameter, @test e por ai vai.

Com o TestNG, você define um método como @dataprovider que é o local que vai sair sua massa.
Geralmente o pessoal utiliza com excel (thks indianos!), ou seja, a massa fica dentro de um excel, e o método com @dataprovider recebe os dados em um objeto multi dimensional.
Do outro lado, você pode ter inúmeros métodos com @test utilizando diferentes @dataproviders, ou seja:

Muito mais semântico concorda? é mais “trabalhoso” para organizar mas acho que ele se paga com o tempo.
Também é possivel fazer do mesmo modo que o Junit, colocando o metodo @DataProvider na mesma classe de teste,  dai é so tirar o caminho da classe nos argumentos:

Asserts

Boas praticas dizem: “dont assert too much” mas quando você faz um “assert”, você precisa “bater o olho” e saber o que está errado.
Não sei como está a nova versão (beta) do Junit, mas o assert do junit que vem dentro da biblioteca selenese do selenium, fica difícil saber de prontidão que raios de assert que deu erro.
Com o TestNG fica mais prático, você pode customizar a mensagem de erro

Conclusão

Eu puxo sardinha para o TestNG mas você não precisa largar o Junit para usar o TestNG.
Tudo é uma questão de prioridade. Se você precisa de algo rápido e funcional, vá de Junit, caso contrário, estude um poquinho o TestNG e organize seus testes de uma forma mais bonita (code is poetry!)