segunda-feira, 30 de março de 2009

Apresentando FDD - Fear-Driven Development

Hoje lendo o blog do Nerdson (muito bacana), vi um negócio engraçado e que se tornou mais engraçado pelo fato de conhecer um caso real que usou esta técnica.

Numa empresa que trabalhei anteriormente, tinha um brother recém-promovido à programador (Ou anapropégua* como preferir). Acontece que este carinha tinha um gerente super-star, que se parecia muito com o Dragãozinho do Nerdson.

O pobre infeliz (do programador), estava com a corda no pescoço, com uns 3 projetos em atraso e 1 que tinha que terminar naquele mesmo dia, desta forma, 18:30 hs na mesa do programador estavam: O próprio, O "coordenador" dele, e o Gerente Super-Star.

O pobre programador chegou a um momento de quase um AVC e choramingou: "Vou la fora dar uma respirada, e volto logo". O gerente então lasca: "Sente aí e quando você terminar, pode respirar!".

Veja o Post do Nerdson para ter uma ilustração desta técnica incrível.


*anapropégua = ANAlista, PROgramador e fí duma ÉGUA.

sexta-feira, 20 de março de 2009

Reparando uma injustiça com a Integração Automatizada.

A algum tempo atrás crucifiquei o Sr. Cruise Control, na verdade não a ferramenta, mas o fato de automatizar esta integração. Porém, esses dias vi um novo cenário (que eu não tinha pensado) e que a automatização da Integração pode ser um GRANDE aliado.

Imagine você que seu desenvolvimento esteja tão, ou simplesmente, evoluído o bastante para termos várias "formas" de testes automatizados. Imagine que um de seus testes seja algo como, apagar TODA uma base de dados, e popula-la novamente com os dados mais atuais da aplicação, e só depois executar uma bateria de testes automatizados.

O bom e velho Build de 10 minutos vai pra roça !!!

Considere o exemplo acima apenas um EXEMPLO, pois podem existir várias situações em que sua integração ultrapasse, em muito, o tempo de 10 minutos.

Resumindo, você deve ter "2 momentos" de integração:

* A integração local: que seria a integração realizada em sua maquina, fazendo os testes unitários e, possivelmente, testes de integração;
* E o momento da integração automatizada, que conta com todas as vantagens da ferramenta, como relatórios e afins.

sábado, 13 de setembro de 2008

Novas atividades

Moçada,

sei que estou meio ausente, e voltar a ativa com um post que não tem nada haver com o blog é desastroso, mas tenho um bom motivo:

A mais de 2 meses venho estudando Ruby on Rails, direcionei todas as minhas atenções e horarios vagos para isso e estou percebendo que devo dedicar mais tempo ainda. Bem, o caso é que criei um novo blog pra falar sobre Ruby on Rails, e venho convidar a todos que se interessem pelo assunto a visita-lo. Bem, os assuntos que se relacionem com testes eu postarei nos 2 blogs, então se não se interessar por Rails, pode aguardar os posts sobre testes aqui mesmo.

Até mais

quinta-feira, 5 de junho de 2008

Fóruns que precisamos conhecer (Sobre Testes)

Em desenvolvimento, dúvidas são frequentes, por isso vou listar alguns lugares (Fóruns sobre teste e utilitários) que podemos encontrar soluções para os mais diversos problemas e mesmo encontrar respostas para nossas novas dúvidas.

EclEMMA: https://sourceforge.net/forum/forum.php?forum_id=614869
EMMA: http://sourceforge.net/forum/forum.php?forum_id=373865
JMock: http://www.jmock.org/mailing-lists.html
JMockit: https://jmockit.dev.java.net/servlets/SummarizeList?listName=users
JUnit: http://www.nabble.com/JUnit-f2687.html
Selenium: http://www.nabble.com/Selenium-f14083.html

XP-Rio (Sobre práticas ágeis, TDD, outras formas de testar software): http://tech.groups.yahoo.com/group/xprio/

Resolvendo o problema do finally no EclEMMA

A algum tempo reclamei do meu colega EclEMMA aqui, acontece que fiz uma pergunta num forum do produto, e mesmo com o meu inglês digno de um índio, obtive uma boa resposta:

"Hi, the yellow line is an artifact of the underlying coverage technology which is based on byte code instrumentation. "Finally" statements only exist in Java source code, the Java compiler creates corresponding control structured in byte code. The finally block is actually executed in two different cases: In case of normal execution and in case of an exception within the try block. You're test code follows only one the these paths, therefor the line is marked yellow (partial execution)."

Muito bacana, dessa forma percebi que tenho que deixar o método disparar a exceção, caso ela aconteça, e tenho que verifica-la no método de teste.

Usando o mesmo exemplo, eis a forma correta de testar e obter o resultado correto com o EclEMMA :

1: public class StupidClass {
2:
3: public String falar() throws Exception{
4:
5: try
6: {
7: System.out.println("try: ");
8: System.out.println("oyeah!");
9: }
10: catch (Exception e)
11: {
12: System.out.println("catch");
13: e.printStackTrace();
14: throw e;
15: }
16: finally
17: {
18: System.out.println("ogou!");
19: }
20:
21: return "oh! fezes";
22: }
23: }
e seu teste fica assim:

0: import static org.junit.Assert.assertEquals;
1: import static org.junit.Assert.assertNotNull;
2:
3: import org.junit.Before;
4: import org.junit.Test;
5:
6: public class TestStupidClass {
7:
8: StupidClass stupidClass = null;
9:
10: @Before
11: public void antes(){
12: stupidClass = new StupidClass();
13: }
14:
15: @Test
16: public void falarTest() throws Exception{
17:
18: assertEquals("Test 1", stupidClass.falar(), "oh! fezes");
19:
20: Exception exp = null;
21:
22: try{
23: stupidClass.falar();
24: }catch (Exception e) {
25: exp = e;
26: }
27:
28: assertNotNull("Test 2", exp);
29:
30: }
31: }
Obrigado ao pessoal do EclEMMA.

terça-feira, 13 de maio de 2008

O que o cliente quer, o que você entrega

Essa figura é bem manjada, mas ilustra muito bem o que acontece com o desenvolvimento de software. As metodologias ágeis vieram ao mundo pra tentar reduzir essa distancia entre o que o "cliente quer" e o que você entrega, algumas práticas como Interações Curtas e Testes podem te ajudar a estar sempre mais próximo de atingir os seus objetivos.