Configurando Suite de Testes¶

Caminhos de Suite¶

Uma das configurações mais óbvias das suites é a configuração de caminhos:

# behat.yml

default:
    suites:
        principal_features:
            paths:
                - %paths.base%/features
                - %paths.base%/test/features
                - %paths.base%/vendor/.../features

Como vocẽ pode imaginar, esta opção diz ao Behat onde é para buscar as funcionalidades de teste. Você poderia, por exemplo, dizer ao Behat para procurar no arquivo features/web por funcionalidades e testá-los com WebContext:

# behat.yml

default:
    suites:
        web_features:
            paths:    [ %paths.base%/features/web ]
            contexts: [ WebContext ]

Você então pode precisar também descrever alguma funcionalidade para uma API-específica em features/api e testá-las com um ApiContext. Fácil:

# behat.yml

default:
    suites:
        web_features:
            paths:    [ %paths.base%/features/web ]
            contexts: [ WebContext ]
        api_features:
            paths:    [ %paths.base%/features/api ]
            contexts: [ ApiContext ]

Isto fará com que o Behat:

1. Encontre todas as funcionalidades em features/web e testá-las usando sua WebContext.
2. Encontre todas as funcionalidades em features/api e testá-las usando sua ApiContext.

As suites Path-Based são um fácil modo de testar aplicações altamente modulares onde as funcionalidades são entregues por componentes altamente desacoplados. Com suites você pode testar todos eles juntos.

Filtros de Suite¶

Além de ser capaz de executar funcionalidades de diretórios diferentes, nós podemos executar cenários do mesmo diretório, mas filtrado por critério específico. O analisador do Gherkin vem empacotado com uma coleção de filtros legais tal como filtros de tags e nome. Você pode utilizar estes filtros ao executar funcionalidades com uma tag (ou nome) específicas em contextos específicos:

# behat.yml

default:
    suites:
        web_features:
            paths:    [ %paths.base%/features ]
            contexts: [ WebContext ]
            filters:
                tags: @web
        api_features:
            paths:    [ %paths.base%/features ]
            contexts: [ ApiContext ]
            filters:
                tags: @api

Esta configuração irá dizer ao Behat para executar funcionalidades e cenários com a tag @web em WebContext e funcionalidades e cenários com a tag @api em ApiContext. Mesmo se todos eles estão armazenados no mesmo arquivo. Como isso é legal? Mas fica ainda mais, por que o Gherkin 4+ (usado no Behat 3+) adicionado um filtro muito especial role. Que significa, que você agora pode ter uma boa suite baseada em ator:

# behat.yml

default:
    suites:
        usuario_features:
            paths:    [ %paths.base%/features ]
            contexts: [ UsuarioContext ]
            filters:
                role: usuario
        administrador_features:
            paths:    [ %paths.base%/features ]
            contexts: [ AdministradorContext ]
            filters:
                role: administrador

Uma Função filtro olha para o bloco da descrição da funcionalidade:

Funcionalidade: Registrando usuários
  A fim de ajudar mais pessoas a utilizarem nosso sistema
  Como um administrador
  Eu preciso ser capaz de registrar mais usuários

  In order to help more people use our system
  As an admin
  I need to be able to register more users

Ele procura por um padrão Como um... e supõe um ator a partir dele. Ele então filtra funcionalidades que não tenham um ator no conjunto. No caso do nosso exemplo, isso basicamente significa que a funcionalidade descrita a partir da perspectiva do ator usuário irá ser testada em UsarioContext e funcionalidades descritas a partir da perspectiva do ator administrador serão testadas em AdministradorContext. mesmo se eles estiverem no mesmo arquivo.

Contextos de Suites¶

São capazes de especificar um conjunto de funcionalidades com um conjunto de contextos para estas funcionalidades dentro da suite tem um efeito colateral muito interessante. Você pode especificar as mesmas funcionalidades em duas suites diferentes sendo testadas por contextos diferentes ou o mesmo contexto configurado diferentemente. Isto basicamente significa que você pode utilizar o mesmo subconjunto de funcionalidades para desenvolver diferentes camadas da sua aplicação com o Behat:

# behat.yml

default:
    suites:
        domain_features:
            paths:    [ %paths.base%/features ]
            contexts: [ DomainContext ]
        web_features:
            paths:    [ %paths.base%/features ]
            contexts: [ WebContext ]
            filters:
                tags: @web

Neste caso, o Behat irá primeiramente executar todas as funcionalidades de features/ do arquivo DomainContext e em seguida somente aqueles com a tag @web em WebContext.

Executando Suites¶

Por padrão, quando você executa o Behat ele irá executar todas as suites registradas uma por uma. Se ao invés disso você quiser executar uma única suite, utilize a opção --suite:

$ vendor/bin/behat --suite=web_features

Inicialização de Suite¶

Suites são a principal parte do Behat. Qualquer funcionalidade do Behat sabe sobre elas e pode lhe dar uma mão com elas. Por exemplo, se você definir suas suites em behat.yml antes de executar --init, ele realmente irá criar os arquivos e suites que você configurou, ao invés do padrão.