Jekyll2019-10-19T15:00:30+00:00https://dgosantos89.github.io/feed.xmlDiego SantosPágina pessoal utilizando o tema http://koppl.in/indigo/2019-10-18T16:20:00+00:002019-10-18T16:20:00+00:00https://dgosantos89.github.io/dolly1<p><img src="/assets/images/dolly1.png" alt="Dollly1" /></p>2019-10-18T16:20:00+00:002019-10-18T16:20:00+00:00https://dgosantos89.github.io/dolly2<p><img src="/assets/images/dolly2.png" alt="Dollly1" /></p>Como melhorar a comunicação usando BDD2019-02-20T16:20:00+00:002019-02-20T16:20:00+00:00https://dgosantos89.github.io/bdd<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>O que é mais difícil: Automatizar, escrever os cenários
ou entender o que o PO quer e elencar as regras de negócios
e os requisitos não funcionais?
</code></pre></div></div>
<h2 id="todos-temos-problemas-de-comunicação">Todos temos problemas de comunicação</h2>
<p>Você pode pensar que não, mas todos temos problemas de comunicação nos nossos times. Temos dificuldades de ver como um todo o que será construído, entender as necessidades de negócios que devem ser atendidas e do outro lado temos a área de negócios que não consegue entender os desafios técnicos que teremos na implementação.<br />
Isto é normal, já que times ágeis são multidisciplinares. Onde cada um tem um perfil, uma visão diferente do problema e de como atacá-lo, é normal que cada um interprete a história do seu jeito.</p>
<h3 id="os-três-amigos">Os três amigos</h3>
<p>PO - Quais problemas estamos tentando resolver?<br />
DEV - Como podemos construir uma solução para resolver?<br />
QE - O que poderia acontecer?</p>
<p>Uma forma de aproveitar ao máximo os diferentes perfis e alinhar o entendimento é a técnica <code class="highlighter-rouge">Os três amigos</code> (Story Kick Off huddles ou the Triad). Esta técnica consiste que todos os interessados sentem juntos e definam o que fazer e concordar sobre como elas sabem que isto foi feito corretamente.<br />
Ao final temos uma descrição mais clara, muitas vezes na forma de exemplos, levando ao entendimento compartilhado.</p>
<h2 id="alguém-já-passou-por-isso">Alguém já passou por isso</h2>
<p>Óbvio que um problema tão comum já foi analisado por vários especialistas e geraram várias soluções, como a técnica dos três amigos e a ideia de termos as especificações em forma de exemplos utilizando uma linguagem ubíqua (DDD - Domain Driven Design). Dan North se utilizou destas técnicas e mais algumas como TDD e ATDD para criar o BDD.</p>
<p>TDD - O código está correto e é fácil de ser testado? [Foco no design do código]</p>
<p>ATDD - O código faz o que é suposto que ele faça? [Foco em validar se foi entregue o que era suposto ser entregue]</p>
<p>BDD é a evolução destes dois trazendo o foco para a comunicação.<br />
A principal diferença entre BDD e TDD é que no BDD estamos em um nível de abstração mais alto, mais próximo do domínio e mais distante dos métodos.</p>
<h3 id="origem">Origem</h3>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>2003 - Agiledox
Ferramenta que gera documentação técnica automaticamente
a partir de testes JUnit
2004 - JBehave
Ferramenta para testar comportamentos
2006 - Formado given-when-then
O formato Dado-Quando-Então é finalmente documentado
no post "Introducing BDD" de Dan North
</code></pre></div></div>
<h3 id="definição">Definição</h3>
<p>BDD é uma abordagem que faz com que um time desenvolva software falando uma mesma língua, entregando valor para o cliente, se utilizando de cenários e por consequência automatizando testes.<br />
Ou seja BDD não é só escrever cenários ou só automação de testes, BDD é isso e mais um pouco.<br />
O objetivo do BDD é descobrir mal entendidos e descobri-los cedo!</p>
<hr />
<h2 id="como-melhorar-a-comunicação-do-time-com-bdd">Como melhorar a comunicação do time com BDD?</h2>
<h3 id="benefícios-do-bdd">Benefícios do BDD</h3>
<p>Deixa claro a todos o que deve ser feito, antes de ser feito;<br />
Expõe o tamanho e a complexidade da história com base no número de cenários que escrevemos;<br />
Garante uma documentação viva;<br />
Torna as especificações executáveis;<br />
Traz empatia a todos os envolvidos;</p>
<h3 id="como">Como?</h3>
<p>BDD se apoia no uso de um vocabulário pequeno, minimizando ruídos na comunicação de forma que todos os envolvidos falem a mesma linguagem.</p>
<h4 id="gherkin">Gherkin</h4>
<p>A cada dia vemos novas linguagens surgindo buscando alcançar uma linguagem mais natural, mas isto não é uma novidade. Na verdade o próprio COBOL (sigla de COmmon Business Oriented Language) [Linguagem Comum Orientada para os Negócios] foi criado com este intuito.
No BDD usamos a linguagem Gherkin, uma linguagem realmente ubíqua, para descrever as história utilizando exemplos.</p>
<pre><code class="language-Gherkin"> Dado que <pré-condições para que ocorram a ação do interesse do cenário>
Quando <eventos que devem ocorrer para que o cenário seja executado>
Então <expectativas a respeito dos resultados em função da execução dos eventos do cenário>
</code></pre>
<h2 id="erros-comuns-no-uso-do-bdd">Erros Comuns no uso do BDD</h2>
<ul>
<li>
<p>O PO deve escrever os cenários<br />
Alguns times acreditam que somente o PO deve escrever os cenários e as descrições das histórias. Todos podem escrever os cenários, aliás é uma tarefa que devemos fazer juntos.</p>
</li>
<li>
<p>Não transforme tudo em testes<br />
A regra segue a mesma pra qualquer outra técnica de testes, utilize quando necessário.</p>
</li>
<li>
<p>Evite detalhes de implementação, foque no “QUE” e não no “COMO”<br />
Nos cenários evite detalhes técnicos, busque manter sempre um alto nível de abstração. Afinal estes cenários também são uma documentação não técnica, então tente sempre escrever cenários que qualquer pessoa que não esteja familiarizada com o seu produto consiga entender as regras de negócio atreladas.</p>
</li>
</ul>
<p><code class="highlighter-rouge">Your cucumber features should drive your implementation, not reflect it</code></p>
<h2 id="conclusão">Conclusão</h2>
<p>Com as especificações escritas, você deve automatizá-las para ter o feedback imediato sobre o que ainda falta ser feito para atender aos requisitos e o que está com defeito, iniciando assim o fluxo de <code class="highlighter-rouge">Red, Green, Refactor</code> igual ao TDD, mas desta vez focando nos comportamentos escritos em conjunto com todos os stakeholders. Ao final temos uma documentação executável que prova que todos os critérios foram atendidos e funcionam.</p>
<h3 id="fontes">Fontes:</h3>
<p><a href="http://broncodev.com/2016-10-11-introduzindo-o-bdd/">Introducing BDD - Tradução do artigo original do Dan North</a><br />
<a href="https://www.agilealliance.org/glossary/bdd/">BDD - Glossário Agile Aliance</a><br />
<a href="https://www.agilealliance.org/glossary/three-amigos/">Three amigos - Glossário Agile Aliance</a><br />
<a href="https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/">ATDD vs BDD</a></p>O que é mais difícil: Automatizar, escrever os cenários ou entender o que o PO quer e elencar as regras de negócios e os requisitos não funcionais? Todos temos problemas de comunicação Você pode pensar que não, mas todos temos problemas de comunicação nos nossos times. Temos dificuldades de ver como um todo o que será construído, entender as necessidades de negócios que devem ser atendidas e do outro lado temos a área de negócios que não consegue entender os desafios técnicos que teremos na implementação. Isto é normal, já que times ágeis são multidisciplinares. Onde cada um tem um perfil, uma visão diferente do problema e de como atacá-lo, é normal que cada um interprete a história do seu jeito. Os três amigos PO - Quais problemas estamos tentando resolver? DEV - Como podemos construir uma solução para resolver? QE - O que poderia acontecer? Uma forma de aproveitar ao máximo os diferentes perfis e alinhar o entendimento é a técnica Os três amigos (Story Kick Off huddles ou the Triad). Esta técnica consiste que todos os interessados sentem juntos e definam o que fazer e concordar sobre como elas sabem que isto foi feito corretamente. Ao final temos uma descrição mais clara, muitas vezes na forma de exemplos, levando ao entendimento compartilhado. Alguém já passou por isso Óbvio que um problema tão comum já foi analisado por vários especialistas e geraram várias soluções, como a técnica dos três amigos e a ideia de termos as especificações em forma de exemplos utilizando uma linguagem ubíqua (DDD - Domain Driven Design). Dan North se utilizou destas técnicas e mais algumas como TDD e ATDD para criar o BDD. TDD - O código está correto e é fácil de ser testado? [Foco no design do código] ATDD - O código faz o que é suposto que ele faça? [Foco em validar se foi entregue o que era suposto ser entregue] BDD é a evolução destes dois trazendo o foco para a comunicação. A principal diferença entre BDD e TDD é que no BDD estamos em um nível de abstração mais alto, mais próximo do domínio e mais distante dos métodos. Origem 2003 - Agiledox Ferramenta que gera documentação técnica automaticamente a partir de testes JUnit 2004 - JBehave Ferramenta para testar comportamentos 2006 - Formado given-when-then O formato Dado-Quando-Então é finalmente documentado no post "Introducing BDD" de Dan North Definição BDD é uma abordagem que faz com que um time desenvolva software falando uma mesma língua, entregando valor para o cliente, se utilizando de cenários e por consequência automatizando testes. Ou seja BDD não é só escrever cenários ou só automação de testes, BDD é isso e mais um pouco. O objetivo do BDD é descobrir mal entendidos e descobri-los cedo! Como melhorar a comunicação do time com BDD? Benefícios do BDD Deixa claro a todos o que deve ser feito, antes de ser feito; Expõe o tamanho e a complexidade da história com base no número de cenários que escrevemos; Garante uma documentação viva; Torna as especificações executáveis; Traz empatia a todos os envolvidos; Como? BDD se apoia no uso de um vocabulário pequeno, minimizando ruídos na comunicação de forma que todos os envolvidos falem a mesma linguagem. Gherkin A cada dia vemos novas linguagens surgindo buscando alcançar uma linguagem mais natural, mas isto não é uma novidade. Na verdade o próprio COBOL (sigla de COmmon Business Oriented Language) [Linguagem Comum Orientada para os Negócios] foi criado com este intuito. No BDD usamos a linguagem Gherkin, uma linguagem realmente ubíqua, para descrever as história utilizando exemplos. Dado que <pré-condições para que ocorram a ação do interesse do cenário> Quando <eventos que devem ocorrer para que o cenário seja executado> Então <expectativas a respeito dos resultados em função da execução dos eventos do cenário> Erros Comuns no uso do BDD O PO deve escrever os cenários Alguns times acreditam que somente o PO deve escrever os cenários e as descrições das histórias. Todos podem escrever os cenários, aliás é uma tarefa que devemos fazer juntos. Não transforme tudo em testes A regra segue a mesma pra qualquer outra técnica de testes, utilize quando necessário. Evite detalhes de implementação, foque no “QUE” e não no “COMO” Nos cenários evite detalhes técnicos, busque manter sempre um alto nível de abstração. Afinal estes cenários também são uma documentação não técnica, então tente sempre escrever cenários que qualquer pessoa que não esteja familiarizada com o seu produto consiga entender as regras de negócio atreladas. Your cucumber features should drive your implementation, not reflect it Conclusão Com as especificações escritas, você deve automatizá-las para ter o feedback imediato sobre o que ainda falta ser feito para atender aos requisitos e o que está com defeito, iniciando assim o fluxo de Red, Green, Refactor igual ao TDD, mas desta vez focando nos comportamentos escritos em conjunto com todos os stakeholders. Ao final temos uma documentação executável que prova que todos os critérios foram atendidos e funcionam. Fontes: Introducing BDD - Tradução do artigo original do Dan North BDD - Glossário Agile Aliance Three amigos - Glossário Agile Aliance ATDD vs BDDUsando todo o poder do Gherkin 2/22017-02-15T16:20:00+00:002017-02-15T16:20:00+00:00https://dgosantos89.github.io/Gherkin-p2<p><img src="http://kplod.com/wp-content/uploads/2016/04/pepinillos-300x131.png" alt="Gherkin" /></p>
<p>No primeiro post entendemos oque é o Gherkin, porque ele foi criado e o básico para você sair escrevendo seus arquivos <code class="highlighter-rouge">*.feature</code>.
Nest post você verá algumas outras armas do Gherkin que tornarão o seu desenvolvimento mais produtivo e eficiente.
Estas dicas são super simples, mas é difícil verem elas em uso, pois a maioria das pessoas desconhece ou tem preguiça de utilizá-las. Vamos a elas!</p>
<h1 id="contexto">Contexto</h1>
<p>Algumas vezes, para testar uma funcionalidade você precisará repetir uma coleção de steps antes de cada cenário. Vamos supor que em todos os seus cenários você precisará cadastrar um usuário e sabemos que não será muito eficiente ficar duplicando estas steps em todos os cenários, então podemos utilizar o Contexto para executar um conjunto de steps antes de cada cenário.</p>
<p>Exemplo:</p>
<pre><code class="language-Gherkin">Contexto:
Dado que eu esteja deslogado na página inicial
Cenário: Usuário deslogado tenta publicar no blog
Quando eu tentar postar em "Terapia Cara"
Então eu devo ver "Você deverá se logar para publicar"
Cenário: Wilson posta em seu próprio blog
Dado que eu realize o login como Wilson
Quando eu tentar postar em "Terapia Cara"
Então eu devo ver "Seu artigo foi publicado."
</code></pre>
<p>Neste exemplo seria como se o <code class="highlighter-rouge">Dado</code> fosse a primeira step de cada Cenário, ele será executado antes de cada Cenário.</p>
<h1 id="esquema-do-cenário">Esquema do Cenário</h1>
<p>Copiar e colar cenários inteiros somente para usar diferentes valores pode ser muito tedioso, repetitivo e ineficiente e é por isso que temos os <code class="highlighter-rouge">Esquemas do Cenário</code>, com ele podemos escrever o cenário apenas uma vez e informar as diferentes <code class="highlighter-rouge">massas</code> que queremos para reutilizá-lo.</p>
<p>O Esquema do Cenário utiliza espaços reservados, que estão contidos entre <code class="highlighter-rouge">< ></code> nas steps do Cenário.
Pense em um espaço reservado como uma variável, que receberá um valor das linhas da tabela de <code class="highlighter-rouge">Exemplos:</code>, onde o texto entre os <code class="highlighter-rouge">< ></code> corresponde ao cabeçalho da coluna da tabela de exemplos. O valor muda a cada execução subsequente do Esquema do Cenário, até que o fim da tabela seja alcançado.
Ou seja, o código abaixo será executado duas vezes, sendo que na primeira execução utilizará os valores da primeira linha e na próxima execução serão utilizados os valores da segunda linha.</p>
<pre><code class="language-Gherkin">Esquema do Cenário: Comendo
Dado que tenho <antes> pepinos
Quando eu comer <come> pepinos
Então eu devo ter <depois> pepinos
Exemplos:
| antes | come | depois |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
Então na primeira execução, o que realmente será executado é:
Cenário: Comer
Dado que temos 12 pepinos
Quando eu comer 5 pepino
Então teremos 7 pepinos
</code></pre>
<h1 id="argumentos-multilineos">Argumentos Multilineos</h1>
<p>Até agora vimos steps de linha única, mas há momentos em que você quer passar uma estrutura de dados mais rica para uma step. Para isto que existem os Argumentos Multilineos, que podem ser escritos de dois modos: <code class="highlighter-rouge">Tabelas</code> ou <code class="highlighter-rouge">Pystrings</code>.</p>
<h2 id="tabelas">Tabelas</h2>
<p>As tabelas são úteis para a especificação de um grande conjunto de dados - normalmente como entrada para uma saída de <code class="highlighter-rouge">Dado</code> ou como uma espera de um <code class="highlighter-rouge">Então</code>.</p>
<pre><code class="language-Gherkin">Cenário:
Dado que as seguintes pessoas existem:
| nome | email | fone |
| Diego | diego@email.com | 123 |
| Santos | santos@email.com | 234 |
| Machado | machado@email.org | 456 |
</code></pre>
<h2 id="pystrings">Pystrings</h2>
<p>São strings multineas utilizadas para a especificação de um grande pedaço de texto. O texto deve ser fechado por delimitadores que consistem em três marcas de aspas duplas colocadas em linha <code class="highlighter-rouge">"""</code></p>
<pre><code class="language-Gherkin">Cenário:
Dado uma postagem em um blog chamado "Random" com:
"""
Algum título, Eh?
=================
Aqui está o primeiro parágrafo do meu post.
Lorem ipsum dolor sit amet, consectetur adipiscing
elit.
"""
</code></pre>
<h1 id="tags">Tags</h1>
<p>Você pode usar tags para agrupar Funcionalidades e Cenários, independente da estrutura do seu arquivo e diretório, elas são uma ótima forma de organizar as suas funcionalidades e cenários.<br />
Um Cenário ou Funcionalidade pode ter quantas tags você quiser, basta apenas separá-los com espaços:</p>
<pre><code class="language-Gherkin">@faturamento @brigar @incomodar
Funcionalidade: Verificar o faturamento
@ci
Cenário: Falta da descrição do produto
</code></pre>No primeiro post entendemos oque é o Gherkin, porque ele foi criado e o básico para você sair escrevendo seus arquivos *.feature. Nest post você verá algumas outras armas do Gherkin que tornarão o seu desenvolvimento mais produtivo e eficiente. Estas dicas são super simples, mas é difícil verem elas em uso, pois a maioria das pessoas desconhece ou tem preguiça de utilizá-las. Vamos a elas! Contexto Algumas vezes, para testar uma funcionalidade você precisará repetir uma coleção de steps antes de cada cenário. Vamos supor que em todos os seus cenários você precisará cadastrar um usuário e sabemos que não será muito eficiente ficar duplicando estas steps em todos os cenários, então podemos utilizar o Contexto para executar um conjunto de steps antes de cada cenário. Exemplo: ```Gherkin Contexto: Dado que eu esteja deslogado na página inicialUsando todo o poder do Gherkin 1/22017-02-13T16:20:00+00:002017-02-13T16:20:00+00:00https://dgosantos89.github.io/Gherkin-p1<p><img src="http://kplod.com/wp-content/uploads/2016/04/pepinillos-300x131.png" alt="Gherkin" /></p>
<p>Vez por outra vejo pessoas empolgadas, falando sobre o surgimento de linguagens com sintaxe tão natural que em breve qualquer pessoa poderá programar sem dificuldades.<br />
Essas pessoas estão certas, realmente existem diversas linguagens surgindo com este intuito, mas oque você provavelmente não sabe é que esta não é uma ideia nova, o próprio COBOL (COmmon Business Oriented Language) foi criado com este intuito e você sabe oque aconteceu depois.</p>
<p>Aqui falaremos sobre uma linguagem que vem sendo amplamente utilizada no intuito de tornar mais fácil a comunicação entre os desenvolvedores, a área de negócios e outras partes interessadas, uma linguagem tão natural que qualquer um destes pode entender e até mesmo escrever, a Gherkin.</p>
<p>Gherkin é uma Business Readable, Domain Specific Language criada especificamente para a descrição de comportamentos, com a habilidade de remover detalhes lógicos dos testes, que serve como documentação do projeto e para automação de testes, usando uma linguagem verdadeira e humana que lhe diz o código que você deve escrever.</p>
<p>Neste primeiro post entenderemos melhor a sua estrutura básica e a melhor forma de a utilizarmos e no próximo post teremos alguns detalhes mais avançados que dificilmente você viu sendo aplicado por ai.</p>
<h1 id="sintaxe-gherkin">Sintaxe Gherkin</h1>
<p>Assim como YAML e o Python, Gherkin é uma linguagem orientada a espaços, ela usa indentação para definir a estrutura. Os fins de linha encerram as declarações (denominados steps) e espaços ou tabs também podem ser usados para indentação (sendo que o indicado é você usar espaços para obter uma melhor portabilidade).</p>
<p>Vamos analisar o exemplo abaixo:</p>
<pre><code class="language-Gherkin"># language: pt
Funcionalidade: Algum texto descritivo conciso do que é desejado
A fim de realizar um valor de negócio
Como ator explicito do sistema
Eu quero ganhar algum resultado benéfico que promova a meta
Texto adicional...
Cenário: Uma determinada situação de negócios
Dado uma pré condição
E uma outra pré condição
Quando uma ação é feita pelo ator
E uma outra ação
E outra ação diferente
Então um resultado testável é alcançado
E outra coisa que possamos verificar também acontece
Cenário: Uma situação diferente
...
</code></pre>
<p>No código, a primeira linha que vemos é um comentário. Sim, na sintaxe do Gherkin <code class="highlighter-rouge">#</code> é utilizado para comentar, mas este é um comentário especial.
O Gherkin está disponível em muitas linguas, permitindo você escrever histórias usando palavras chave de sua lingua nativa.
Em outras palavras, se você fala Francês, você pode usar a palavra <code class="highlighter-rouge">Fonctionnalité</code> ao invés de <code class="highlighter-rouge">Funcionalidade</code>.
Então nunca se esqueça de explicitar a língua utilizada no início do seu arquivo *.feature.</p>
<p>No demais, o código é dividido em três partes: <code class="highlighter-rouge">Funcionalidades</code>, <code class="highlighter-rouge">Cenários</code> e <code class="highlighter-rouge">Steps</code>.</p>
<pre><code class="language-Gherkin">Funcionalidade: Algum texto descritivo conciso do que é desejado.
</code></pre>
<p>Inicia a feature e lhe dá um título.<br />
Seguido por três linhas (A fim de… Como um… Eu quero…).</p>
<pre><code class="language-Gherkin">Cenário: Uma determinada situação de negócios
</code></pre>
<p>Contém uma descrição do cenário.<br />
As próximas 7 linhas são as chamadas steps do cenário.</p>
<pre><code class="language-Gherkin">Cenário: Uma situação diferente`
</code></pre>
<p>Inicia o próximo cenário.</p>
<p>Agora vamos ver os detalhes de cada uma destas partes:</p>
<h1 id="funcionalidades">Funcionalidades</h1>
<p>Os arquivos *.feature convencionalmente consistem em uma funcionalidade única.<br />
Linhas iniciando com a palavra chave <code class="highlighter-rouge">Funcionalidade:</code> seguida por três linhas indentadas iniciam uma funcionalidade.<br />
Você pode escrever qualquer coisa que você precise até o primeiro Cenário.</p>
<h1 id="cenário">Cenário</h1>
<p>Cenários são uma das principais estruturas do Gherkin. Todo cenário deve iniciar com a palavra chave <code class="highlighter-rouge">Cenário:</code>, opcionalmente seguido de um título.<br />
Cada funcionalidade pode ter um ou mais cenários e todo cenário é formado por uma ou mais <code class="highlighter-rouge">steps</code>.</p>
<h1 id="steps">Steps</h1>
<p>Funcionalidades consistem em steps, também conhecidas como <code class="highlighter-rouge">Dado</code>, <code class="highlighter-rouge">Quando</code> e <code class="highlighter-rouge">Então</code> que também podemos interpretar estas palavras-chave como uma máquina de estados finitos</p>
<h1 id="dado">Dado</h1>
<p>O propósito da step <code class="highlighter-rouge">Dado</code> é colocar o sistema em um estado conhecido antes de iniciarmos a interação com o sistema.<br />
Evite falar sobre interações em <code class="highlighter-rouge">Dado</code>, pense nele como uma pré condição em casos de uso.</p>
<p>Exemplos de <code class="highlighter-rouge">Dado</code></p>
<p>Dois bons exemplos do uso de <code class="highlighter-rouge">Dado</code> são:</p>
<ul>
<li>Para criar registros (instâncias de modelo) ou de configuração do banco de dados:</li>
</ul>
<pre><code class="language-Gherkin"> Dado que não tenha usuários no site
Dado que o banco de dados esteja limpo
</code></pre>
<ul>
<li>Autenticar um usuário (uma exceção a recomendação de não-interação coisas que “aconteceram antes” estão ok):</li>
</ul>
<pre><code class="language-Gherkin"> Dado que eu esteja logado como "Diego"
</code></pre>
<h1 id="quando">Quando</h1>
<p>O propósito da step <code class="highlighter-rouge">Quando</code> é descrever a ação que o usuário executa, ou pensando em uma máquina de estados, a transição de estado.</p>
<p>Exemplos de <code class="highlighter-rouge">Quando</code>:</p>
<ul>
<li>Interagir com uma página web:</li>
</ul>
<pre><code class="language-Gherkin"> Quando eu estiver em "/alguma/pagina"
Quando eu preencho o campo "username" com "diegosantos"
</code></pre>
<h1 id="então">Então</h1>
<p>O propósito da step <code class="highlighter-rouge">Então</code> é observar saídas. As observações devem estar relacionadas com o valor/benefício de negócio na sua descrição da funcionalidade.<br />
As observações devem inspecionar a saída do sitema e não alguma oculta dela, que não tenha valor de negócios.</p>
<p>Dois bons exemplos do uso de <code class="highlighter-rouge">Então</code> são:</p>
<ul>
<li>Verificar algo relacionado ao Dado + Quando está (ou não) na saída:</li>
</ul>
<pre><code class="language-Gherkin"> Quando eu chamo "echo hello"
Então a saída deve ser "hello"
</code></pre>
<ul>
<li>Checar se algum sistema externo recebeu a mensagem esperada:</li>
</ul>
<pre><code class="language-Gherkin"> Quando eu enviar um email com:
"""
...
"""
Então o cliente deve receber um email com:
"""
...
"""
</code></pre>
<h1 id="e-mas">E, Mas</h1>
<p>Se você tem várias steps <code class="highlighter-rouge">Dado</code>, <code class="highlighter-rouge">Quando</code> ou <code class="highlighter-rouge">Então</code> você pode repetir:</p>
<pre><code class="language-Gherkin">Cenário: Múltiplos Dado
Dado uma coisa
Dado outra coisa
Dado mais outra coisa
Quando eu abrir meus olhos
Então eu verei qualquer coisa
Então eu não verei qualquer outra coisa
</code></pre>
<p>Ou você pode usar steps <code class="highlighter-rouge">E</code> ou <code class="highlighter-rouge">Mas</code>, permitindo uma leitura mais natural do seu Cenário:</p>
<pre><code class="language-Gherkin"> Cenário: Múltiplos Dado
Dado uma coisa
E outra coisa
E mais outra coisa
Quando eu abrir meus olhos
Então eu verei qualquer coisa
Mas eu não verei qualquer outra coisa
</code></pre>Vez por outra vejo pessoas empolgadas, falando sobre o surgimento de linguagens com sintaxe tão natural que em breve qualquer pessoa poderá programar sem dificuldades. Essas pessoas estão certas, realmente existem diversas linguagens surgindo com este intuito, mas oque você provavelmente não sabe é que esta não é uma ideia nova, o próprio COBOL (COmmon Business Oriented Language) foi criado com este intuito e você sabe oque aconteceu depois.Aplicação com um Navegador incorporado2016-10-26T16:20:00+00:002016-10-26T16:20:00+00:00https://dgosantos89.github.io/navegador-incorporado<p><img src="http://i66.tinypic.com/k0pbp.jpg" alt="App" /></p>
<h1 id="como-automatizá-la">Como automatizá-la?</h1>
<p>Recentemente me deparei com um objeto de navegador incorporado em uma aplicação desktop, como no exemplo acima, onde temos um navegador incorporado em uma planilha excel.<br />
Eu era capaz apenas de identificá-lo como um WinObject <code class="highlighter-rouge">navegador</code>,<br />
então não era possível acessar o conteúdo dentro desta página.</p>
<p>Pesquisando sobre o assunto descobri que o UFT não identifica objetos Web se estes objetos estiverem em uma aplicação não Web.<br />
Foi então que encontrei uma solução utilizando a Register New Browser Control.<br />
Esta ferramenta permite a navegação, visualização de documentos<br />
e outras funcionalidades de navegador em um aplicativo não Web.</p>
<p>Antes de mais nada, encerre o UFT e em seguida abra a ferramenta Register New Browser Control.<br />
Para abrir o Register New Browser Control, vá em:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> Iniciar >
Todos os Programas >
HP Software >
HP Unified Functional Testing >
Tools >
Register New Browser Control.
</code></pre></div></div>
<p>Nesta janela insira o arquivo .exe da sua aplicação e clique em Registrar.</p>
<p>Obs: Caso você queira especificar a aplicação localizada em um diretório<br />
você pode adicionar o caminho absoluto até o executável da aplicação,<br />
caso contrário o UFT reconhecerá todos os executáveis com o nome que você adicionou.</p>
<ul>
<li>Para remover uma aplicação registrada, entre com o caminho absoluto e clique em Cancelar Registro.</li>
</ul>
<p>Esta ferramenta é basicamente uma interface amigável que realiza uma alteração no arquivo mic.ini<br />
(contém as configurações padrão do UFT).<br />
Então caso você não tenha esta ferramenta à disposição, você pode alterar diretamente o arquivo mic.ini: <br />
Este arquivo pode ser encontrado em:<br />
<code class="highlighter-rouge">C:\Program Files (x86)\HP\Unified Functional Testing\bin\</code></p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> 1) Localize o arquivo mic.ini e edite utilizando o Notepad.
2) Procure pela seção [ie_hook]
3) Ao final da seção adicione o nome do executável da aplicação (ou seu caminho absoluto) e a defina como YES:
[ie_hook]
name=ie_hooks.dll
method=specific
explorer.exe=yes
iexplore.exe=yes
ie4.exe=yes
APLICAÇÃO.exe=yes
</code></pre></div></div>Como automatizá-la? Recentemente me deparei com um objeto de navegador incorporado em uma aplicação desktop, como no exemplo acima, onde temos um navegador incorporado em uma planilha excel. Eu era capaz apenas de identificá-lo como um WinObject navegador, então não era possível acessar o conteúdo dentro desta página. Pesquisando sobre o assunto descobri que o UFT não identifica objetos Web se estes objetos estiverem em uma aplicação não Web. Foi então que encontrei uma solução utilizando a Register New Browser Control. Esta ferramenta permite a navegação, visualização de documentos e outras funcionalidades de navegador em um aplicativo não Web. Antes de mais nada, encerre o UFT e em seguida abra a ferramenta Register New Browser Control. Para abrir o Register New Browser Control, vá em: Iniciar > Todos os Programas > HP Software > HP Unified Functional Testing > Tools > Register New Browser Control. Nesta janela insira o arquivo .exe da sua aplicação e clique em Registrar. Obs: Caso você queira especificar a aplicação localizada em um diretório você pode adicionar o caminho absoluto até o executável da aplicação, caso contrário o UFT reconhecerá todos os executáveis com o nome que você adicionou. Para remover uma aplicação registrada, entre com o caminho absoluto e clique em Cancelar Registro. Esta ferramenta é basicamente uma interface amigável que realiza uma alteração no arquivo mic.ini (contém as configurações padrão do UFT). Então caso você não tenha esta ferramenta à disposição, você pode alterar diretamente o arquivo mic.ini: Este arquivo pode ser encontrado em: C:\Program Files (x86)\HP\Unified Functional Testing\bin\ 1) Localize o arquivo mic.ini e edite utilizando o Notepad. 2) Procure pela seção [ie_hook] 3) Ao final da seção adicione o nome do executável da aplicação (ou seu caminho absoluto) e a defina como YES: [ie_hook] name=ie_hooks.dll method=specific explorer.exe=yes iexplore.exe=yes ie4.exe=yes APLICAÇÃO.exe=yesExemplo de teste de APIs2016-09-23T16:20:00+00:002016-09-23T16:20:00+00:00https://dgosantos89.github.io/exemplo-teste-api<h1 id="exemplo-de-teste-de-apis">Exemplo de teste de APIs</h1>
<p>Este é um exemplo de teste automatizado de uma API utilizando frameworks PHP.
Para este exemplo iremos utilizar a API pública <a href="http://postmon.com.br/">Postmon</a>, que dado um determinado CEP ela retorna as suas informações. O modelo da chamada é o seguinte:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>GET - http://api.postmon.com.br/v1/cep/01001001
</code></pre></div></div>
<p>Resposta:</p>
<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"complemento"</span><span class="p">:</span><span class="w"> </span><span class="s2">"lado par"</span><span class="p">,</span><span class="w">
</span><span class="nl">"bairro"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Sé"</span><span class="p">,</span><span class="w">
</span><span class="nl">"cidade"</span><span class="p">:</span><span class="w"> </span><span class="s2">"São Paulo"</span><span class="p">,</span><span class="w">
</span><span class="nl">"logradouro"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Praça da Sé"</span><span class="p">,</span><span class="w">
</span><span class="nl">"estado_info"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"area_km2"</span><span class="p">:</span><span class="w"> </span><span class="s2">"248.222,362"</span><span class="p">,</span><span class="w">
</span><span class="nl">"codigo_ibge"</span><span class="p">:</span><span class="w"> </span><span class="s2">"35"</span><span class="p">,</span><span class="w">
</span><span class="nl">"nome"</span><span class="p">:</span><span class="w"> </span><span class="s2">"São Paulo"</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nl">"cep"</span><span class="p">:</span><span class="w"> </span><span class="s2">"01001001"</span><span class="p">,</span><span class="w">
</span><span class="nl">"cidade_info"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"area_km2"</span><span class="p">:</span><span class="w"> </span><span class="s2">"1521,11"</span><span class="p">,</span><span class="w">
</span><span class="nl">"codigo_ibge"</span><span class="p">:</span><span class="w"> </span><span class="s2">"3550308"</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nl">"estado"</span><span class="p">:</span><span class="w"> </span><span class="s2">"SP"</span><span class="w">
</span><span class="p">}</span><span class="w">
</span></code></pre></div></div>
<p>Para este teste escrevi a seguinte <a href="https://raw.githubusercontent.com/dgosantos89/qa-walmart-php/master/features/SegundoExercicio.feature">Feature</a></p>
<p>E para esta feature desenvolvi esta <a href="https://raw.githubusercontent.com/dgosantos89/qa-walmart-php/master/features/bootstrap/SegundoExercicioContext.php">Context</a></p>Exemplo de teste de APIsExemplo utilizando Behat e Mink2016-09-21T16:20:00+00:002016-09-21T16:20:00+00:00https://dgosantos89.github.io/exemplo-utilizando-behat-mink<h1 id="exemplo-de-teste-utilizando-behat-e-mink">Exemplo de teste utilizando Behat e Mink</h1>
<p>Este é um exemplo de teste automatizado utilizando o Behat e o Mink.
Este exemplo foi retirado da prova para a vaga de QA do Walmart.com.</p>
<h2 id="no-site-vamos-validar-a-seguinte-sequência-de-ações">No site vamos validar a seguinte sequência de ações:</h2>
<ul>
<li>Procurar pelo termo “tv” na busca</li>
<li>Validar que a busca teve resultados</li>
<li>Clicar em um dos resultados e validar que a página do produto abriu corretamente</li>
<li>Adicionar o Produto ao carrinho</li>
<li>Abrir o carrinho e validar que o mesmo foi adicionado com sucesso</li>
</ul>
<p>Para este teste escrevi a seguinte <a href="https://raw.githubusercontent.com/dgosantos89/qa-walmart-php/master/features/PrimeiroExercicio.feature">Feature</a></p>
<p>E para esta feature desenvolvi esta <a href="https://raw.githubusercontent.com/dgosantos89/qa-walmart-php/master/features/bootstrap/PrimeiroExercicioContext.php">Context</a></p>Exemplo de teste utilizando Behat e MinkDocumentação do Mink2016-08-13T19:00:00+00:002016-08-13T19:00:00+00:00https://dgosantos89.github.io/documentacao-mink<p><img src="https://s3.amazonaws.com/media-p.slid.es/uploads/gwengwaihir/images/74719/mink-logo.png" alt="Mink" /></p>
<h1 id="documentação-do-mink">Documentação do Mink</h1>
<p>Esta é a documentação do Mink em português, ela foi fortemente inspirada em sua documentação oficial.
A ideia é que com o tempo possamos reescrevê-la adequando seus exemplos e explicações ao nosso cotidiano.
Então, caso você encontre melhorias, sinta-se a vontade para nos enviar a sua sugestão.</p>
<p>O Mink remove as diferentes APIs entre diferentes emuladores de navegador fornecendo diferentes drivers para todos os emuladores de navegador e provê uma forma fácil de controlar o navegador, analisar páginas, manipular elementos da página ou interagir com elas.</p>
<ul>
<li><a href="http://docmink.readthedocs.io">Documentação</a></li>
</ul>Documentação do Behat2016-05-06T16:20:00+00:002016-05-06T16:20:00+00:00https://dgosantos89.github.io/documentacao-behat<p><img src="https://dl.dropboxusercontent.com/u/282797/behat/behat.png" alt="Behat" /></p>
<h1 id="documentação-do-behat">Documentação do Behat</h1>
<p>Esta é uma documentação do Behat em português fortemente inspirada em sua documentação oficial.
A ideia é que com o tempo possamos reescrevê-la adequando seus exemplos e explicações ao nosso cotidiano.
Então, caso você encontre melhorias, sinta-se a vontade para nos enviar a sua sugestão.</p>
<ul>
<li><a href="http://docbehat.readthedocs.io">Documentação</a></li>
</ul>