E-Plamtax foi um projeto muito positivo que executamos para a Força Aérea. A equipe do E-Plamtax aprendeu muitas coisas no projeto, mas muitas dessas aprendizagens ficaram guardadas conosco. Uma das mais interessantes é a criação de utilitários de teste.

Utilitários de teste são uma maneira de reaproveitar código em testes unitários. Usualmente, isso é feito utilizando os métodos setUp ou @Before dos casos de teste, mas isso tem algumas desvantagens. Por exemplo, em um caso de teste, podemos ter a seguinte inicialização:

    private Address address;
    private AddressDAO addressDAO;
    
    @Before
    public void setUp() {
        address = new Address();
        address.setStreet("Rua fulano");
        address.setNumber("123/A");
        addressDAO = new AddressDAO();
    }

Se tivermos um teste com o abaixo essa inicialização funciona bem…

    @Test
    public void testGetAllAddresses(){
        addressDAO.addAddress(address);
        
        List<Address> addresses = addressDAO.getAllAddresses();
        
        assertEquals(1, addresses.size());
        assertEquals("Rua fulano", addresses.get(0).getStreet());
        assertEquals("123/A", addresses.get(0).getNumber());
    } 

Agora, se tivermos o teste abaixo, o objeto criado é desperdiçado:

    @Test
    public void testGetNoAddress() {
        List<Address> addresses = addressDAO.getAllAddresses();

        assertEquals(0, addresses.size());
    }
 

Se o código for como o seguinte, teremos redundância de código. também temos de decidir SE o outro objeto deve ser criado no @Before também ou no método.

    @Test
    public void testGetAllAddressesMoreThanOne() {
        addressDAO.addAddress(address);
        Address address2 = new Address();
        address2.setStreet("Outra rua");
        address2.setNumber("111");
        addressDAO.addAddress(address2);
        List<Address> addresses = addressDAO.getAllAddresses(); 
        assertEquals(1, addresses.size());
        assertEquals("Rua fulano", addresses.get(0).getStreet());
        assertEquals("123/A", addresses.get(0).getNumber()); 
    }

Esses inconvenientes são menores quando comparados à tarefa de criar as dependências e um objeto para o teste. Por exemplo, para testar uma classe Person que agrega um Address em um outro caso de teste, teremos de ter um @Before semelhante a esse:

    private Person person;
    private Address address;
    private PersonDAO personDAO;
        
    @Before     
    public void setUp() {
        address = new Address();
        address.setStreet("Rua fulano");
        address.setNumber("123/A");
        person = new Person();
        person.setName("João");
        person.setAddress(address);
        personDAO = new PersonDAO();
    } 

O código para a criação de endereços replicou-se, e é difícil criar as dependências. Nesses exemplos, vemos casos simples, mas é fácil visualizar como a situação irá se complicar.

Nós solucionamos esse problema criando uma classe para criar esses objetos. Essa classe seria algo como isso:

    public class TestUtil {
        public static Address utilCreateAddress(String street, String number) {
            Address address = new Address();
            address.setStreet("Rua fulano");
            address.setNumber("123/A");
            return address;     
        }
     
        public static Person utilCreatePerson(String name, Address address) {
            Person person = new Person();
            person.setName(name);
            person.setAddress(address);
            return person;
        }
    }

Nossos casos de teste estendiam a TestUtil, facilitando a criação de objetos:

public class TestAddress2 extends TestUtil {
    private AddressDAO addressDAO = new AddressDAO();

    @Test
    public void testGetAllAddresses() {
        Address address = utilCreateAddress("Rua fulano", "123/A");
        addressDAO.addAddress(address);

        List<Address> addresses = addressDAO.getAllAddresses();

        assertEquals(1, addresses.size());
        assertEquals("Rua fulano", addresses.get(0).getStreet());
        assertEquals("123/A", addresses.get(0).getNumber());
    }

    @Test
    public void testGetNoAddress() {
        List<Address> addresses = addressDAO.getAllAddresses();

        assertEquals(0, addresses.size());
    }

