- 
-
-
-
- Build integration and end-to-end tests in minutes, instead of days, using OpenTelemetry and trace-based testing. -
+## Table of Contents +- [How does QT works?](#How--does-QT-works?) +- [Architecture diagram](#architecture-diagram) +- [How to install and run Quality Trace?](#how-to-install-and-run-Quality-Trace?) +- [What does the test definition file look like?](#what-does-the-test-definition-file-look-like) +- [How to run an automated test?](#how-to-run-an-automated-test?) - - - - - -- Docs | - Tutorials | - Recipes | - Examples | - Discord | - Blog | - Website -
- - -
-
- 
-
- 
-
-
- 
-
-
- 
-
-
- 
-
-
- 
-
-
- 
-
-
- 
-
-
- 
-
-
- 
-
- 
- 
-
- 
-
-- Tracetest lets you build integration and end-to-end tests 98% faster with distributed traces. -
+1. Pick an endpoint to test. +2. Run a test, and get the trace. +3. The trace is the blueprint of your system under test. It shows all the steps the system has taken to execute the request. +4. Add assertions on different services, checking return statuses, data, or even execution times of a system. +5. Run the tests. -- No plumbing, no mocks, no fakes. Test against real data. -
+Once the test is built, it can be run automatically as part of a build process. Every test has a trace attached, allowing you to immediately see what worked, and what did not, reducing the need to reproduce the problem to see the underlying issue.We can able to see the traces in signoz ui. -You can: +## Architecture diagram -- **Assert** against both the **response and trace data** at every point of a request transaction. -- **Assert** on the **timing of trace spans**. - - Eg. A database span executes within `100ms`. -- **Wildcard assertions** across common types of activities. - - Eg. All gRPC return codes should be `0`. - - Eg. All database calls should happen in less than `100ms`. -- **Assert** against **side-effects** in your distributed system. - - Eg. Message queues, async API calls, external APIs, etc. -- **Integrate** with your **existing distributed tracing solution**. -- Define multiple test triggers: - - HTTP requests - - gRPC requests - - Trace IDs - - and many more... -- Save and run tests manually and via CI build jobs. -- Verify and analyze the quality of your OpenTelemetry instrumentation to enforce rules and standards. -- Test long-running processes. - -**Build tests in minutes**. - -- **Visually** - in the Web UI -
- 
-
-
-
- Click on the image or this link to watch the "Tracetest Intro Video" video (< 2 minutes)
- 
-
+ Qualitytrace lets you build integration and end-to-end tests 98% faster with distributed traces. +
-Once you've installed Tracetest Server, access the Tracetest Web UI on `http://localhost:11633`. ++ No plumbing, no mocks, no fakes. Test against real data. +
-Check out the [Opening Tracetest guide](https://docs.tracetest.io/getting-started/open) to start creating and running tests! +**Build tests in minutes** -# 🤔 How does Tracetest work? +We should use yaml file for testing the http and grpc applications from the cli. +## What does the test definition file look like? -1. Pick an endpoint to test. -2. Run a test, and get the trace. -3. The trace is the blueprint of your system under test. It shows all the steps the system has taken to execute the request. -4. Use this blueprint to define assertions in the Tracetest Web UI. -5. Add assertions on different services, checking return statuses, data, or even execution times of a system. -6. Run the tests. +The Quality Trace [test definition files] are written in a simple YAML format. You can write them directly. Here is an example of a test which: -Once the test is built, it can be run automatically as part of a build process. Every test has a trace attached, allowing you to immediately see what worked, and what did not, reducing the need to reproduce the problem to see the underlying issue. +- Executes `POST` against the endpoint. +- Verifies that the HTTP blocks return a `201` status code. -# 📂 What does the test definition file look like? +```yaml +type: Test +spec: +id: tA_Of67IR +name: name of the application +trigger: +type: http +httpRequest: +method: Method you need to test like GET,POST etc +url: [Endpoint of your application] +body: [body {"The request body of your application"}] +headers: +- key: Content-Type +value: application/json +specs: +- selector: span[Qualitytrace.span.type="http"] +name: "All HTTP Spans: Status code is 201" +assertions: +- attr:http.status_code = 201 +``` -The Tracetest [test definition files](https://docs.tracetest.io/cli/test-definition-file) are written in a simple YAML format. You can write them directly or build them graphically via the UI. Here is an example of a test which: +Save a test definition file for http application. Use the CLI to run a test. -- Executes `POST` against the `pokemon/import` endpoint. -- Verifies that the HTTP blocks return a `200` status code. -- Verifies all database calls execute in less than `50ms`. +For grpc applications please add the protobuf file in the definition file. ```yaml type: Test spec: - id: 5dd03dda-fad2-49f0-b9d9-5143b746c1d0 - name: DEMO Pokemon - Import - Import a Pokemon - description: "Import a pokemon" - - # Configure how tracetest triggers the operation on your application - # triggers can be http, grpc, etc + id: xZIRCuIIZ + name: name of the application trigger: - type: http - httpRequest: - method: POST - url: http://demo-pokemon-api.demo.svc.cluster.local/pokemon/import - headers: - - key: Content-Type - value: application/json - body: '{"id":52}' - - # Definition of the test specs which is a combination of a selector - # and an assertion - specs: - # the selector defines which spans will be targeted by the assertions - selector: span[tracetest.span.type = "http"] - # the assertions define the checks to be run. In this case, all - # http spans will be checked for a status code = 200 - - assertions: - - http.status_code = 200 - # this next test ensures all the database spans execute in less - # than 50 ms - selector: span[tracetest.span.type = "database"] - - assertions: - - tracetest.span.duration < "50ms" + type: grpc + grpc: + protobufFile: | + [your application protobuf file] +address: Endpoint to your appplicaion +method: [Method you need to test] +request: [The request body of your application] +auth: {} ``` -# 🤖 How to run an automated test?. - -Save a test definition file above as `pokeshop_import.yaml`. Use the CLI to run a test. +## How to run an automated test? ```bash -tracetest run test --file /path/to/pokeshop_import.yaml +quality-trace run test --file /path/to/name.yaml ``` -Check out the [CI/CD docs](https://docs.tracetest.io/ci-cd-automation/overview) to learn more about test automation. - -# Tests - -We strive to produce quality code and improve Tracetest rapidly and safely. Therefore, we have a full suite of both front-end and back-end tests. Cypress tests are running against the front-end code and (surprise, surprise) Tracetest against the back-end code. You can see the [test runs here](https://github.com/kubeshop/tracetest/actions/workflows/pull-request.yaml), and a blog post describing our [testing pipelines here](https://tracetest.io/blog/50-faster-ci-pipelines-with-github-actions). - -# 🎤 Feedback - -Have an idea to improve Tracetest? - You can: -- [Create an issue here](https://github.com/kubeshop/tracetest/issues/new/choose)! -- Join our [Discord](https://discord.gg/eBvEQRVyKX), and ask us any questions there. -- Follow us on [Twitter at @tracetest_io](https://twitter.com/tracetest_io) for updates. -- Give us a ⭐️ on Github if you like what we're doing! - -# 🌱 Contributing & Community - -Whether it's big or small, we love contributions. - -Not sure where to get started? You can : - -- Visit our [Community Page](https://tracetest.io/community). -- See our contributing guidelines [here](./CONTRIBUTING.md). +- **Assert** against both the **response and trace data** at every point of a request transaction. +- **Assert** on the **timing of trace spans**. + - Eg. A database span executes within `100ms`. +- **Wildcard assertions** across common types of activities. + - Eg. All gRPC return codes should be `0`. + - Eg. All database calls should happen in less than `100ms`. +- **Assert** against **side-effects** in your distributed system. + - Eg. Message queues, async API calls, external APIs, etc. +- **Integrate** with your **existing distributed tracing solution**. +- Define multiple test triggers: + - HTTP requests + - gRPC requests + - Trace IDs + - and many more... +- Save and run tests manually. +- Verify and analyze the quality of your OpenTelemetry instrumentation to enforce rules and standards. +- Test long-running processes. \ No newline at end of file diff --git a/assets/QTArchitecture.png b/assets/QTArchitecture.png new file mode 100644 index 000000000..c11992dd8 Binary files /dev/null and b/assets/QTArchitecture.png differ