# Test

> Checking your configuration before it reaches Radarr or Sonarr.

A page from the Profilarr documentation by https://github.com/santiagosayshey, last updated 2026-10-01 (commit: https://github.com/Dictionarry-Hub/profilarr.com/commit/92a5c54a149c3c94cd38a300e6082dc70a368f93). Web version: https://profilarr.com/test. Edit on GitHub: https://github.com/Dictionarry-Hub/profilarr.com/edit/develop/src/routes/(docs)/test/+page.svx

> **Info:** Testing is optional. It's most useful if you maintain your own configuration, because every change you make can break something you decided earlier. If you sync a database and only make the occasional change, you can skip this section and come back when you need it.

[Building](https://profilarr.com/build) a configuration means making lots of small decisions: which release groups you trust, which sources you prefer, how much lossless audio is worth, and so on. The regular expressions, custom formats, and quality profiles you end up with are the results of those decisions. But a result can't tell you why it looks the way it does, or which releases you had in mind when you made it. That part stays in your head.

Consider an example; you want a regular expression that matches lossless DTS audio. You have three releases in front of you, one lossless and two lossy, and you write `DTS-HD.MA`, the label you've seen on *most* lossless DTS releases. It matches the first and not the other two, which is what you want.

`DTS-HD.MA`

```text
Movie.2019.2160p.UHD.BluRay.[DTS-HD.MA].5.1-GROUP      lossless
Movie.2019.1080p.BluRay.DTS-HD.HRA.5.1-GROUP         lossy
Movie.2019.1080p.BluRay.DTS.5.1-GROUP                lossy
```

Square brackets mark the text the expression matched. They are not part of the string.

Weeks later a lossless release comes through labelled just `DTS-HD`, with no `MA`, and your expression misses it. You look at that release, shorten the expression to `DTS-HD`, and check it matches.

`DTS-HD`

```text
Movie.2019.1080p.BluRay.[DTS-HD].5.1-GROUP             lossless
```

Square brackets mark the text the expression matched. They are not part of the string.

What you didn't check was the lossy release from the first day. `DTS-HD.HRA` contains `DTS-HD`, so it matches now too.

`DTS-HD`

```text
Movie.2019.1080p.BluRay.[DTS-HD].HRA.5.1-GROUP         lossy, wrong
```

Square brackets mark the text the expression matched. They are not part of the string.

This is a [_regression_](https://en.wikipedia.org/wiki/Software_regression): something you had right, broken by a later change made while you were looking at something else. Nothing told you, because the decision that HRA must not match only ever existed in your head.

Testing takes those decisions out of your head. You write down a release and what should happen to it, and re-run that check after every change, so a regression shows up as a failed test instead of a wrong download weeks later. Each kind of entity has its own kind of test:

| Entity | Test |
| --- | --- |
| [Regular expressions](https://profilarr.com/test/regular-expressions) | Unit tests on regex101.com, run against the .NET regex engine Radarr and Sonarr use. |
| [Custom formats](https://profilarr.com/test/custom-formats) | Release titles with whether each one should match, and a breakdown of which conditions passed. |
| [Quality profiles](https://profilarr.com/test/quality-profiles) | Releases imported from a Radarr or Sonarr interactive search, scored against a profile. |

> **Info:** Every test in this section runs through the [parser](https://profilarr.com/installation#the-parser), so set it up before you start.

## Next

- [Test: Regular Expressions](https://profilarr.com/test/regular-expressions): Running Regex101 unit tests against the regex engine Radarr and Sonarr use.

---

Index of this site's Markdown pages: https://profilarr.com/llms.txt