Aqui em Curitiba está fazendo um frio que dói. Há 14 anos, quando vim para cá isso seria o “armagedom”, mas hoje tira-se de letra com uma bebida quente e as roupas que acumulei em todos esses anos. O lado bom que você pode ficar bem vestido, se bem que alguns dias você lembra o boneco da Michelin.
Bebida quente por outro lado, não é mais café. Minha paixão por essa bebida foi interrompida por uma senhora gastrite. Não que o café por si só seja a origem do problema, mas faz parte da paisagem.
Meus interesses nesses ultimos tempos é me aprofundar em programação Java. Para o trabalho, mais especificamente por causa do JUnit.
Sabe quando o sistema começa a ficar grande demais? Então. Parte do trabalho mais braçal por ser automatizado e outra pode ser evitado. Nessa segunda parte que entra o JUnit.
É incrivel como testes de regreção precisam ser feitos com tanta frequência! Alog que no build anterior fucionava, se seguinte é vira bela tela de erro ou um stacktrace quilométrico.
A ideia é quebrar os testes em partes.
Uma primeira, onde entra o Junit são feitos os testes unitários, e tem função preventiva. Os desenvolvedores ficam com essas classes para execuatar os testes unitários. Só vai para testes (no caso eu) se passar por essa etapa.
A segunda etapa entra os testes automatizados à partir da interface, que pode ser o Selenium ou o Visual Studio. A ideia aqui é simular os usuários interagindo com a interface. Aqui a coisa complica um pouco por dois motivos básicos. AJAX e processos. O Selenium por exemplo me falha miseravelemente quando se tem componentes AJAX envolvidos.
Já a parte dos processo é um pepino por si só. No meu caso expecífico, são encessários alguns mocks automatizados para conseguir combrir um fluxo simples.
E por ultimo testar aquilo que o usuário vê, e dá mais valor que normalmente os desenvolvedores dão. Algo como um botão desalinhado, uma tela bagunçada e cia serão com uma probabilidade imensa reclamada.
Vida de tester não é fácil…. que o diga um “Test Crash Dummie”.
