quarta-feira, 27 de outubro de 2010

Mantenha seu código limpo como sua casa

cozinha suja

Resolvi escrever esse post para falar de código limpo (clean code).

Já pensou uma casa tão suja e desorganizada que você não consegue entrar na cozinha ou pegar uma roupa no armário. Até diarista pediu aumento devido à bagunça.

Um sistema cresce e seu código também. O crescimento sem cuidado leva a um código enorme (nada enxuto), não legível e bagunçado. O pesadelo dos desenvolvedores.

O código deve ser limpo como sua casa. Limpezas frequentes são altamente recomendáveis.

Sugestões para manter o código limpo:

  • Controle do tamanho dos métodos, funções, classes e sistemas;
  • Use nomes significativos para funções e métodos, evitando os comentários. Código com excesso de comentários não são legíveis;
  • Use nomes significativos nos testes unitários. Os testes unitários comentam os métodos que testam.
  • Teste de integração;
  • Trate exceções;
  • Construa um software para suportar concorrência. No ambiente web é importantíssimo;
  • Padronização de código e indentação para todas as equipes. Para indentação existem  IDE’s que fornecem recursos de formatação automática;
  • Regra do escoteiro: Deixe área do acampamento mais limpa do que quando você a encontrou. Para código a mesma regra: não limpe somente seu código, limpe dos outros também. Quando encontrar código ruim, melhore com os seguintes passos:
    • Testes unitários;
    • Refatorar;
    • Commit.

Uma excelente leitura  é o livro “Clean Code” escrito por “Robert C. Martin”.

Fonte:

