DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou
Story - por Kamilla Queiróz
Será que er...
As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente
visto no domínio real, o qual pode ser ...
• Funcionalidade
• Contexto
• Cenário
• Dado
• Quando
• Então
• E
• Mas
• Esquema de cenário
• Exemplos
Desta forma os tes...
Vantagens
Para a Engenharia:
• é um teste que evita defeito, não que encontra defeitos;
• torna os testes como requisitos;...
Próximos SlideShares
Carregando em…5
×

DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou User Story

310 visualizações

Publicada em

Será que era possível criar uma documentação formal que pudesse servir de base para o desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que era possível ter documentações ou especificações vivas, ou seja, onde é ela mantida consistente com o código e é entregue como evidência de software funcionando ?

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
310
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou User Story

  1. 1. DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou Story - por Kamilla Queiróz Será que era possível criar uma documentação formal que pudesse servir de base para o desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que era possível ter documentações ou especificações vivas, ou seja, on consistente com o código e é entregue como evidência de software funcionando ? Introdução É possível pensarmos que ao invés de trabalharmos para criar e manter uma série de documentações estáticas e com custo de manutenção elevado, que gradualmente se tornará ultrapassado, podemos desenvolver espec entre conhecimento do negócio e a tecnologia, assim colaborando para que o foco do desenvolvimento se mantenha na entrega de valor Uma possível solução para essas questões, pode ser o uso de uma técnica cha nada mais é que uma técnica ágil de desenvolvimento, também conhecida como Specification By Example, que visa a integração entre regras de negócio com linguagem de programação, encorajando a colaboração entre as várias partes envolvidas em um projeto de desenvolvimento de software. BDD O Behaviour-Driven Development ainda sendo possível pensá- desenvolvimento orientado a testes desenvolvimento, sendo escrito primeiro o testes para somente depois o código conceitos do DDD, focando no comportamento do sistema somado a um desenvolvimento visando testes. DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou Será que era possível criar uma documentação formal que pudesse servir de base para o desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que era possível ter documentações ou especificações vivas, ou seja, onde é ela mantida consistente com o código e é entregue como evidência de software funcionando ? É possível pensarmos que ao invés de trabalharmos para criar e manter uma série de documentações estáticas e com custo de manutenção elevado, que gradualmente se tornará ultrapassado, podemos desenvolver especificações vivas, que aliam e diminuem a distância entre conhecimento do negócio e a tecnologia, assim colaborando para que o foco do desenvolvimento se mantenha na entrega de valor Uma possível solução para essas questões, pode ser o uso de uma técnica cha nada mais é que uma técnica ágil de desenvolvimento, também conhecida como , que visa a integração entre regras de negócio com linguagem de programação, encorajando a colaboração entre as várias partes envolvidas em um projeto de desenvolvimento de software. Fig #1 - como visto ficando a cargo do negócio definições de Features / Cenários / Passos/Etapas (steps) e para a tecnologia Definições para etapas (Step definitions) / Código / Biblioteca de automação Driven Development, tem seu foco no comportamento do software, também -lo como um aperfeiçoamento sendo a próxima milha para o desenvolvimento orientado a testes - uma vez que os testes ainda orientam o sendo escrito primeiro o testes para somente depois o código conceitos do DDD, focando no comportamento do sistema somado a um desenvolvimento DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou User Será que era possível criar uma documentação formal que pudesse servir de base para o desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que de é ela mantida consistente com o código e é entregue como evidência de software funcionando ? É possível pensarmos que ao invés de trabalharmos para criar e manter uma série de documentações estáticas e com custo de manutenção elevado, que gradualmente se tornará ificações vivas, que aliam e diminuem a distância entre conhecimento do negócio e a tecnologia, assim colaborando para que o foco do Uma possível solução para essas questões, pode ser o uso de uma técnica chamada BDD, que nada mais é que uma técnica ágil de desenvolvimento, também conhecida como , que visa a integração entre regras de negócio com linguagem de programação, encorajando a colaboração entre as várias partes envolvidas em um projeto de como visto ficando a cargo do negócio definições de Features / Cenários / Passos/Etapas (steps) e para a tecnologia Definições para etapas (Step definitions) / Código / Biblioteca de automação , tem seu foco no comportamento do software, também sendo a próxima milha para o uma vez que os testes ainda orientam o sendo escrito primeiro o testes para somente depois o código - com alguns conceitos do DDD, focando no comportamento do sistema somado a um desenvolvimento
  2. 2. As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para usuários de negócio. Assim o BDD se apoia no uso de um vocabulário pequeno e bem específico, nesse ponto sendo seu foco a linguagem e as interações usadas no proces “ruídos” na comunicação de forma que todos os interessados – estejam alinhados, apoiando todos os envolvidos e reduzindo riscos de desenvolvimento inadequado. A “venda da ideia” para BD por envolver mais gente, seja mais “trabalhoso” de implantar. Todo o desenvolvimento das especificações são baseadas em cenários, que utilizam a linguagem de negócio usada pelo próprio cliente e pode ser ex especificações fornecidas durante o procedimento de levantamento dos requisitos. Sendo que alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como cenários para os testes. Se lembrarmos de quando Dan North perceber a sugestão para que fosse seguido um padrão de escrita. Fig. #2 - Modelo sugerido por Dan North Dessa forma, a documentação que é produzida quando escrevemos especificações em BDD, dá aos leitores uma ideia de como o sistema irá se com simplesmente verificar se os métodos estão retornados os dados corretos, ou seja, o software é criado baseado em critérios de aceitação. Com isso, podemos atender as necessidades de ambos os envolvidos no projeto, técnicos aspectos do DDD com os conceitos fundamentais do TDD. BDD pode ser realizado utilizando frameworks de testes de unidade, ou com frameworks específicos de BDD que têm surgido em diversas linguagens. Um dos BDD, JBehave, foi criado por Dan North, seguido de um framework em Ruby chamado RBehave, no qual foi depois incorporado ao projeto Hellesoy, é um outro exemplo que pode ser usado para testar código Java, .NET e Flex. Utilizando o Cucumber, as funcionalidades do sistema são escritas em arquivos de texto e em uma linguagem de domínio específico chamada natural, mas que contém algumas palavras chaves que orientam sua sintaxe: As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para Assim o BDD se apoia no uso de um vocabulário pequeno e bem específico, nesse ponto sendo seu foco a linguagem e as interações usadas no processo de desenvolvimento, minimizando os “ruídos” na comunicação de forma que todos os interessados – tanto de TI, quanto do negócio estejam alinhados, apoiando todos os envolvidos e reduzindo riscos de desenvolvimento inadequado. A “venda da ideia” para BDD costuma ser mais fácil do que para TDD. Embora, por envolver mais gente, seja mais “trabalhoso” de implantar. Todo o desenvolvimento das especificações são baseadas em cenários, que utilizam a linguagem de negócio usada pelo próprio cliente e pode ser extraída das estórias ou especificações fornecidas durante o procedimento de levantamento dos requisitos. Sendo que alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como Dan North apresentou este conceito ainda em 2003, é possível perceber a sugestão para que fosse seguido um padrão de escrita. Modelo sugerido por Dan North - sendo esse apenas um modelo e não um formato obrigatório. Dessa forma, a documentação que é produzida quando escrevemos especificações em BDD, dá aos leitores uma ideia de como o sistema irá se comportar em vários cenários, e não simplesmente verificar se os métodos estão retornados os dados corretos, ou seja, o software é criado baseado em critérios de aceitação. Com isso, podemos atender as necessidades de ambos os envolvidos no projeto, técnicos ou especialistas no negócio, através da mistura dos aspectos do DDD com os conceitos fundamentais do TDD. BDD pode ser realizado utilizando frameworks de testes de unidade, ou com frameworks específicos de BDD que têm surgido em diversas linguagens. Um dos primeiros frameworks de , foi criado por Dan North, seguido de um framework em Ruby chamado , no qual foi depois incorporado ao projeto RSpec. O Cucumber, escrito por um outro exemplo que pode ser usado para testar código Java, .NET e Flex. Utilizando o Cucumber, as funcionalidades do sistema são escritas em arquivos de texto e em uma linguagem de domínio específico chamada Gherkin muito semelhante à linguagem natural, mas que contém algumas palavras chaves que orientam sua sintaxe: As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente como visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para Assim o BDD se apoia no uso de um vocabulário pequeno e bem específico, nesse ponto sendo so de desenvolvimento, minimizando os tanto de TI, quanto do negócio estejam alinhados, apoiando todos os envolvidos e reduzindo riscos de desenvolvimento D costuma ser mais fácil do que para TDD. Embora, Todo o desenvolvimento das especificações são baseadas em cenários, que utilizam a traída das estórias ou especificações fornecidas durante o procedimento de levantamento dos requisitos. Sendo que alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como apresentou este conceito ainda em 2003, é possível sendo esse apenas um modelo e não um formato obrigatório. Dessa forma, a documentação que é produzida quando escrevemos especificações em BDD, dá portar em vários cenários, e não simplesmente verificar se os métodos estão retornados os dados corretos, ou seja, o software é criado baseado em critérios de aceitação. Com isso, podemos atender as necessidades de ou especialistas no negócio, através da mistura dos BDD pode ser realizado utilizando frameworks de testes de unidade, ou com frameworks primeiros frameworks de , foi criado por Dan North, seguido de um framework em Ruby chamado , escrito por Aslak um outro exemplo que pode ser usado para testar código Java, .NET e Flex. Utilizando o Cucumber, as funcionalidades do sistema são escritas em arquivos de texto e em muito semelhante à linguagem
  3. 3. • Funcionalidade • Contexto • Cenário • Dado • Quando • Então • E • Mas • Esquema de cenário • Exemplos Desta forma os testes de BDD são compostos, basicamente funcionalidades - features e por arquivos de definição de passos funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio do sistema. As funcionalidades são descritas e armazenadas em arquivos com extensão descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conter diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se comportar em uma determinada situação. Devemos perceber que os cenários seguem sempre um padrão: 1. Colocam o sistema em um determinado estado; 2. Fazem alguma ação sobre o sistema (provocação); 3. Examinam o novo estado. Fig #3 - Exemplo de um arquivo de funcionalidade com fluxo simples de login. Dado que os cenários estão feitos, podemos agora criar uma ambiente de execução desses cenários e fazer o primeiro passo do TDD, ou seja, criar meu teste unitário e deixar ele "quebrando". Depois disso é hora da construção e implementação, onde para cada funcionalidade criada, um ou mais cenários sejam atendidos, ou seja, meus testes começam a funcionar. Conclusão Com isso, o BDD se torna uma evolução do TDD, saindo do ambiente somente de desenvolvimento, e chegando nas áreas de requisitos, teste e qualidad Desta forma os testes de BDD são compostos, basicamente, por arquivos que especificam as e por arquivos de definição de passos - steps . Os arquivos com as funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio scritas e armazenadas em arquivos com extensão .feature descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conter diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se inada situação. Devemos perceber que os cenários seguem sempre um padrão: Colocam o sistema em um determinado estado; Fazem alguma ação sobre o sistema (provocação); Examinam o novo estado. Exemplo de um arquivo de funcionalidade com fluxo simples de login. Dado que os cenários estão feitos, podemos agora criar uma ambiente de execução desses cenários e fazer o primeiro passo do TDD, ou seja, criar meu teste unitário e deixar ele "quebrando". Depois disso é hora da construção e implementação, onde para cada uncionalidade criada, um ou mais cenários sejam atendidos, ou seja, meus testes começam a Com isso, o BDD se torna uma evolução do TDD, saindo do ambiente somente de desenvolvimento, e chegando nas áreas de requisitos, teste e qualidade. , por arquivos que especificam as . Os arquivos com as funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio .feature. Cenários descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conter diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se Dado que os cenários estão feitos, podemos agora criar uma ambiente de execução desses cenários e fazer o primeiro passo do TDD, ou seja, criar meu teste unitário e deixar ele "quebrando". Depois disso é hora da construção e implementação, onde para cada uncionalidade criada, um ou mais cenários sejam atendidos, ou seja, meus testes começam a Com isso, o BDD se torna uma evolução do TDD, saindo do ambiente somente de
  4. 4. Vantagens Para a Engenharia: • é um teste que evita defeito, não que encontra defeitos; • torna os testes como requisitos; torna os testes mais elegantes; • torna os testes mais legíveis e sucintos; • torna os testes mais simples para pessoas de negócios; • consome menos tempo para escrever testes; • é uma documentação executável; • é tecnicamente um teste de unidade, integração ou sistema, mas com valor de teste de aceite; Para a Gestão: • pode ser usado como ferramenta para mensura o tamanho e progresso do projeto; • é uma documentação evolutiva; • é formado por critérios de aceite que representam o valor do produto e não valor de documentação; Desvantagens • é necessário uma boa abstração e uma visão sistêmica para criar os cenários; • é necessário um especialista de negócio para fazer a duas mãos os cenários; • refactoring é necessário e comum. • deve está aliado a um ambiente de integração contínua. Links Relacionados The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends Wikipedia: Behavior-driven development BDDWiki: BehaviourDrivenDevelopment Publicado originalmente em O Tapioca: http://www.otapioca.com.br/?p=2574

×