Skip to content

Latest commit

 

History

History
86 lines (63 loc) · 4.69 KB

README.md

File metadata and controls

86 lines (63 loc) · 4.69 KB
Raw

POKT E2E Testing Document

Table of Contents

tl; dr - make localnet_up and then make test_e2e

Tilt button for running E2E tests

You can also click the e2e-tests button in the Tilt UI, which is handy during development.

Development

make localnet_up to start a LocalNet. make test_e2e after it's up to run the end to end test suite.

The code depends on a Kube config located at the $HOME/.kube/config default path for retrieving a Clientset.

Typical Development Workflow

godog run e2e/tests/ generates error stubs based on the detected feature files. This speeds up writing tests because you can copy & paste over the stubbed-out Go step definitions of new steps that need writing.

Build Tags

Because the E2E tests depend on a Kubernetes environment to be available, the E2E tests package gets a build tag so the E2E tests are ignored unless the test command is run with -tags=e2e. Issue #581 covers running the E2E tests in the delivery pipeline. This also means the develop_test Make target won't run E2E tests.

Issue templates

Issues can formally define features by attaching an erroring feature file to bug or feature requests. A complete example feature is provided below.

Feature: Example Namespace

  Scenario: User Needs Example
    Given the user has a node
    When the user runs the command "example"
    Then the user should be able to see standard output containing "Example Output"
    And the pocket client should have exited without error

Implementation

The test suite is located in e2e/tests and it contains a set of Cucumber feature files and the associated Go tests to run them. make test_e2e sees any files named with the pattern *.feature in e2e/tests and runs them with godog, the Go test runner for Cucumber tests. The LocalNet must be up and running for the E2E test suite to run.

The Node issues RPC commands on the container by calling kubectl exec and targeting the pod in the cluster by name. It records the results of the command including stdout and stderr, allowing for assertions about the results of the command.

---
title: E2E Lifecycle
---
flowchart TD
    subgraph Init [Initialization]
        Harness[Harness initialization] --$HOME/.kube/config--> Kubeconfig
        Kubeconfig --> Clientset
    end
        Kubeconfig --> Kubectl
        Kubeconfig --> DevNet
    subgraph E2E [E2E scenarios]
        Kubectl -- commandResult --> Node
        Node -- args --> Kubectl
    end
    subgraph DevNet [DevNet]
        Runner[E2E Test Runner]
    end
Loading

Keywords

The keywords below are a summary of the source documentation available here.

  • Feature: This keyword, followed by the name and optional description, is used to describe a feature of the system that you're testing. It should provide a high-level description of a software feature, and to group related scenarios.
  • Scenario: This keyword, followed by the name and optional description, is used to describe a particular behavior of the system that you're testing. A feature can have multiple scenarios, and each scenario should follow the 'Given-When-Then' structure.
  • Given: This keyword is used to set up a situation or a context. It puts the system in a known state before the user interacts with the system.
  • When: This keyword is used to describe an action or event. This is something the user does or the system does.
  • Then: This keyword is used to describe an expected outcome or result.
  • And, But: These keywords are used when you have more than one Given, When, or Then step. They help to make the specifications more readable.
  • Background: This keyword provides the context for the following scenarios. It allows you to add some context to the scenarios in a single place.
  • Scenario Outline: This keyword can be used when the same test is performed multiple times with a different combination of values.
  • Examples: This keyword is used in conjunction with Scenario Outline to provide the values for the test.
  • Rule: This keyword is used to represent one business rule that should be implemented. It provides additional information for a feature.
  • Tags: This is not a Gherkin keyword but an integral part of organizing your Cucumber features. They are preceded by '@' symbol and can be used before Feature, Scenario, Scenario Outline, or Examples.