    @Test
    public void testGetAllAddressesMoreThanOne() {
        Address address = utilCreateAddress("Rua fulano", "123/A");
        Address address2 = utilCreateAddress("Outra rua", "111");
        addressDAO.addAddress(address);
        addressDAO.addAddress(address2);

        List<Address> addresses = addressDAO.getAllAddresses();

        assertEquals(2, addresses.size());
        assertEquals("Rua fulano", addresses.get(0).getStreet());
        assertEquals("123/A", addresses.get(0).getNumber());
    } 
} 

Como também precisávamos frequentemente de um objeto qualquer, ou que apenas um ou outro parâmetro fosse definido, criávamos variantes dos métodos:

    public static Address utilCreateAddress() {
        return utilCreateAddress("Qualquer", "Qualquer");
    }

    public static Person utilCreatePerson() {
        return utilCreatePerson("José", utilCreateAddress());
    } 

O E-Plamtax foi um projeto um tanto complexo, com grandes redes de dependências de objetos. O uso desses utilitários de teste viabilizou a prática de TDD no sistema. Era emocionante descobrir que, para criar aquele documento que dependia de sete outros documentos e uns cinco ou seis usuários, bastava chamar um método :)

Naturalmente, há mais sobre nossos utilitários de teste do que foi escrito aqui, e pode haver mais ainda que sequer fizemos. (Por exemplo, pode ser interessante produzir utilitários de teste para classes específicas, ao invés de um gigantesco utilitário) Entretanto, como a ideia é bem simples, esperamos que esse pontapé inicial lhe motive a pensar sobre o tema. Até mais!

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

A maré tá cheia, iô iô!
A maré tá cheia, iá iá!

Duas edições do Maré de Agilidade estão prestes a acontecer e você é nosso convidado de honra!

Com uma pré-organização invejável, Belo Horizonte/MG  sai na frente, nos dias 20, 21 e 22/05, inaugurando a pegada social do evento e sua distribuição online por streaming de vídeo para diversas outras cidades de dentro e fora do estado de Minas Gerais. Na semana seguinte, 29/05, é a vez de Vitória/ES, que levará ao litoral capixaba um time de primeiríssima divisão para networking e troca de conhecimento com o público local.

A 5ª Edição do Maré trás em seu gene a comunidade e as parcerias bem-sucedidas das edições anteriores, fazendo desta uma edição tradicionalmente mineira. Nos corredores, o “dedo de prosa” será o construtor  de networks e em torno de uma mesa, o “café com pão de queijo” fortalecerá parcerias e formará amizades.	O Maré de Agilidade mantém-se fiel a seu objetivo de disseminar Metodologias Ágeis em todas as regiões do país. Assim, chega a Vitória em sua sexta edição.
Dia 20/05 08:00 - Abertura e Credenciamento 08:00 - Márcio Sete: Gestão ágil de projetos com Scrum 19:00 - Éder Frances: Principais Problemas do Product Owner Dia 21/05 08:00 - Abertura e Credenciamento 08:00 - Marco Mendes: Arquiteturas ágeis       19:00 - Rodrigo Yoshima: TDD com Java     19:00 - Mácio Sete: Visual Studio Team System com SCRUM Dia 22/05 07:00 - Abertura e Credenciamento 08:00 - Manoel Pimentel: Coaching e Facilitação de Equipes Ágeis 09:00 - Guilherme Silveira: Deploy contínuo - pois integração contínua não basta 10:00 - Coffee Break 10:30 - Carlos Barbieri e Isabela Fonseca: MPS.BR com metodologias ágeis 11:30 - Rodrigo Yoshima: Implantando Scrum - experiências de um Agile Coach 12:30 - Almoço 13:30 - Leandro Ângelo: Ágil: Previsibilidade & CMMi, como ficam? 14:30 - Heitor Horiz: Planejamento e Estimativas em Projetos Ágeis 15:30 - Pedro Valente: PO na prática 16:30 - Coffee Break 17:00 - Renato Willi: Agilidade e Licitações 18:00 - Alexandre Gomes: Escolhas 2.0 19:00 - Cristiano Lopes: Carreira Profissional – escolha o seu sucesso 20:00 - Encerramento / #horaextra	Dia 29/05 08:00 - Recepção, credenciamento e coffee break 09:00 - Abertura oficial 09:20 - Palestra: Um Produto em duas semanas por Guilherme Silveira, da Caelum 10:20 - Palestra: Negociação de contratos de projetos ágeis por Paulo César M Jeveaux, da Giran 11:20 - Palestra: TDD e Zero Defeito por Fabrício Matos, da Qualidata 12:30 - Parada para o almoço 14:00 - Palestra: Domain-Driven Design por Denis Ferrari, da Mindworks 15:00 - Palestra: a definir por Guilherme Chapiewski, do Yahoo! 16:00 - Coffee break 16:30 - Mesa redonda com Guilherme Silveira, Guilherme Chapiewski, Fabrício Matos, Paulo César M Jeveaux e Denis Ferrari 17:30 - Sorteios e confraternização

Pra você, o que é o Maré?

Durante a preparação dessas duas edições houve um intenso debate na lista de organização do evento sobre a real essência da iniciativa. De uma thread de quase 80 mensagens, colhi alguns depoimentos que me resgataram o orgulho de ser parte deste movimento. Até poema saiu! :-)

E pra você, o que é o Maré?

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

Nesta próxima semana, faremos uma excursão da SEA rumo à Lavras/MG para a realização de palestras e mini-cursos na 4ª Semana Acadêmica da Federal de lá (UFLA). Acho pouco provável que haja algum leitor do blog praquelas bandas mas, de toda forma, segue nossa agenda, caso você queira participar:  5ª-feira, 20/05/2010 15:00 às 16:00 - Scrum, @rwilli 17:00 às 18:40 - Computação Invisível e a Internet de Coisas, @alegomes 19:00 às 20:40 - O Pensamento Ágil, @rwilli 21:00 às 22:40 - Empreendedorismo 2.0, @alegomes 6ª-feira, 21/05/2010 08:00 às 09:40 - Cultura do Design no Desenvolvimento de Software, @ThiagoMartins e @WesleyRocha 10:00 às 11:40 - Manifesto 2.0, @alegomes 19:00 às 22:40 - Mini-curso: RubyOnRails na Prática, @ 19:00 às 20:40 - Playstation 3 como plataforma de desenvolvimento de alta performance, @edhana 21:00 às 22:40 - Mundo Mac: Passado, Presente e Futuro da Apple, @ThiagoMartins Na sequência, seguiremos pro Maré de Agilidade BH. Pé na estrada!

Uma forma prática de entender porque não se deve planejar software por tempo, mas sim por escopo:

São 2 cenários possíveis:

1) Pegamos a tarefa mais importante, estimamos quanto TEMPO ela custa: fica pronta na quarta; Enfiamos a cara e implementamos; Qndo ficar pronto, entregamos;

2) Estipulamos uma data - quarta - e estimamos o ESCOPO que cabe: Até quarta é possível fazer essa tarefa aqui (a mesma!). Enfiamos a cara. Entregamos na quarta de um jeito ou de outro.

Quando chegar a quarta, invariavelmente, o cliente vai achar alguns detalhes que ainda precisam ser ajustados. O que muda nas duas abordagens?

No caso (1) o que acotece é uma dessas duas coisas:
   a) ou o cliente já prometeu pra alguém na quarta e ficamos trabalhando até as 22:00, criando mais e mais bugs e acabamos deploiando uma cagada (Alguém já viu isso?)
   b) empurramos a release pra amanhã, e amanhã a gente acha mais alguma coisa pra mudar, e empurramos pra depois de amanhã, e etc. Não entregamos nunca, não temos feedback do cliente, acabamos priorizando mal os detalhes e perdendo tempo implementando uma besteira que não faz a menor diferença.

No caso (2), o que acontece é o oposto: como combinamos de entregar na quarta, e planejar por escopo (podemos remanejar o escopo), quando a data chegar a gente já viu que não vai dar tempo, simplificou a funcionalidade e entregou uma versão mais simples na quarta! Na quinta a gente prioriza o que faltou com o cliente e isso entra como melhoria na quarta seguinte, se for importante. Se não for, economizamos o esforço de implementar qq besteira e o software já está sendo usado, dando retorno ao cliente.

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>