Mock it with Mockito

Mês passado eu trouxe um tutorial sobre testes unitários usando JUnit 4 que trouxe bastante conhecimento legal sobre questões como boas práticas para a construção de testes unitário, padrões de desenvolvimento úteis que podem contribuir com isso, e um passo a passo para começar a desenvolver software usando testes unitários.

Agora a ideia é dar continuidade aos princípios apresentados, através de uma aula sobre testes unitários utilizando JUnit 4 + Mockito. Mockito é um framework de desenvolvimento de testes unitários, que tem como objetivo dar ferramentas úteis para a construção de testes unitários mais simples, legíveis, úteis e efetivos.

Mockito

Caso se interesse o download do Mockito pode ser obtido através do site https://code.google.com/p/mockito/ e se quiser ver uma documentação mais detalhada, com exemplos de código e formas de implementação, acesse aqui.

Anúncios

How to com experiências em JUnit 4

JUnit é um framework simples, baseado na arquitetura xUnit para a implementação de testes unitários na linguagem Java. O JUnit geralmente vem integrado em IDE’s como Eclipse e NetBeans, mas pode ser obtido através da seguinte url https://github.com/junit-team/junit/wiki/Download-and-Install. Para começar a trabalhar com JUnit é preciso identificar junto à IDE como criar suites de testes. Geralmente uma suite de testes implementada no JUnit estará vinculada a uma determinada classe a ser testada. Cada suite de testes é formada por um conjunto de testes unitários que farão afirmações específicas sobre comportamentos do código, gerando resultados positivos se as afirmações forem verdadeiras, e resultados negativos se as afirmações forem falsas.

Testes unitários no JUnit são caracterizados por métodos de classe que implementam comportamentos da ferramenta. Cada teste unitário pode ser mapeado através de uma anotação @Test, declarada junto com o método de teste para sinalizar ao JUnit que este método deve ser invocado quando executar a(s) suite(s) de testes. Cada teste deve mapear exatamente um cenário a ser testado na aplicação, exigindo que determinados comportamentos sejam testados várias vezes para os diferentes cenários identificados.

Existem afirmações básicas que podem ser utilizadas ao implementar um teste unitário. Dependendo das necessidades e objetivos do teste, afirmações diferentes podem ser melhor aplicadas ao contexto. O teste mais simples pode ser construído usando o comando assertEquals(expected, obtained), que serve para comparar dois valores (objetos), e verificar se eles são iguais (um valor esperado e um valor obtido).

Outros testes podem ser construídos usando comandos como assertTrue(booleanValue). assertFalse(booleanValue), assertNull(valueObject), assertNotNull(valueObject), assertArrayEquals(expectedArray[], obtainedArray[]), e alguns matchers que fazem comparações específicas entre os valores esperados e os valores obtidos. Exceções podem ser esperadas em determinados cenários de teste, sendo verificadas através da anotação @Test presente no cabeçalho, inserindo a Exception.class no atributo ‘expected’. Ex.: @Test(expected=’Exception.class’)

É possível também criar critérios próprios de teste, implementando classes de Assertions especializadas nas abordagens adotadas pelo desenvolvedor. Para isso basta construir comparações e comportamentos que verifiquem as condições desejadas do código. Caso as verificações falhem, o resultado deve ser transmitido através do comando fail(message). Dessa maneira o teste irá falhar e exibir a respectiva justificativa para a falha.

O tutorial apresentado nos slides pode ser consultado através do link https://github.com/rmuchoa/JunitExperience com os códigos armazenados no github. Ps.: O acesso a banco não foi implementado de verdade, foi apenas uma prova de conceito inicial.

Design Patterns: Como descobrir aonde queremos chegar

Padrões sempre existiram nas práticas de codificação de software. Eles eram idealizados e implantados em cada equipe de desenvolvimento, sempre que algum caso de sucesso era identificado e reproduzido em outros projetos. Porém existem alguns padrões específicos que tem sido identificados ao longo do tempo e que foram catalogados e amplamente disseminados e consagrados na comunidade de software, como os célebres Padrões de Projeto.

Image

