You are viewing the documentation of TeamCity 2018.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.


Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Prior to TeamCity 9.1, one test could have been reported from within another test.
In the later versions,starting another test finishes the currently started test in the same "flow". To still report tests from within other tests, you will need to specify another flowId in the nested test service messages.



All the other test messages (except for testIgnored) with the same name attribute should appear between the testStarted and testFinished messages (in that order).

Currently, the test-related service messages cannot be output with If using Ant's echo task until flowId attribute is specifiedto output the messages, make sure to include flowId attribute with the same value in all the messages related to the same test/test suite as otherwise they will not be processed correctly.

It is highly recommended to ensure that the pair of test suite + test name is unique within the build.
For advanced TeamCity test-related features to work, test names should not deviate from one build to another (a single test must be reported under the same name in every build). Include absolute paths in the reported test names is strongly discouraged.


A full test name can have a form of: <suite name>:<package/namespace name>.<class name>.<test name>method>(<test parameters>),

where <class name> and <test name> <test method> can have no dots in the names. Only <test method> is a mandatory part of a full test name.

The full test name is used to compare tests between consequent builds or match tests across different build configurations.

An example of a full test name is

Code Block
Integration Tests: Backend: org.jetbrains.teamcity.LoginPageController.testBadPassword("incorrect password", false)
// in the example above, 
// suite name = "Integration Tests: Backend"
// package = org.jetbrains.teamcity
// class name = LoginPageController
// test method = testBadPassword
// test parameters = ("incorrect password", false)

The Tests tab of the Build Results page allows grouping by suites, packages/namespaces, classes, and tests. Usually the attribute values are provides as they are reported by your test framework and TeamCity is able to interpret which part of the reported names is the test name, class, package as follows:

TeamCity takes the suite name from the corresponding suite message and


test names correctly.

If a test cannot be parsed in the form above, TeamCity still tries to extract <suite name> from the full test name for the filtering on the Tests tab, and treats everything after the suite a non-parsable test name.

Reporting additional test data

Since TeamCity 2018.2, it is possible to attach extra information to the tests, using a testMetadata service message.

More details on this is available on a separate page.

Reporting .NET Code Coverage Results


id - (mandatory) limited by 255 characters
name - (mandatory) limited by 255 characters
category - (mandatory) limited by 255 characters. The category attribute examples are "Style violations", "Calling contracts" etc.
description (mandatory) limited by 4000 characters.  The description can also be in html, e.g.


where all the attributes can have either numeric or textual values:
typeId - (mandatory), reference to the inspectionType.id described above limited by 255 characters
message - (optional) current instance description limited by 4000 characters 
file - (mandatory) file path limited by 4000 characters. The path can be absolute or relative to the checkout directory
line - (optional) line of the file, integer
additional attribute - can be any attribute, SEVERITY is often used here, with one of the following values ((warning) mind the upper case): INFO, ERROR, WARNING, WEAK WARNING



The process of publishing artifacts process can affect the build because it consumes network traffic and some disk/CPU resources (should be pretty negligible for not large files/directories).


TeamCity allows changing the build status text from the build script. Unlike progress messages, this change persists even after a build has finished.
You can also change the build status of a failing build to success.

Prior to TeamCity 7.1, this service message could be used for changing the build status to failed. In the later TeamCity versions, the buildProblem service message is to be used for that.


To report build statistics using service messages: Specify a 'buildStatisticValue' service message with the following format for each statistics value you want to report: