GithubHelp home page GithubHelp logo

abhilashendurthi / testvectors Goto Github PK

View Code? Open in Web Editor NEW

This project forked from stratum/testvectors

0.0 0.0 0.0 669 KB

Collection of TestVectors test cases

License: Apache License 2.0

Dockerfile 40.44% Shell 4.06% Python 52.86% Makefile 2.64%

testvectors's Introduction

Test Vectors

This repo maintains Test Vectors-based test cases for testing Stratum enabled switches.

What are Test Vectors

Test Vectors offer a compact way of defining test input/output. A Test Vector is defined as a set of Test Cases where each test case is defined as a set of Actions and Expectations. Actions are operations run on the switch sequentially, in parallel, or in random sequence. Expectations are expected behavior and start after all actions are triggered. The assumption here is the switch is a blackbox, so an action or an expectation is basically a set of Open API access or external stimulus.

Detailed description of Test Vectors structure can be found in the docs.

Structure of this Repo

Currently Stratum supports Barefoot Tofino and Broadcom Tomahawk devices, as well as the bmv2 software switch. At this point Test Vectors for different switch targets are maintained separately under tofino, bcm and bmv2 folders.

Take tofino as an example, Test Vectors under tofino folder are organized into three test suites i.e. gnmi, p4runtime and e2e, each of which contains several Test Vector files with .pb.txt extension.

Note: please always use .pb.txt as filename extension when creating new Test Vectors. Files with other extensions might be ignored by a Test Vectors runner.

Other files under the same folder are listed below:

  • PipelineConfig.pb.txt is normally executed first to push a pipeline configuration to the switch under test.
  • target.pb.txt stores the IP and port of the switch under test which could be used by a Test Vectors runner to connect to the switch. E.g. address: "127.0.0.1:28000"
  • portmap.pb.txt contains a list of entries, each of which stores infomation related to a specific switch port used in the Test Vectors including port number, port type (see proto/portmap/portmap.proto for definition) and name of physical or virtual interface connected to the switch port. E.g. a portmap entry with port_number: 58, interface_name: "ens6f0" and port_type: 0 means interface ens6f0 is connected to switch port 58 and could be used as both ingress and egress to switch. The interfaces could be used by a Test Vectors runner to send or receive packets when Test Vectors contain Actions/Expectations that involve packets sending/receiving in the data plane.

Note: It is recommended to mark ports used in Test Vectors as either ingress or egress because it is not supported in the loopback mode to use a port that serves as both ingress and egress to the switch. See more details below.

Loopback Mode

In order to support running Test Vectors in loopback mode, each port used in Test Vectors should be specified as either ingress or egress to the switch. In addition, extra Insert* and Delete* Test Vectors are provided as part of loopback mode setup and teardown.

Test Vector Templates

As an alternative way of maintaining the tests, Test Vector templates were created with the goal of having only one set of tests that works across multiple switch platforms. Test Vector templates use .tmpl instead of .pb.txt as extension name and are maintained under templates folder. They are organized the same way as the platform specific Test Vectors.

In addition to the template files, one template configuration file is also needed for each platform. The template configuration file is used for rendering the templates and producing Test Vector files that match your switch target. Examples of template configuration files can be found under switch target specific folders e.g. bcm/template_config.json. Also check the docs for more details about Test Vector templates.

Run Test Vectors-based Tests

Reference implementation of Test Vectors Runner and commands to run example tests can be found here.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.