Um dos mais famosos catálogos de Design Patterns é o catálogo de padrões do GoF (Gang of Four), grupo com os quatro autores do livro “Design Patterns: Elements of Reusable Object-Oriented Software” (1995), que atribuiu popularidade aos conceitos de padrões de projeto. Outro catálogo denominado GRASP (General Responsibility Assignment Software Patterns), foi proposto por Larman em seu livro “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” (2005), e também foi muito importante para a comunidade de software, levando também em conta princípios de desenvolvimento como SOLID.

Um padrão de projeto pode ser identificado sempre que alguma prática de solução de problemas é resolvida de maneira semelhante em diferentes ambientes e equipes de desenvolvimento. Para propor algum padrão de projeto, é necessário identificar 3 critérios muito importantes: o nome do padrão, o problema que o padrão se propõe a resolver, e a forma com que o padrão se propõe a resolver o problema. Alguns autores também se preocupam em definir quando usar e consequencias de usar um determinado padrão de projeto, mas em linhas gerais um padrão de projeto deve ser específico o suficiente para responder ao problema independente de linguagem ou arquitetura.

Os padrões de projeto se tornaram tão relevantes para a comunidade de software, que começaram a orientar a construção de inúmeros projetos ao redor do mundo, inclusive a construção de algumas linguagens de programação, componentes e frameworks de desenvolvimento que temos hoje. A definição de conceitos como padrões de arquitetura, também contribuiu muito para isso, visto que ofereceram a grandes projetos, modelos de arquitetura compostos por diferentes padrões de desenvolvimento reunidos e combinados.

Image

Um problema porém ainda permanece, desenvolver software preocupado com os padrões de projeto ainda é uma tarefa extremamente desafiadora, e que exige um alto grau de experiência e conhecimento de Orientação a Objetos. Como adotar os diversos princípios e leis da Orientação a Objetos, juntamente com os diversos padrões de desenvolvimento? Esta é uma pergunta difícil de se responder, principalmente porque os padrões, diferente das leis e princípios, não vem como uma simples cartilha de como programar, mas vem como uma proposta específica para um problema específico.

Nesse contexto, ressaltamos que conhecer os problemas e aprender a identifica-los ao longo do processo de desenvolvimento, é a chave para começar a demonstrar o real interesse em trabalhar com padrões de projeto. Quando um problema no projeto é identificado e compreendido de forma clara, propor uma solução ideal se torna uma tarefa bem mais objetiva. Se para cada problema de implementação encontrado for possível encontrar um padrão de projeto que solucione o problema, será necessário apenas adaptar a proposta ao projeto, e implementar a solução para resolver o problema.

Image

Martin Fowler catalogou alguns dos principais problemas de implementação de código, chamando-os de code smells ou bad smells (maus cheiros), por servirem como sintomas para as necessidades de refatoração no código e no projeto. Não existe uma relação exata entre um padrão de projeto e um bad smell específico. Mas os padrões de projeto podem ser utilizados de diferentes maneiras, para resolver problemas específicos e contribuir para eliminar alguns dos maus cheiros do código. Isso acontece porque os padrões de projeto possuem foco em problemas específicos, mas apesar disso eles possuem uma base muito forte em leis e princípios de Orientação de Objetos que apontam soluções claras de implementação e como evitar problemas de código.

Cabe a cada equipe de software escolher e desenvolver práticas que agucem a percepção dos desenvolvedores a fim de identificar os problemas mais acertivamente, e nada como a prática diária de desenvolvimento para adquirir esse tipo de experiência.

Objetivos e Desafios com o Clean Code

Para a grande maioria dos desenvolvedores minimamente preocupados com Qualidade, Evolução e Manutenibilidade de Software, um código limpo pode ser traduzido em termos de simplicidade, elegância e legibilidade. Ou seja, atribuir características ao código fonte, que dêem ao desenvolvedor semelhante nível de complexidade necessário para interpretar um texto.

Isso pode soar até estranho, porque apesar de usar linguagem humana para representar conceitos computacionais, a programação muitas vezes subentende um certo nível de preparo implícito do desenvolvedor, para compreender o que está codificando. Mas quando se trata de código legado, com largo domínio de negócio e uma equipe heterogênea formada por todo tipo de desenvolvedores, compreender o código começa a se tornar um grande desafio.

Image

