You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Test Paths is a feature for development to test multi-repository applications. These are applications that span multiple projects, which communicate using one of the following services and/or containers:

For instance you have an application which start with project A that shows a dashboard, which opens project B, which starts an external flow in project C, etc. When you are developing your application, you sometimes need to change only one project in the whole application chain. Test Paths allow you to only branch that specific project and test your application with that specific branch, without having to resort to branching every project in the application, changing shortcuts etc.

The following presentation explains this in more detail.


Test Paths only work when the Runtime is in development mode, as this is a development feature, which makes testing changes to a project in an application chain easier.

Usage

The first step is making the runtime aware of the fact that a Test Path exists. You do this by adding the Test Paths to a shortcut, in the form <name> = <version>:

application.properties
blueriq.shortcut.ChildSupport.testPaths.feature1 = 0.0-FeatureBranch1
blueriq.shortcut.ChildSupport.testPaths.feature2 = 0.0-FeatureBranch2

This indicates that when the project is started with Test Path feature1, the project should use 0.0-FeatureBranch1 instead of the version indicated by blueriq.shortcut.ChildSupport.version.

If any Test Paths are configured, the development dashboard will display a selector for the Test Paths:

Selecting a Test Path will result in the following behavior:

  • When the selected Test Path is defined for the shortcut, the corresponding version of the project is started instead of the default version.
  • When the selected Test Path is not defined for the shortcut, the default version of the project is started.
  • When the selected Test Path is defined, but the corresponding version doesn't exist in the project, an error is returned.

The selected Test Path will be propagated through the entire application. This means that even if the current shortcut has not defined the Test Path (and therefore uses the default version), it will still pass it on because the Test Path may be defined on project further downstream.

The Test Path names, e.g. feature1 in the previous example, are identifiers that are limited to alphanumeric characters and underscores. Choose Test Path names that describe the feature you are testing.

It is possible to use a Test Path when calling a Blueriq REST-service. To do this, add a header with key X-Blueriq-Test-Path and for value the name of your Test Path.

Cleaning up

When a feature is done and the corresponding branch is merged, the Test Path is not automatically deleted. As a maintainer of the shortcuts, you should remove Test Paths for these versions manually.
This way, the list of Test Paths to choose from will remain restricted to features that are still under development.

A note on StartControllers

Blueriq has the Old Start Controller and the new API Start Controller which is used by external themes. Both StartControllers support the Test Path feature in the following way:


Old Start ControllerAPI Start Controller
Entrypoint/runtime/server/start/runtime/server/api/v2/start
Test Path support in start project endpoint
Test Path support in start shortcut endpoint
Test Path override from start in shortcuts
Test Path override from start in projectreference
Test Path support in default project


Note that for overriding a Test Path in a project reference, you can simply select another version, so there is no need to override it. The same holds for the default project, which is the fallback project when you do not specify anything (including Test Path).



  • No labels