Muting Test Failures

TeamCity provides a way to "mute" any of the currently failing tests so they will not affect build status for future builds.

When a test is muted, it is still run in the future builds, but its failure does not fail the build (by "at least one test failed" Configuring General Settings). The test can be unmuted manually on specific date or after successful run. Also, tests can be muted only in a single build configuration or in all the build configurations of a specific TeamCity project.

Your build script might need adjustment to make build green when there are failing but muted tests. Please ensure that build does not fail because of other build failure conditions (like "Fail if build process exit code is not zero") in case the only errors encountered were tests failures. See also related issue TW-16784.

How to mute tests

Only users with the Mute/unmute problems in project permission can perform it. By default, these are Project administrator and System administrator You can mute a test failure from:

• Projects page

• Project overview page

• Build Configuration overview page

• Current Problems tab

On the build results page you can select several test failures (or all) to be muted or unmuted:

Note, that you can start investigation of the problem simultaneously with muting the failure. When muting a test failure you can specify conditions when it should be unmuted: on a specified date or when it is fixed. Alternatively, you can unmute it manually.

• On the build results page you can view the list of muted test failures, their stacktraces and details about mute status:

  

• From the Project Home page you can navigate to the Muted Tests tab to view all the test failure muted in all build configurations within project.

This feature is useful when some tests fail for some known reason, but it is currently not possible to fix them. For example, responsible developer is on vacation, or you are waiting for the system administrators to fix the environment, or the test is failing intentionally, for example, if required functionality is not yet written (TDD). In these cases you can mute such failure and avoid unnecessary disturbance of other developers.