sexta-feira, 10 de outubro de 2014

Test Driven Development e o esforço para ter isso

Test Driven Development é uma pratica sugerida pela metodologia ágil XP. A ideia é fazer testes automatizados antes de desenvolver a implementação. Essa inversão traz diversos beneficios para o projeto como uma suite de teste maior, cobrindo mais casos e garantindo maior qualidade externa. Para escrever testes de boa qualidade, exige que o código também seja escrito com qualidade, usando boa orientação a objetos e talvez padrões de projeto para soluções.
Mas TDD não garante o código de boa qualidade se os testes não forem de boa qualidade. Para isso é necessário um esforço para manter o código sempre melhor e estudar praticas a fim de aumentar a qualidade. A pratica do TDD bem usada torna o produto melhor e a equipe produtiva.


TDD, XP, testes antes da implementação, qualidade externa, bons testes de unidade, orientação a objetos, codigo melhor, aumentar a qualidade deve ser estudada, pratica do TDD bem usada, produtiva

segunda-feira, 22 de setembro de 2014

É prioridade?

Se testar é uma prioridade,
Então vamos testar toda hora.

Se integrar é uma prioridade,
Então vamos integrar com frequência.

Se interações curtas é uma prioridade,
Entao vamos deixar as interações realmente curtas.

Se entregas constantes são prioridades,
Então vamos entregar todos os dias.

Autor: Rogério Figueiredo (https://github.com/rogersmuk)

segunda-feira, 7 de julho de 2014

Testes de unidade, integração ou sistema? Você já fez cada um deles?

Nas equipes de desenvolvimento é comum a discussão de que os testes de sistemas devem ser abrangentes, ou devemos aumentar a cobertura dos teste de unidade. Será que o entendimento de cada nomenclatura dos testes é igual para todos?

Na equipe que trabalho tivemos essas discussões e foi preciso igualar o conhecimento das nomenclaturas para que ter uma comunicação eficaz.

Um dos artigos usados como referência foi do Mauricio Aniche: http://blog.caelum.com.br/unidade-integracao-ou-sistema-qual-teste-fazer/

Texto coloca com precisão o que é cada teste. Também explica um pouco que cada um tem um contexto para ser usado.

sexta-feira, 20 de junho de 2014

Sessão de design colaborativo

Existem decisões que podem ser adiadas e outras que precisam ser tomadas o mais cedo possível.

Sessão de design colaborativo é uma forma de alinhar o entendimento do que vai trabalhado. É também usada para criar produtos diante de uma necessidade.

Glauber tem uma sugestão bacana em como a equipe pode conduzir essa reunião: http://glauberramos.com/sessao-design-colaborativo.html

terça-feira, 27 de maio de 2014

Todos testes devem ser feitos

Apenas um tradução do um ponto de vista que eu compartilho.

Todos testes devem ser feitos...

- Baseado em risco: Cuidar para não perder usuários, dinheiro, nome, quota de mercado, o valor da marca, clientes, pessoas, etc..
- Guiado ao negócio: Focada em objetivos que a empresa quer alcançar
- Com cuidado para os usuários: realmente cuidar deles e não se masturbar sobre cuidar deles
- Para melhorar as vendas: foco na conversão, funil de conversão, menor custo por aquisição de clientes 
- Para aumentar a rentabilidade: para ser mais eficiente ao fazer o mesmo dinheiro
- Para fazer com que os clientes satisfeitos: por apenas permitindo-lhes fazer o que eles pretendem com o software

Será que o seu teste cobre os pontos acima?

Se, todo o seu teste que é feito para testar a estabilidade funcional e não se importa com os pontos acima - o teste é de valor extremamente baixo e em algum dia não vão se importar com você e seus testes. Não que você não sabe.


Fonte: http://testertested.blogspot.com.br/2014/03/all-testing-done-should-be.html


A opinião de Pradeep Soundararajan é enfática que estes pontos não podem ficar de fora do teste. Acho que ele também poderia usar mais argumentos e menos emoção. Nesse assunto ou o autor fala de forma muito acadêmica ou de forma pessoal. Cabe a cada um aproveitar o melhor.

quarta-feira, 9 de abril de 2014

Referências TDD/BDD

Gostaria de agradecer muito o colega Eduado Lima pelas referências:

ARTIGOS:

*Artigo em que o James Coplien critica fortemente o TDD e outras práticas do XP ( MUITO polêmico, mas vale demais a leitura): http://www.rbcs-us.com/images/documents/User-Stories-and-Test-Driven-Development.pdf

*Definição de TDD do Martin Fowler: http://martinfowler.com/bliki/TestDrivenDevelopment.html

*Comentários sobre BDD do Martin Fowler: http://martinfowler.com/bliki/GivenWhenThen.html

*Diferenças entre BDD e  TDD:

*Paper do Kent Beck (cara que popularizou o aperfeiçou o TDD, praticamente o pai da prática) sobre o SUnit, o primeiro framework em que se usaram as técnicas de TDD
como se usa hoje, e um marco na prática: http://www.xprogramming.com/testfram.htm

*Vídeo-aulas de TDD, ensinadas diretamente pelo Kent Beck:


*Post do Uncle Bob sobre TDD, refatoração de testes e arquitetura: http://blog.8thlight.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html

*Post sobre as 3 regras do TDD do Uncle Bob: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd


*Posts do Uncle Bob sobre TDD em Startups: http://blog.8thlight.com/uncle-bob/2013/03/05/TheStartUpTrap.html

*Post sobre BDD do Dave Astels (Se não me engano o artigo que cunhou o termo BDD): http://web.archive.org/web/20090419153557/http://techblog.daveastels.com/2005/07/05/a-new-look-at-test-driven-development


*Post de BDD do Dan North(Um dos pais do BDD): http://dannorth.net/introducing-bdd/
*Debate épico, lendário e monumental entre o Uncle Bob e o James Coplien sobre TDD: http://www.infoq.com/interviews/coplien-martin-tdd

LIVROS:

1)Iniciantes:
- Test-Driven Development By Example (Do Kent Beck, obrigatório pra quem quer estudar TDD) => http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530

