# Test Pyramid concept

The test pyramid is a way of thinking about different kinds of automated tests should be used to create a balanced portfolio. Its essential point is that you should have many more low-level UnitTests than high level BroadStackTests running through a GUI.

![](https://3408508746-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lis5JLcnSD2vdYdyQ3U%2F-Lk8mPkGNbnUwxjwoBQ0%2F-Lk8mas48dkLaQXmPe79%2Fimage.png?alt=media\&token=f8a2b553-d99b-4a0c-a998-978198794445)

Test pyramid consists of 3 types of tests:

* unit,
* integration,
* end-to-end.

{% hint style="success" %}
The **concept of pyramid** refers to the ratio in which these types of tests are usually presented in a test suite.
{% endhint %}

As unit tests run fast, it makes sense to have more of them as they give the quickest feedback. On the contrary, end-to-end tests are the minority because they take a lot of time to execute.

Tests residing in each level have a different value proposition. The higher the level, the more protection against regression errors and false positives you get. But you do that at the expense of the feedback speed. Similarly, the lower the level, the faster your tests run, but at the expense of coupling your tests to the details of the classes' structure.

{% hint style="info" %}
While the test pyramid is a good **guideline** in general, you need to take into account the specifics of your own project. You don't have to have end-to-end tests if you think that integration tests will provide enough protection for your code base. The ratio between the number of the tests of different types is also **not a strict rule**.

If your project is quite simple in terms of business rules, it might make sense to have just a few unit tests, and focus the most of your effort on integration testing because integration with database and other sub-systems in this case would be the most risky area.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://dotnetweb30-ke.gitbook.io/ke/verification/automated-testing-principles-patterns-and-practices/test-pyramid-concept.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.