MathLC

"Onde começa o bem e acaba o mal ? O reino da bondade começa onde a nossa imperfeita percepção deixa de notar o «impulso do mal» porque se tornou demasiado subtil; a partir desse ponto, o sentimento de que entramos no reino da bondade excita os nossos impulsos que se sentem ameaçados e limitados pelos «impulsos do mal»: os sentimentos de segurança, de conforto, de benevolência. Quanto mais imperfeita for a nossa percepção, maior será a extensão do bem. É por isso que as crianças e pessoas comuns gozam de uma eterna boa disposição e também por essa razão que os grandes pensadores sofrem sempre de uma melancolia semelhante à de uma má consciência." (53)

Ao trabalhar com UML obtemos diagramas que representam diferentes visões de um sistema. Da mesma forma, diferentes papeis estão envolvidos e possuem interesses dinstintos: o analista trabalha no alto nível, o arquiteto no intermediário e o desenvolvedor no baixo nível. Cada um deles precisa de um determinado grupo de informações sobre o sistema, que se encontram disponíveis no nível em que atuam.

Alto Nível

É de responsabilidade do analista entrevistar o usuário e entender como funciona o seu processo de trabalho. Daí sai o diagrama de atores e casos de uso. A medida em que são identificadas entidades e demais objetos de valor, cada caso de uso complementa o diagrama que representa a estrutura de dados do sistema.

Nível Intermediário

Tendo como base os diagramas gerados no alto nível, o arquiteto já é capaz de identificar as classes necessárias para atender ao caso de uso. Da mesma forma, também saberá quais componentes devem fazer parte disso.

Apenas são criados componentes para elementos da implementação que não tem uma classe como representação UML, tais como tabelas de banco, arquivos, etc. Interfaces realizadas por um componente também aparecem neste diagrama.

Baixo Nível

Tendo como base os diagramas gerados nos níveis alto e intermediário, o desenvolvedor deve representar cada fluxo dos casos de uso através de um diagrama de sequencia. Nesses diagramas ficará claro qual a interação entre as classes que atuam na colaboração do caso de uso.

Uso e Custo

BDD é uma técnica de desenvolvimento ágil de software que visa guiar a codificação e os testes a partir de aspectos comportamentais do sistema a ser desenvolvido. O JBehave é um dos frameworks que implementa esta técnica.

Vantagens

Envolve especialistas no negócio.

Estabelece uma linguagem comum para especificar e testar.

Padroniza o desenvolvimento dos testes.

Pré-requisitos

IDE de desenvolvimento: Eclipse (download) + Plugin para Maven, o m2e (download).

Projeto de Exemplo: baixe aqui o fonte do projeto usado como exemplo neste post.

Comportamento

Considerando a seguinte user story:

Como administrador, Quero cadastrar usuários Para mante-los atualizados.

Esta user story reflete uma funcionalidade CRUD para gerenciamento da entidade usuário, o que requer testes de validação e consulta.

Validação

Considerando os seguintes cenários:

Cenário: Usuário válido deve ser salvo. Dado um usuário A com e-mail [email protected] Quando A for salvo Então A deve ser persistido pelo repositório. Cenário: Usuário sem e-mail não deve ser salvo. Dado um usuário B sem e-mail Quando B for salvo Então a obrigatoriedade do e-mail deve impedir a operação. Cenário: Usuário com e-mail inválido não deve ser salvo. Dado um usuário C com e-mail foo Quando C for salvo Então a validade do e-mail deve impedir a operação.

Nos cenários acima, encontramos as seguintes classes:

Usuario: entidade.

UsuarioService: serviço de gerenciamento de usuários.

UsuarioRepository: repositório de usuários.

Antes de ser persistido por UsuarioRepository, Usuario é validado por UsuarioService. Somente após garantir a integridade da entidade é que sua persistência é delegada para UsuarioRepository. Para este teste a lógica de persistência será mockeada.

Os cenários Usuário válido deve ser salvo, Usuário sem e-mail não deve ser salvo e Usuário com e-mail inválido não deve ser salvo garantem que Usuario só é persistido após passar pela validação.

Consulta

Considerando o seguinte cenário:

Cenário: Consulta a usuários deve permitir filtro por nome. Dado os usuários: |email| |[email protected]| |[email protected]| |[email protected]| Quando consultar por foo Então deve retornar os usuários [email protected] e [email protected].

Usuário é a entidade a ser consultada, enquanto UsuarioService é a classe que valida sua integridade. UsuarioService também integra com UsuarioRepository, sendo o primeiro responsável apenas pela validação, e encapsulando e abstraindo o segundo, este que é responsável pela persistência.

O cenário Consulta a usuários deve permitir filtro por nome garante que a consulta retornará o resultado esperado pelo cenário. Ele armazena os dados num banco em memória que só existe durante a execução dos passos:

Concluindo

A integração contínua prega pela resposta rápida a mudanças, o que implica em implantar uma versão do sistema em tempo hábil. O manifesto ágil simpatiza com essa ideia. Com o Git temos um SCM que permite o versionamento, a recuperação de versões em um workspace e a implantação de uma release em produção.

Pré-requisitos

Git: usei a versão 1.7.5.4 no Ubuntu 11.10. Para trabalhar com o git no Windows, use o msysgit.

Repositório

No repositório não existem arquivos sendo criados, editados ou excluídos. Isso ocorre apenas no workspace. O repositório apenas versiona-os. Portanto, o repositório Git a ser criado deve ser bare:

mkdir myrepo.git cd myrepo.git git init --bare

A medida que o repositório recebe novas alterações de código, versões podem ser criadas para serem liberadas futuramente:

git tag 1.0.0.0

A versão 1.0.0.0 foi criada a partir do branch master.

Workspace

O workspace apenas cria, edita ou exclui arquivos. Não mantém um versionamento deles. Portanto, o repositório Git a ser criado pode clonar um repositório bare:

git clone myrepo.git myworkspace.git

Clonar o repositório cria o workspace com uma referência remota para o primeiro, chamada origin. No entanto, não é necessário clonar um repositório para criar um workspace:

mkdir myworkspace.git cd myworkspace.git git init git remote add origin myrepo.git

Para baixar uma determinada versão do sistema, e não o que se tem em linhas de desenvolvimento, é possível recuperar o código-fonte a partir de uma versão armazenada no repositório:

git fetch origin tag 1.0.0.0 git checkout 1.0.0.0

A medida que o desenvolvimento vai sendo concluído, o trabalho pode ser salvo no workspace:

git add . git commit -m "Entrega de valor xyz."

Ao término de um desenvolvimento, as mudanças podem ser enviadas para o repositório:

git push origin master

O desenvolvimento no branch master foi enviado para o repositório.

Implantação

Utilize o git ftp para implantar uma versão em produção. A implantação é feita a partir do workspace, portanto será implantada a versão disponível lá. Primeiro, configure um escopo:

git config git-ftp.prod.url my.domain.com/www git config git-ftp.prod.user root

Na primeira implantação deve-se iniciar o repositório distribuído:

git ftp init -s prod -p

Nas próximas o processo tende a ser mais rápido:

git ftp push -s prod -p

Backup