- Capítulo 4 do livro Agile Software Development: Principles, Patterns and Practices do Uncle Bob (espetacular) => http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/

- Capítulo 5 do livro The Clean Coder: A Code of Conduct for Professional Programmers, do Uncle Bob (espetacular) => http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/

- The Art of Unit Testing: with examples in C# (Passo-a-passo em TDD para programadores .NET) => http://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890


2)Intermediários/Avançados:
- Capítulo 9 do livro The Clean Code: A Handbook of Agile Software Craftsmanship, do Uncle Bob => http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/

- xUnit Test Patterns: Refactoring Test Code (Catalógo de Patterns de testes, para usuários mais avançados) => http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054/

- Growing Object-Oriented Software, Guided by Tests (Evolução de sistemas orientados a objeto com o uso de testes) => http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/


- The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends (Se aplica mais ao Ruby, mas fornece muitas definições sobre BDD, com alguns dos criadores da técnica) =>

-Working Effectively with Legacy Code (Refatorando e lidando com código legado, usa testes como a técnica central para lidar com código legado ) => http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

segunda-feira, 31 de março de 2014

Data Driven Testing (Teste guiado a dados)

Data-driven testing é a criação de scripts de testes para executar juntamente com conjunto de dados.

A estrutura exige uma lógica reutilizável para que as entradas e resultado esperado sejam fornecidas pelos dados e a ação se repete variando os dados.

Esse conceito existe no Junit com a classe Parameterized. doc: http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html

Para utilizar, deve colocar a anotação na classe:
@RunWith(Parameterized.class)
 
Além de colocar anotação no método estático que provê os dados:
@Parameterized.Parameters 


Dessa forma é possível colocar dados em seus scripts do JUnit.

Mas para facilitar criei um método que le de um xls e retorna o matriz de objetos.

Usando a biblioteca jxl, alterar o pom.xml (ou adicionar o jar) com:
        <dependency>
            <groupId>net.sourceforge.jexcelapi</groupId>
            <artifactId>jxl</artifactId>
            <version>2.6.12</version>
        </dependency>

O metodo ficou assim:
public class ReaderXls {
  
    public static Object[][] lerXls(String arquivo) {
        Workbook workbook = null;
        try {
            workbook = Workbook.getWorkbook(new File(arquivo));
        } catch (Exception e) {
            e.printStackTrace();
        }

        Sheet sheet = workbook.getSheet(0);
        int linhas = sheet.getRows();
        int colunas = sheet.getColumns();
        System.out.println(linhas);
        System.out.println(colunas);

        Object[][] retorno = new Object[linhas][colunas];

        for (int i = 0; i < linhas; i++) {
            Object[] linha = new String[colunas];
            for(int j =0; j < colunas; j++)
            {
                linha[j] = sheet.getCell(j, i).getContents();
            }
            retorno[i] = linha;
        }

        return retorno;
    }
}

O metodo de dados na classe de teste ficou assim:
@RunWith(Parameterized.class)
public class CadastroUsuarioTest{

    @Parameterized.Parameters
    public static Collection<Object[]> dados(){
        Collection dados = Arrays.asList(
                ReaderXls.lerXls("C:\\Automacao\\usuario.xls")
        );
        return dados;
    }


Veja exemplos em:
http://examples.javacodegeeks.com/core-java/junit/junit-parameterized-test-example/

http://www.mkyong.com/unittest/junit-4-tutorial-6-parameterized-test/