O SpecFlow é um framework que conecta analistas e desenvolvedores através de regras de negócios legíveis, facilitando o desenvolvimento orientado por comportamento (BDD) e testes de aceitação (ATDD). Ele permite descrever cenários de uso em diversos idiomas e integrar com ferramentas como Selenium e NUnit, proporcionando uma abordagem 'fora para dentro'. O objetivo é garantir que o software desenvolvido atenda aos critérios de aceitação estabelecidos, melhorando a comunicação entre equipes e a compreensão do negócio.

1. SpecFlow (Specification-By-Example)
Criando uma “ponte” entre analistas e os desenvolvedores
através de regras de negócios legíveis e de exemplos

2. SpecFlow é um framework inspirado no Cucumber , ou seja, podemos
descrever cenário reais de uso de forma estruturada. Também é
possível descrever nossos cenários em diversos idiomas.

3.  O SpecFlow é um Plug-In para o Visual Studio e um framework de execução de
Acceptance Teste Driver Development (ATDD)” Desenvolvimento Orientado a
Testes de Aceitação” e Behavior Driven Development (BDD) “Desenvolvimento
Guiado por Comportamento)”
 Ele pode ser integrado com Nunit, MSTest, xUnit.
 Não funciona sozinho, ele precisa de uma ferramenta que faça a interação com o
browser com o *Selenium

4.  SpecFlow tem por premissa criar uma “ponte” entre analistas e os
desenvolvedores através de regras de negócios legíveis e de exemplos.
 O objetivo é trabalhar de fora pra dentro, começando pela história.
 A missão do SpecFlow é fornecer uma abordagem sem atrito através da
especificação.
O que é SpecFlow?

5. O mais interessante de trabalhar com SpecFlow é a facilidade
que ele tem de chamar um cenário ou outro através de
frases, frases essas que são nada mais nada menos que os
próprios critérios de aceite de uma estória.
O que é SpecFlow?

6. ENTÃO...
 Por onde começar?
Outside-in (fora p/dentro)
 O que testar?
User Story (história do usuário)
 O que não testar?
O resto
O que é SpecFlow?

7. As empresas de desenvolvimento de software sofriam para aprovar com o cliente
quando um software ou mesmo uma funcionalidade estava completa e
principalmente se ela estava se comportando como deveria.
Nesse ponto a abordagem de User Stories implementa os critérios de aceite
(acceptance criteria ou acceptance testing) que é uma abordagem bem parecida
com o nosso teste tradicional usando test cases, ou seja, são escritos testes e
executados manualmente após a implementação de alguma feature.
Histórias de usuário

8. É aí onde serão definidos as nossas User Stories e o comportamento de nossa App.
Aí que está o poder do BDD: Descrever comportamentos em uma linguagem mais
alto nível e testar automaticamente para garantir que estamos desenvolvendo
corretamente.
Observe que isto possibilita ao desenvolvedor aumentar seu entendimento de
negócio da aplicação. Além de favorecer os testes de regressão feitos
posteriormente.
Histórias de usuário

9. Apesar das pessoas terem algum foco específico, porque estudaram mais uma
determinada área, todas elas são consideras desenvolvedores dentro de um time
Ágil, porque todos Desenvolvem Software, utilizando seu conhecimento.
Teste em par
Visão de Time ágil
Baseado no livro da Lisa Crispin – Agile Testing

10. Funcionalidade: <descrição da funcionalidade>
Como um <usuário/ator>
Eu quero <meta a ser alcançada>
De modo que <a razão para alcançar a meta>
Cenário: <descrição do teste>
Dado <um estado conhecido>
Quando <um determinado evento ocorre>
Então <isso deve ocorrer>
Estrutura do Specflow
 Funcionalidade: Formulário de Contato
 Eu como usuário
 Preciso contatar o prestador de serviço
 Para que seja necessário um possível retorno.
 Preenchimento do formulario corretamente
 que eu esteja no site jobmidia
 eu clicar no link contato e preencher o formulario
 o site ira informar a mensagem 'Sua mensagem foi
enviada com sucesso.'

11. Exemplo VISUAL STUDIO

12. Deu pra notar como isso pode facilitar os testes
funcionais em uma aplicação maior? É uma vantagem e
ganho de tempo enorme. Somando isso ao utilizar com
um servidor de integração contínua (TFS ou JENKINS),
sua aplicação está bem mais testável, além de mapear
pontos mais sensíveis a quebra do sistema.

13. DÚVIDAS

14. Obrigado!
Contatos:
franklin.araujo@doqconsulting.com.br
Facebook: @doqconsulting
Skype:faraujo52
Cod GitHub: https://github.com/nilknarf52/SpecFlow
Site SpecFlow : http://www.specflow.org/
BDD: http://pt.slideshare.net/CintiaArmesto/bdd-com-spec-flow
Lisa Crispin: http://lisacrispin.com/