User Tools



Testspace Client

The Testspace Client is a command line tool used to push results to Testspace.

For installation information of the Testspace Client, please see: Installing Client

The Client executes on a host computer and communicates with Testspace via the Internet. It's a lightweight command line tool with versions for Windows, Linux, and Mac OS X. It's suitable for inclusion in automated build/test setups and can also be used interactively.

The Testspace Client command line supports five commands that specify the action the tool will perform. Each command has its own set of parameters.

Syntax

testspace [--version] [--help] [<command>] [<args>] ​
Command Action
config Get and set default global options.
push Push existing result file(s) to a Space. (this is the default)

Any argument with NAME=VALUE syntax will be treated as an environment variable assignment available during the current execution. For example: testspace "mytests.xml" "my-space" NAME=VALUE

To prevent unexpected behavior due to the way the shell interprets the command line, any argument containing spaces and/or special shell character should be surrounded in double quotes.


Config

​The config command allows you to pre-configure all or part of the default Testspace URL used in subsequent testspace invocations. When running Testspace interactively, this simplifies the parameters you must enter.

​testspace config <option-name> [<value>]

If you run the command with no arguments, the current settings are displayed on the console.

Note: The configuration scope is the local user profile.

All base Testspace URLs have the following form:

credentials@domain-name/project-name/space-name

The URL decomposes into three segments delimited by the forward slash: domain (including credentials), project, and space.

With the config command, you can set defaults for any or all of these fields.

Tip: A common practice is to use the config command to set default values for some or all of the required URL segments. These defaults then don't have to be specified on the command line when you push - anything that is given for the URL parameter is appended to the current value previously set with config.
Note: If you are planning to work with more than one Space within a Project you can set a partial default URL and then specify the Space name on the command line when you push.
Note: If an argument contains one or more space characters, you must surround the argument in double quotes. This can be avoided by refraining from the use of the space character in Project and Space names.

option-name

The following options are supported:

project - sets/gets the project name segment of the URL; it is the name (non case sensitive) of an existing Project in your Organization

space - sets/gets the space name segment of the URL; it is the name (non case sensitive) of an existing Space in the Project

url - sets/gets the entire URL (all three fields) in a single operation.

config examples

Set entire URL as default

testspace config url "myuser:mysecret@myorg.testspace.com/My-Project/My-Space"

Set partial URL as default; no space specified

testspace config url "myuser:mysecret@myorg.testspace.com/My-Project"

View current config settings

testspace config

To clear a setting use "". For example testspace config url project "".

Set project option; clear current setting for space

testspace config project "My-Project"
testspace config space ""

Login Credentials

The specified login credentials (the part of the domain segment before @) must match an account with permission on the Project specified by the Testspace URL.

The credentials may be given either as user:pwd or as anaccess-token1).

For example:
myuser:mysecret@myorg.testspace.com/project-name/space-name

Or, if using an access token:
6c074d4ab70a53ba19c0e5abfacc72699f1c03b1:@myorg.testspace.com/project-name/space-name

Persisting your Login Credentials

You may also persist your login credentials, which allows you to omit them in the URL.

Windows

Using Control Panel | User Accounts | Credential Manager create a Generic Credential:

Network address: myorg.testspace.com
User name: myuser
Password: mysecret

To use an Access token replace the username with the token and leave the password field blank.

Network address: myorg.testspace.com
User name: 6c074d4ab70a53ba19c0e5abfacc72699f1c03b1
Password: 
Linux/OSX

In ~/.netrc file, simply add:

machine myorg.testspace.com
login myuser
password mysecret
:!: Note: This technique is insecure, as the password is stored in plain-text. Make sure you modify permissions to make the file readable only by yourself.

When using an Access token replace the username with the token and leave the password field blank.

machine myorg.testspace.com
login 6c074d4ab70a53ba19c0e5abfacc72699f1c03b1
password 

Using a Proxy

If you access the Internet via an HTTP proxy, you must set the environment variables HTTP_PROXY and HTTPS_PROXY to specify the name and port of the proxy server.

Symptoms of needing to specify a proxy is an error like:

Unable to proceed. Unable to access "My-Space" space in "My-Project" project at Testspace (myorg.testspace.com) with specified credentials (myuser). 
Failed performing request: [7] Couldn't connect to server

Define the environment variables in format host:port, corresponding to your proxy server. For example, on Windows:

> set HTTP_PROXY=myproxy:8765
> set HTTPS_PROXY=myproxy:8765

would instruct the Testspace Client to use the proxy named myproxy on port 8765 to communicate via HTTP and HTTPS protocols.

If your proxy requires authentication use the format username:password@host:port where username and password are your credentials.


Push

The push command uploads existing test results data in one of the supported formats to a Space.

testspace push [options] [<files>] [<url>]

Note that the push command is the default, thus is not required on the command line.

testspace [options] [<files>] [<url>]

options

Option Description
--repo arg Specifies the type of the repository to allow collection of commit details and generation of a code change report. Its value must be formatted in the following way:
type[:path]
Where type could be 'git', 'svn' or 'p4' and path is an optional path to the local repository location, otherwise the current directory will be used.
:!: Note: For 'git' the optional path argument is equivalent to ''--git-dir'' git's option and can also be controlled by setting the GIT_DIR environment variable.
:!: Note: For 'p4' there must an active login ticket plus ''P4PORT'' and ''P4CLIENT'' (matching the specified optional path argument) settings configured in your environment.
--build-url arg Specifies the URL of the build that produced the content being pushed.
--message arg Specifies a textual description to associate with the pushed content.
--dry Dry processing, just validate the input without uploading.
--verbose Print detailed progress messages.

files

This specifies one or more files (space delimited) to be uploaded. Each entry can be full or relative to the current console directory file path (including wildcard pattern), formatted as follows:

[[folder]][+]/path/to/file[{metadata}]

where the optional prefix and suffix are:

Option Description
[folder] A result folder to place the content of the file in.
+ When + prefix is present, instead of interpreting the test result data, the containing file is treated opaque and is simply added as an annotation.
{metadata} File specific metadata that define special processing of the content:
- for Unit Test Formats must be the root file path to the test source code, base on file folder hierarchy the test results should be organized;
- for Static Analysis "Test Log" Format must be set to lint;
- when + prefix is present provides a textual description for the annotation
- for custom metrics must be a `.csv` file
- for log file must be exit code and/or textual description
:!: Note: If a file argument is not a simple file-path or contains one or more space characters, you must surround it in double quotes. That would prevent unexpected behavior due to the way the shell expands wildcard patterns.

If multiple files are specified, the results of all files will be automatically aggregated into a single result set. Also a file containing a lists of files to push can be specified.

@/path/to/content-list.txt

Where content-list.txt contains line separated list of files:

file1.xml
file2.xml

url

The form of the URL argument is as follows:

credentials@domain/project/space[?how][#[name][/path-to]]

By default, the root Space URL will use the one set with the ''config'' command, but you can optionally specify a URL on the command line that will override any existing config setting if present.

The other segments of the URL are described below.

how

The optional how segment specifies the way results are to be pushed. Use this option when you want to aggregate several uploads into a single result set. If you invoke the Testspace Client more than once to push to a single result set, you use the how segment to specify the state that the result set should be in after the current invocation.

Recognized values are:

full Causes a new result set to be created and marked complete (this is the default).
start Creates a new result set and marks it incomplete.
add Adds more data to an existing incomplete result set and keeps it incomplete.
finish Adds more data to an existing incomplete result set and marks it complete.

When using the how argument, you must specify the identical result set name for each Testspace Client invocation.

Note: Use the how argument only when you invoke the Testspace Client multiple times and want to aggregate results from more than one publication.

name

Use the optional name argument to specify a name for the result set created in Testspace. The name does not have to be unique to existing result sets.

A name is required when you specify anything but full in the how segment in order to match uploads from multiple invocations to a singe result set.

If not specified, the Testspace Client will supply the name Sequence_N, where N is a monotonically increasing integer.

path-to

The optional path-to argument specifies a path under the Space root where the pushed results will be placed.

When uploading results, this feature is useful when you want to better organize a result set uploaded via multiple invocations of the Testspace Client; each upload can specify a different root folder. Any non-existent folders in the path are automatically created using the name given in the path.

Push Examples

Note: Additional examples are shown in Push Data.

Push local myResults.xml to a Space

testspace myResults.xml "myuser:mysecret@myorg.testspace.com/My-Project/My-Space"

Push local myResults.xml to a Space; default Project Root URL has been set via config

testspace myResults.xml My-Space

Push multiple files to a single result set

testspace myResults1.xml myResults2.xml My-Space

Push multiple files to a single result set using wildcard

testspace myResults*.xml My-Space

Push result files to specific folder, by organizing the content based on its test source location and add a file annotation to a folder named Coverage

testspace push "[Folder1]myResults*.xml{/path/to/test-source}" "[Coverage]+/path/to/myProj.cov{Bullseye Coverage}" My-Space

Incrementally push files to specific folders in a single result set named my-resultset; default Project Root URL has been set via config

testspace myResults1.xml "My-Space?start#my-resultset/Folder1"
testspace myResults2.xml "My-Space?add#my-resultset/Folder2"
testspace "My-Space?finish#my-resultset/Folder3"
1) You can generate and get an Access token from your User Settings

Page Tools