---
title: Writing automated tests
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

Test automation is an important part of every development project and is essential for agile projects. Automated tests help you improve productivity, reduce the testing phase of the development cycle, and increase code predictability and quality.

When developing custom functionality for Xperience projects, we recommend that you [create projects with automated tests](https://docs.kentico.com/13/custom-development/writing-automated-tests/creating-automated-test-projects.md) to cover the given code.

Xperience provides the **CMS.Tests** library, which simplifies writing of automated tests for code that uses the Xperience API. The library contains base classes for unit and integration tests, as well as helper classes for faking _Info_ and _Provider_ objects. You can obtain the library by installing the **Kentico.Xperience.Libraries.Tests** NuGet package into your test projects.

## Supported testing framework

All of the functionality in the _CMS.Tests_ library is compatible with the [NUnit](https://github.com/nunit/docs/wiki) testing framework.

## Types of tests

You can create the following general types of tests (categorized according to the way the tests work with database data):

> **Info:** 
>
> ### Unit tests
>
> Unit tests are able to run without external resources, such as a database. Try to write most of your tests as unit tests, since they are used to examine relatively small pieces of code. Unit tests execute much faster than the other types of automated tests.
>
> Use fake _Info_ and _Provider_ objects in your unit tests to avoid accessing the database. For more information, see [Faking Info and Provider objects in unit tests](https://docs.kentico.com/13/custom-development/writing-automated-tests/faking-info-and-provider-objects-in-unit-tests.md).

> **Info:** 
>
> ### Integration tests
>
> Integration tests can access a database provided by a connection string. Use integration tests when you need to read the data from the database (unless you are absolutely sure you clean up everything properly after the test). Integration tests are significantly slower than unit tests.
>
> See: [Creating integration tests with a connection string](https://docs.kentico.com/13/custom-development/writing-automated-tests/creating-integration-tests-with-a-connection-string.md)

> **Info:** 
>
> ### Isolated integration tests
>
> Isolated integration tests automatically create their own database before the test execution and clean up the database after the test is finished. Use isolated integration tests for complex testing that requires writing to the database, for example if the cleanup after an integration test is difficult. Isolated integration tests are the slowest of the three types of automated tests.
>
> See: [Creating isolated integration tests](https://docs.kentico.com/13/custom-development/writing-automated-tests/creating-isolated-integration-tests.md)

## API differences in test code

By default, all Xperience API executed within the body of tests that inherit from the _CMS.Tests_ base classes runs without additional logging operations. For example, this includes logging of [staging tasks](https://docs.kentico.com/13/deploying-websites/content-staging.md), [web farm synchronization tasks](https://docs.kentico.com/13/configuring-xperience/setting-up-web-farms.md), etc. Such operations are typically not relevant for the results of tests and unnecessarily reduce test performance.

If you wish to run these additional operations within your tests, you need to explicitly enable them for blocks of code using the corresponding properties of **CMSActionContext**.

```csharp title="Example"

using CMS.Base;

...

using (new CMSActionContext { LogSynchronization = true, LogWebFarmTasks = true })
{
    // Test execution
}

```