Nesse momento, muitos problemas começam a ser introduzidos no código, como Comentários Ruins e Desnecessários, Duplicação de Código, Classes e Métodos Muito Grandes, Alto Grau de Acoplamento e Dependências. Isso ocorre muitas vezes por utilizar Nomes de Métodos Pouco Intuitivos, ou por implementar Comportamentos com Muitas Condições e Complexidades, ou mesmo por atribuir Muitas Responsabilidades aos Métodos e Classes. Todos esses problemas e mais alguns foram denominados por Martin Fowler como Bad Smells (maus cheiros) que sinalizam reais necessidades de refatoração e reengenharia de código.

Robert C. Martin aborda em seu livro Clen Code, sobre alguns técnicas que propõe uma cultura de desenvolvimento Orientado a Objetos, com o objetivo de preparar desenvolvedores para identificar problemas de código e corrigi-los por meio de refatoração. Mas o problema está em como manter e desenvolver uma cultura de qualidade preocupada com esse tipo de detalhes. Ele apontou ironicamente que uma das mais válidas métricas de qualidade de código é a quantidade de WTFs/Minute. Ou seja, quanto melhor for o código fonte, menos estressante, frustrante e desgastante será a experiência do desenvolvedor ao dar manutenção de código.

Image

Não há como fugir disso, pois existem pesquisas que afirmam que 80% do tempo e custos de desenvolvimento de software são dedicados à manutenção e suporte de aplicações existentes, e que 40% desse tempo é gasto para entender o código fonte (Alexandru Telea). Compreender Software é sim uma tarefa complicada, mas adotar boas práticas de codificação podem contribuir para minimizar esse problema.

O próprio Robert C. Martin em seu outro livro “Agile Software Development: Principles, Patterns and Practices” (2002) apontou alguns princípios e práticas de Orientação a Objetos que tem como objetivo criar sistemas que sejam fáceis de manter e estender ao longo do tempo. O SOLID é uma sigla mnemônica que representa os 5 princípios propostos por Robert (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) e propõe ao desenvolvedor comportamentos que podem guiá-lo a um código mais saudável, como definir e simplificar as responsabilidades de métodos e classes, ou como escolher a melhor forma de abstrair conceitos, comportamentos e implementações ao longo da evolução da arquitetura.

Cabe às equipes de desenvolvimento encontrar as melhores alternativas para transformar esses conceitos teóricos em uma cultura de desenvolvimento mais organizacional. Para isso valem as diversas técnicas e metodologias que apoiem a troca de experiências e a distribuição de conhecimento entre a equipe. Mais informações podem ser encontradas no blog http://www.cleancoders.com/ do autor.

Sass+Compass: Front-end Profissional

Fala Galera!

Hoje vamos falar um pouco sobre desenvolvimento web, mais precisamente ao que tange aos estilos de folha, mais conhecidos como CSS. Se você é um desenvolvedor web front-end provavelmente já teve que lidar com ele e suas regras para que o layout do site fique “bonitinho”. Um grande problema enfrentado ao criar os estilos para CSS é a repetição de seletores e estilos a serem criados para que o layout desejado seja atendido. Quantas vezes você queria tornar um estilo em um componente podendo reutilizar ele em vários momentos? Quantas linhas de código você já teve que reescrever para criar estilos aninhados? Pois é, seus problemas acabaram com os pré processadores de CSS. Abaixo segue uma talk minha que realizamos aqui na uMov.me

O Sass é escrito em Ruby e roda de maneira server-side que pode ser instalado através da gem do Ruby. Atualmente ele possui duas versões, uma mais atual e utilizada chamada de SCSS que suporta CSS3 e que possui uma familiaridade com o CSS na sua identação e estrutura. Também possui uma versão mais antiga chamada SASS que exclui os colchetes e ponto-virgula da sua estrutura. Sua documentação é bem vasta, intuitiva e possui um excelente tutorial.

O Compass é um framework open-source para CSS que se utiliza do próprio Sass para criar folhas de estilos de forma poderosa e fácil. Ela também dispõe da possibilidade de minificar seus CSS, tornando eles menores em seu tamanho e consequentemente obtendo uma renderização mais rápida. Para maiores informações existe este ótimo tutorial demonstrando boas práticas e seu poder.

Deixo para vocês o link do projeto no GitHub ao qual foi feito no vídeo.

Valeu Pessoal!

Até a próxima!