BDD + Smoke Test combina?

Atualmente estou trabalhando muito com BDD e Smoke Test Automatizado. Vou descrever o que eu conheço de intersecção dessas ferramentas de testes de software.

BDD um dos conceitos do Behavior Development Driven é: "Suficiente é suficiente"

Isso implica que o BDD só vai abranger aquilo que é importante para o momento.

Nos meus teste eu vou fazer todas as variações, mas será em outro momento, durante a criação e automação do BDD vamos nos concentrar em fazer funcionar o que precisa funcionar primeiro. Depois eu faço todas as variações e vou aprendendo com os testes exploratórios manuais.

E esse conceito é o Smoke Test, criar testes de fumaça que passa pelas principais funcionalidades para ver se tudo que deveria estar funcionando está. Nesse caso, alguns ciclos de BDD pode já deixar esse smoke test iniciado.

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 (fazer testes antes) traz diversos benefícios para o projeto como uma suíte de teste maior, cobrindo mais casos e garantindo qualidade do que foi testado. Para escrever testes de boa qualidade, exige que o código também seja bem escrito, 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, código melhor, aumentar a qualidade deve ser estudada, pratica do TDD bem usada, produtiva

É 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)

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.

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

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.

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:

-Uncle Bob: https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd

                   https://sites.google.com/site/unclebobconsultingllc/specs-vs-tests

-Dan North: http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/

*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:

http://pragprog.com/screencasts/v-kbtdd/test-driven-development

*Vídeo-aulas de TDD do Uncle Bob: http://cleancoders.com/episode/clean-code-episode-6-p1/show

http://cleancoders.com/episode/clean-code-episode-6-p2/show

*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

*Post do Uncle Bob sobre TDD & Acceptance Tests: https://sites.google.com/site/unclebobconsultingllc/tdd-with-acceptance-tests-and-unit-tests

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

http://blog.8thlight.com/uncle-bob/2013/03/06/ThePragmaticsOfTDD.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) =>

http://www.amazon.com/The-RSpec-Book-Behaviour-Development/dp/1934356379/

-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

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/

Bugs? Tolerância zero!

Em conversas em grupo de teste é comum alguns falar que existe um limite aceitável para bugs. Alguns até falam que pode ser 5% do total de bugs aceitável ir para produção.

Na minha opinião a tolerância deve ser ZERO!

Se algum bug for para produção deve ser adotado como débito técnico.

Analise de vulnerabilidades Cross Site Scipt

Fonte: https://www.owasp.org/index.php/Testing_for_Cross_site_scripting

Ataques de Cross Site Script (XSS) ocorrem quando um invasor usa uma aplicação web para enviar código malicioso, geralmente do lado cliente para um usuário final diferente.

Testes XSS são importantes para que o sistema não seja publicado com uma vulnerabilidade, podendo comprometer a confiabilidade e integridades das informações prestadas.

Nesse artigo referenciado pode ser encontrado algumas técnicas de teste XSS para básicos.

Dilema do QA

Segue artigo sobre deploy continuo.

http://www.startuplessonslearned.com/2009/12/continuous-deployment-for-mission.html

boa leitura.