1 / 7

Integration & Test Strategy for Lithium

This strategy focuses on testing individual and combined projects in OpenDaylight, with a common CI process for all projects and a non-rigid distribution. It includes test triggers, distribution assembly, build and system tests, and feature-specific system tests.

gantt
Download Presentation

Integration & Test Strategy for Lithium

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Integration & Test Strategy for Lithium

  2. Facts • OpenDaylight is made of multiple projects -> we have to test them individually and together • Projects are quite heterogeneous: core, tools, plugins, apps, etc… -> they have different test needs • OpenDaylight has a common CI process for all projects -> tests should in general be part of the CI • We leave users freedom to select features -> we need an strategy to test a non-rigid distribution

  3. High Level Strategy • Forget about verifying projects, focus on features • Test single feature enabled to identify issues in a feature itself • Test all features enabled to identify feature interferences • For a given project, tests are called after: • A change (merge) in an upstream project. This triggers build and system test • A change in the project itself. We miss system test on code submit • Be selective with the tests we run • A change in a “stem” project will trigger test on many features • A change in a “leaf” project will trigger test on few concerned features

  4. Distribution Assembly We define 2 integration features for test purposes: • compatible-with-all -> useful for all features system test • all = compatible-with-all + incompatible features -> useful to detect feature/bundle interferences We generate 2 distributions (no feature enabled at startup): • Regular distribution with all projects feature indexes (except integration) • Test distribution = Regular distribution + integration feature index

  5. Build Test Build test occurs during project code build. Examples are Junit, PAX-EXAM or Karaf feature install test Every project in OpenDaylight defines 3 build jobs: • Verify -> This job builds the project code and pass build tests upon code submit • Merge -> This job builds the project code and pass build tests upon code merge. In addition it will upload generated artifacts to Nexus repository. • Integration -> This job will build the project code and pass build tests after a merge in an upstream project

  6. System Test System test requires a framework that installs controller and executes tests against network tools. Example is the Robot test. For every project user-facing feature we will create 2 system test jobs: • feature-only test -> Install single feature with required dependencies and run feature planned test • feature-all test • If feature is compatible -> Install odl-integration-compatible-with-all and run feature planned test • If feature is not compatible -> Install odl-integration-compatible-with-all + incompatible feature and run feature planned test

  7. Test Triggers feature-only test* Verify build Code Submit For all projects in downstream Integration build For all features in downstream Merge build Code Merge feature-only test feature-all test For all available features *Optional (requires project distribution or some automation to update project artifact) feature-only test Release creation feature-all test

More Related