Dev in Sampa 2010 – Código Limpo – Hugo Corbucci (outro ângulo):

    Uma excelente leitura  é o livro “Clean Code” escrito por “Robert C. Martin”.

    Fonte:

    Dev in Sampa 2010 – Código Limpo – Hugo Corbucci (outro ângulo):

    http://www.blip.tv/file/4024593

    Bye see you next post

    sábado, 23 de outubro de 2010

    segunda-feira, 18 de outubro de 2010

    QA e Equipe Ágil

    testeranddeveloper

    Apesar do titulo do artigo demonstrar que QA é separado da equipe ágil, digo que idéia é inversa. Sabemos que uma equipe ágil é multidisciplinar e o papel do QA é importante para garantia de qualidade de teste.

    TDD e ATDD

    O TDD antecede o comportamento do código e O ATDD (Teste de Aceitação) antecede o comportamento do software (Webinar: O ciclo ATDD + TDD por Scrum Amazônia, Paulo Igor e Heitor Roriz).

    O QA achou que não tinha papel no Extreme Programming

    Em STAREAST 2008, numa palestra “Testing Lessons from Extreme Programmers, Elisabeth Hendrickson” os testadores diziam que no Extreme Programming (XP) não tinham um papel definido. A equipe XP praticava tanto TDD como ATDD de modo eficaz.

    Mais adiante veremos que o QA tem papel fundamental numa equipe ágil

    Por que é importante o QA numa equipe ágil?

    Os Analistas, projetistas e programadores usarão o TDD e o ATDD para desenvolver o produto.

    Porém a visão de um profissional de QA (Engenheiro e Analista de teste) ajudará a melhorar arquitetura e plano de caso de teste.

    Imagine apresentar para o cliente um teste de aceitação usando selenium (excelente software) e os resultados saírem na janela do JUnit numa IDE de desenvolvimento. Realmente não ficará apresentável para cliente, mas para garantir a qualidade  do produto dentro da equipe técnica tudo bem.

    O mais correto é a integração do código de teste de aceitação com uma ferramenta de gerenciamento de caso de teste, por exemplo, ferramenta Testlink. Esta ferramenta será responsável pela geração do relatório de resultado do teste de aceitação que será apresentado para cliente.

    Em suma, a união de analistas, projetistas, desenvolvedores e QA têm grau elevado de importância para desenvolvimento do produto orientado a teste com qualidade.

    O papel do QA no TDD

    tdd 

    É recomendável que QA participe dos testes unitários. Aprendendo e ajudando os demais membros da equipe ágil.

    O teste unitário antecede o comportamento do código, porém é focado na funcionalidade.

    O Teste de desempenho poderá aproveitar o teste unitário, um exemplo é uso do JUnit junto ao JUnitPerf. Podendo simular: usuários, interações e tempo.

    O Teste de desempenho é mais uma garantia de qualidade para toda equipe.

    O papel do QA no ATDD

    atdd

    Aqui o papel do QA é fundamental. Na elaboração de plano de caso de teste de aceitação, integração da ferramenta de teste de código (exemplo: selenium) com gerenciador de caso de teste.

    É necessário um plano de caso de teste para escrever o teste de aceitação no código, e ninguém melhor que QA para escrever plano de caso de teste.

    E QA será também apresentador do resultado do teste de aceitação para cliente.

    Eis a questão(Shakespeare):

    Do que adianta teste de aceitação sem um bom plano de caso de teste?

    Fonte:

    http://sembugs.blogspot.com/2010/10/integracao-selenium-e-testlink.html

    e

    Webinar O ciclo ATDD + TDD by Scrum Amazônia, Paulo Igor e Heitor Roriz:

    http://www.slideshare.net/Pigor/palestra-tddcompleta-5460534

    e

    video.google.com/videoplay?docid=-3903817398443328799#

    Bye see you next post

    domingo, 17 de outubro de 2010

    Teste de Aceitação no Eclipse IDE usando Selenium

    testing

    O ATDD nada mais é que o teste aceitação. Aqui no post foi criado um teste de aceitação via código usando Eclipse IDE Galileu, sem integração com Testlink ou outros. Apenas usamos Selenium RC(com api’s server e client) e JUnit 4. 

    O Teste foi feito no Blog Cantinho do Agile - label Agile:

    http://cantinhodoagile.blogspot.com/search/label/Agile/

    Foram testados textos e um link no post: Checklist para definição de feito.

    Api’s necessárias no Java Build Path do Eclipse IDE:

    javabuildpath

     

    selenium-server.jar 1.0.3

    selenium-java-client-driver-.jar 1.0.1

    Jdk 6

    JUnit 4.jar: Vem no Eclipse IDE Galileu.

    Código do teste de aceitação no blog Cantinho do Agile – label Agile:

    import junit.framework.TestCase;

    import org.junit.Test;
    import org.openqa.selenium.server.SeleniumServer;

    import com.thoughtworks.selenium.DefaultSelenium;
    import com.thoughtworks.selenium.Selenium;

    public class CantinhodoAgileTest extends TestCase {

        Selenium selenium;
        SeleniumServer servidor;

        public void setUp() throws Exception {
            servidor = new SeleniumServer();
            servidor.start();

            selenium = new DefaultSelenium("localhost", 4444, "*firefox",
                    "http://cantinhodoagile.blogspot.com/search/label/Agile/");
            selenium.start();
        }

        @Test
        public void testChecklistDefinicaoFeito() throws Exception {
            selenium.open("/");
            assertTrue(selenium.isTextPresent("Checklist para definição de feito"));
            selenium.click("link=Checklist para definição de feito");
            assertTrue(selenium
                    .isTextPresent("Os dez itens do checklist para definição de feito são:"));
        }

        public void tearDown() throws Exception {
            selenium.stop();
            servidor.stop();
        }

    }

    Note que servidor Selenium é iniciado e finalizado pelo código. Também temos a Classe Selenium(representada pelo objeto selenium) que é responsável pela realização das verificações junto ao JUnit.

    No exemplo o navegador web é Firefox e a porta 4444.

    Resultado do Teste de Aceitação:

    Comecei quebrando o teste até fazer passar e logo após fui melhorando:

    junit4 

     

    O teste foi apenas um simples exemplo de como fazer teste de aceitação no Eclipse IDE usando Selenium.

    Porém recomendo uma integração da equipe de analise e projeto com QA para elaboração de planos de casos de testes. E uma integração do código de teste de aceitação com uma ferramenta de gerenciamento de caso de teste e execução.

    Um bom exemplo seria integração do Selenium com Testlink. Dois excelentes artigos sobre integração de autoria de Elias Nogueira são:

     Integração Selenium e Testlink 

    ou

    Integração Selenium e Mantis

    Uma ferramenta de gerenciamento de caso de teste proporciona uma visualização amigável e de bom entendimento para o cliente do teste de aceitação. Por exemplo, com uso de relatório.

    Ferramentas e Api’s necessários para executar o exemplo:

    1)Selenium RC http://seleniumhq.org/download/

    • Um servidor que executa automaticamente e mata o navegador e atua como um proxy HTTP para solicitações web a partir dele;
    • Disponibiliza biblioteca cliente para a linguagem de programação usada, no caso do exemplo a biblioteca cliente é para java.

    2)JUnit http://www.junit.org/

    Obs.: É possível pegar uma versão mais avançada do JUnit.

    3)Java JDK http://www.oracle.com/technetwork/java/javase/downloads/index.html

    Obs.: É possível pegar uma versão mais avançada do JDK.

    4)Eclipse IDE http://www.eclipse.org/downloads/

    Obs.: É possível pegar uma versão mais avançada do Eclipse IDE.

    Fonte:

    http://seleniumhq.org/projects/remote-control/

    http://sembugs.blogspot.com/2010/10/integracao-selenium-e-testlink.html

    Webinar O ciclo ATDD + TDD by Scrum Amazônia, Paulo Igor e Heitor Roriz:

    http://www.slideshare.net/Pigor/palestra-tddcompleta-5460534

    Bye see you next post

    sexta-feira, 15 de outubro de 2010

    Checklist para definição de feito

    done

    Os dez itens do checklist para definição de feito são:

    • Códigos produzidos. Os Todo’s com códigos completados;
    • Códigos comentados. Check-in e rodar em comparação a versão atual no controlador de versão;
    • Avaliação em pares(pair programming) e/ou padrão de desenvolvimento por reunião;
    • Construir sem erros;
    • Testes unitários construídos e passagens pelos testes com sucesso;
    • Deploy do sistema no ambiente de teste e passagem com sucesso do sistema nos testes;
    • Passagem com sucesso nos testes de aceitação do cliente e requisitos cumpridos;
    • Qualquer construção ou implantação de mudanças ou configuração implementada ou documentação;
    • A documentação relevante ou diagramas produzidos;
    • Horas restantes passam para “zero” e a tarefa é fechada.

    Fonte: http://www.agile-software-development.com/2007/07/definition-of-done-10-point-checklist.html

    Bye see you next post