Configurando Suíte de Testes¶

Caminhos de Suíte¶

Uma das configurações mais óbvias das suítes é 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 suítes 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 suítes você pode testar todos eles juntos.

Filtros de Suíte¶

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 tais como filtros de tags e nome. Você pode utilizar estes filtros ao executar funcionalidades com uma tag (ou nome) específica 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. Achou isso legal? Isso ficará ainda mais, por que o Gherkin 4+ (usado no Behat 3+) trouxe um filtro muito especial role. Que significa, que você agora pode ter uma boa suíte 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

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 Suítes¶

São capazes de especificar um conjunto de funcionalidades com um conjunto de contextos para estas funcionalidades dentro da suíte tem um efeito colateral muito interessante. Você pode especificar as mesmas funcionalidades em duas suítes 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 Suítes¶

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

$ vendor/bin/behat --suite=web_features

Inicialização de Suíte¶

Suítes 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 suítes em behat.yml antes de executar --init, ele realmente irá criar os arquivos e suítes que você configurou, ao invés do padrão.