diff --git a/docs/gsoc/contribution-guide.md b/docs/gsoc/contribution-guide.md
index 53c37a4bf..2fb4c468f 100644
--- a/docs/gsoc/contribution-guide.md
+++ b/docs/gsoc/contribution-guide.md
@@ -24,7 +24,7 @@ Google pays the students, not the organizations they work with. Beginning in 202
You can read more about the format of the program and its goals [here](https://google.github.io/gsocguides/mentor/).
-
+
## Keploy X GSoC
diff --git a/docs/hacktoberfest/contribution-guide.md b/docs/hacktoberfest/contribution-guide.md
index 78bbf333c..e39f9505d 100644
--- a/docs/hacktoberfest/contribution-guide.md
+++ b/docs/hacktoberfest/contribution-guide.md
@@ -10,7 +10,7 @@ label: Hacktoberfest
Hacktoberfest'22 is a month-long celebration of open-source software run by DigitalOcean. Hacktoberfest is open to everyone, from first-time contributors to seasoned open-source developers. Your open-source journey begins with a pull request.
-
+
## Hacktoberfest Journey with Keploy
diff --git a/docs/hacktoberfest/non-code.md b/docs/hacktoberfest/non-code.md
index b51541dc6..72c4f9de3 100644
--- a/docs/hacktoberfest/non-code.md
+++ b/docs/hacktoberfest/non-code.md
@@ -8,8 +8,8 @@ label: Hacktoberfest
There are many ways to contribute to Keploy projects without writing a single line of code. You can help with:
-- Used Keploy recently ? Tell the community about it in an awesome blog post.
+-
Used Keploy recently ? Tell the community about it in an awesome blog post.
--
Improve Documentation as the more detailed the documentation is, better it will be for people who are looking for help.
+-
Improve Documentation as the more detailed the documentation is, better it will be for people who are looking for help.
--
Create a tutorial because they provide instructions on how to use a tool or service in a step-by-step manner.
+-
Create a tutorial because they provide instructions on how to use a tool or service in a step-by-step manner.
diff --git a/versioned_docs/version-1.0.0/concepts/what-are-keploy-features.md b/versioned_docs/version-1.0.0/concepts/what-are-keploy-features.md
index 5e08e1e8c..405df0c35 100644
--- a/versioned_docs/version-1.0.0/concepts/what-are-keploy-features.md
+++ b/versioned_docs/version-1.0.0/concepts/what-are-keploy-features.md
@@ -14,7 +14,7 @@ keywords:
Keploy captures all the API calls and subsequent network traffic served by the application. You can use any existing API management tools like Postman, curl to generate test-case.
-
+
### 2. Automatically mock Mutations
@@ -22,13 +22,13 @@ Keploy automatically [mocks](/concepts/general-glossary.md#1-api-data-mocking) n
Data dumps, stubs or mocks for dependencies like DBs, internal services, or third party services like twilio, shopify or stripe are **not required**.
-
+
Please check list of currently supported dependencies in [Go, Java and Node](https://keploy.io/#integrations).
Keploy can safely replay writes or mutations by capturing from local or other environments and replaying without API chaining.
-
+
[Idempotency](/concepts/general-glossary.md#2-idempotency) guarantees are also **not required** in the application. Multiple Reads after write operations can be replicated automatically too.
@@ -38,7 +38,7 @@ Keploy identifies [noisy fields](/concepts/general-glossary.md#3-noisy-field) in
As the application serves the API, Keploy re-run that API request with the captured dependency mocks.
-[//]: # '
'
+[//]: # '
'
Keploy then compares if the responses of the API requests disagree with each other.
If any of the fields of the API responses are different they are marked as random/non-deterministic fields.
@@ -49,7 +49,7 @@ Keploy has [native integrations](/concepts/general-glossary.md#4-interoperabilit
Code coverage will be reported with existing and Keploy recorded test cases and can also be integrated in
existing CI pipelines easily.
-
+
### 5. Easy Integration Framework for new Libraries
diff --git a/versioned_docs/version-1.0.0/gsoc/contribution-guide.md b/versioned_docs/version-1.0.0/gsoc/contribution-guide.md
index 127d64ae7..fbf197a69 100644
--- a/versioned_docs/version-1.0.0/gsoc/contribution-guide.md
+++ b/versioned_docs/version-1.0.0/gsoc/contribution-guide.md
@@ -22,7 +22,7 @@ Google pays the students, not the organizations they work with. Beginning in 202
You can read more about the format of the program and its goals [here](https://google.github.io/gsocguides/mentor/).
-
+
## Keploy X GSoC
diff --git a/versioned_docs/version-1.0.0/hacktoberfest/contribution-guide.md b/versioned_docs/version-1.0.0/hacktoberfest/contribution-guide.md
index d52f408d2..2faee9ef8 100644
--- a/versioned_docs/version-1.0.0/hacktoberfest/contribution-guide.md
+++ b/versioned_docs/version-1.0.0/hacktoberfest/contribution-guide.md
@@ -10,7 +10,7 @@ label: Hacktoberfest
Hacktoberfest is a month-long celebration of open-source software run by DigitalOcean. Hacktoberfest is open to everyone, from first-time contributors to seasoned open-source developers. Your open-source journey begins with a pull request.
-
+
## Hacktoberfest Journey with Keploy
diff --git a/versioned_docs/version-1.0.0/hacktoberfest/non-code.md b/versioned_docs/version-1.0.0/hacktoberfest/non-code.md
index 14c6510c2..091027983 100644
--- a/versioned_docs/version-1.0.0/hacktoberfest/non-code.md
+++ b/versioned_docs/version-1.0.0/hacktoberfest/non-code.md
@@ -8,8 +8,8 @@ label: Hacktoberfest
There are many ways to contribute to Keploy projects without writing a single line of code. You can help with:
-- Used Keploy recently ? Tell the community about it in an awesome blog post.
+-
Used Keploy recently ? Tell the community about it in an awesome blog post.
--
Improve Documentation as the more detailed the documentation is, better it will be for people who are looking for help.
+-
Improve Documentation as the more detailed the documentation is, better it will be for people who are looking for help.
--
Create a tutorial because they provide instructions on how to use a tool or service in a step-by-step manner.
+-
Create a tutorial because they provide instructions on how to use a tool or service in a step-by-step manner.
diff --git a/versioned_docs/version-2.0.0/concepts/platform-requirements.md b/versioned_docs/version-2.0.0/concepts/platform-requirements.md
index 36ed4bc99..b67a5ecf6 100644
--- a/versioned_docs/version-2.0.0/concepts/platform-requirements.md
+++ b/versioned_docs/version-2.0.0/concepts/platform-requirements.md
@@ -27,8 +27,8 @@ Linux:
| Operating System | Without Docker | Docker Installation | Prerequisites |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-|
**MacOS** | [Guide](/keploy-explained/mac-linux.md) | [Guide](/server/installation/) | - Docker Desktop version must be 4.25.2 or above
|
-| **Windows** |
|
| - Use [WSL](https://learn.microsoft.com/en-us/windows/wsl/install#install-wsl-command) `wsl --install`
- Windows 10 version 2004 and higher (Build 19041 and higher) or Windows 11 |
-|
**Linux** | |
| Linux kernel 5.15 or higher |
+|
**MacOS** | [Guide](/keploy-explained/mac-linux.md) | [Guide](/server/installation/) | - Docker Desktop version must be 4.25.2 or above
|
+| **Windows** |
|
| - Use [WSL](https://learn.microsoft.com/en-us/windows/wsl/install#install-wsl-command) `wsl --install`
- Windows 10 version 2004 and higher (Build 19041 and higher) or Windows 11 |
+|
**Linux** | |
| Linux kernel 5.15 or higher |
On MacOS and Windows, additional tools are required for Keploy due to the lack of native eBPF support.
diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/end-to-end-testing.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/end-to-end-testing.md
index 9f8d8b26e..7469e96dd 100644
--- a/versioned_docs/version-2.0.0/concepts/reference/glossary/end-to-end-testing.md
+++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/end-to-end-testing.md
@@ -45,7 +45,7 @@ Despite the challenges, E2E testing is an important part of the software develop
Keploy generate E2E API tests with built-in-mocks or stubs by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
### How Keploy works?
diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/microservice-testing.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/microservice-testing.md
index 96e839c32..03e820465 100644
--- a/versioned_docs/version-2.0.0/concepts/reference/glossary/microservice-testing.md
+++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/microservice-testing.md
@@ -41,7 +41,7 @@ Microservice testing is the process of validating individual components of a mic
## Overcoming Challenges with Keploy
Keploy is an innovative testing tool designed to address many of the challenges associated with microservices testing. Here's how it helps:
-
+
- **Automated Test Case Generation**: Keploy can generate test cases by recording your application's network calls. This automation significantly reduces the time and effort required to create comprehensive test suites.
diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/mocks.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/mocks.md
index dc0167a61..90ea14bbd 100644
--- a/versioned_docs/version-2.0.0/concepts/reference/glossary/mocks.md
+++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/mocks.md
@@ -36,6 +36,6 @@ Data mocks refer to the synthetic data that mimics real-world datasets, which is
Keploy can generate dependency mocks in addition to the testcases by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
Since these data mocks are generated based on the real-time capturing of API calls from your application, they will be from real-world scenarios. This can help to ensure that the data mocks are accurate and that it represents the real data as closely as possible. As well as, it makes the data maintenance process easier by providing a same environment for testing. This can help to identify the source of bugs more easily.
diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/stubs.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/stubs.md
index 29c3b5fda..a921cfa7c 100644
--- a/versioned_docs/version-2.0.0/concepts/reference/glossary/stubs.md
+++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/stubs.md
@@ -50,6 +50,6 @@ Overall, stubs are a valuable tool for software development and testing. They ca
Keploy can generate dependency stubs in addition to the testcases by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
Since the data stubs are generated based on the real-time capturing of API calls from your application, they will be from real-world scenarios. This can help to ensure that the mock data is accurate and that it represents the real data as closely as possible. As well as, it makes the data maintenance process easier by providing a same environment for testing. This can help to identify the source of bugs more easily.
diff --git a/versioned_docs/version-2.0.0/concepts/what-are-keploy-features.md b/versioned_docs/version-2.0.0/concepts/what-are-keploy-features.md
index a68da419e..8e53f8f3b 100644
--- a/versioned_docs/version-2.0.0/concepts/what-are-keploy-features.md
+++ b/versioned_docs/version-2.0.0/concepts/what-are-keploy-features.md
@@ -31,7 +31,7 @@ Keploy has [native integrations](/concepts/general-glossary.md#4-interoperabilit
like `go-test`, `jUnit`, `jest`, `pyTest`. Keploy gives combined test-coverage and can also be integrated in existing CI
pipelines easily within `go-test`, `jUnit`, `jest`, `pyTest` workflows.
-
+
Run tests with mocks anywhere you likeโ**locally on the CLI**, in your **CI pipeline**, or even across a **Kubernetes
cluster**. It's testing wherever you want it! ๐
@@ -49,7 +49,7 @@ favorite API management tools like Postman or even Curl to generate test cases.
Keploy automatically [mocks](/concepts/general-glossary.md#1-api-data-mocking) network/external dependencies for **all
CRUD operations** with correct responses.
-
+
Once recorded, you have the flexibility to replay and simulate the same flow with mutations/write calls locally or
within your CI environment without needing to connect to external services/dependencies.
@@ -57,12 +57,12 @@ within your CI environment without needing to connect to external services/depen
No more data dumps, stubs, or mocks for dependencies like DBs, internal services, or third-party services like twilio,
shopify, or stripe are required anymore. ๐ก
-
+
[Idempotency](/concepts/general-glossary.md#2-idempotency) guarantees are also **not required** in the application.
Multiple Reads after write operations can be replicated automatically too. ๐
-[//]: # '
'
+[//]: # '
'
## โป๏ธ Multi-Purpose Mocks
@@ -86,7 +86,7 @@ timestamps, random values) to ensure high quality tests.
As the application serves the API, Keploy re-run that API request with the captured dependency mocks.
-[//]: # '
'
+[//]: # '
'
Keploy identifies differences in API responses, marking them as random/noisy fields. ๐งโ
diff --git a/versioned_docs/version-2.0.0/concepts/what-is-keploy.md b/versioned_docs/version-2.0.0/concepts/what-is-keploy.md
index caff92cbf..365a66d49 100644
--- a/versioned_docs/version-2.0.0/concepts/what-is-keploy.md
+++ b/versioned_docs/version-2.0.0/concepts/what-is-keploy.md
@@ -22,7 +22,7 @@ keywords:
Keploy creates backend **API tests with built-in-mocks** or stubs **by recording your application network calls** making
your testing process not only faster than unit tests but also incredibly efficient.
-
+
Keploy acts a proxy in your application that captures and replays all network interaction served to application from any
source.
@@ -35,7 +35,7 @@ Now, when the application serves an API, all the unique network interactions are
test-case.
+
+
## Keploy X GSoC
diff --git a/versioned_docs/version-2.0.0/hacktoberfest/contribution-guide.md b/versioned_docs/version-2.0.0/hacktoberfest/contribution-guide.md
index a0b3fe9b2..53d648423 100644
--- a/versioned_docs/version-2.0.0/hacktoberfest/contribution-guide.md
+++ b/versioned_docs/version-2.0.0/hacktoberfest/contribution-guide.md
@@ -28,7 +28,7 @@ Anyone around the globe who desires to help drive the growth of open source and
#### Non-code contributions include:
--
+
Let's see what broke and fix it.
@@ -37,14 +37,14 @@ Let's see what broke and fix it.
keploy console
```
+
+
- Select the **latest** test report to make edits.
@@ -58,7 +58,7 @@ Edit test-cases locally using keploy console.
- โป๏ธ Re-Record Test Suite
- ๐๏ธ Delete Test Report
-
+
> โ๏ธ Note that the changes can be made by editing the latest test report only.
@@ -66,11 +66,11 @@ Edit test-cases locally using keploy console.
Noisy fields are ignored for assertion when the test-cases runs. Say, `Date` and `Content-Length` are two headers that are not static and can change with each request. We can mark these fields as noisy.
-
+
You'd see the changes in the test-case file locally, new noisy fields are added under noise param in the test case.
-
+
### Normalise Test Report or Test Case
diff --git a/versioned_docs/version-2.0.0/keploy-cloud/new-application.md b/versioned_docs/version-2.0.0/keploy-cloud/new-application.md
index 83c96b361..cc127babe 100644
--- a/versioned_docs/version-2.0.0/keploy-cloud/new-application.md
+++ b/versioned_docs/version-2.0.0/keploy-cloud/new-application.md
@@ -35,7 +35,7 @@ To add the new application to Keploy Cloud, you need to login to [Keploy Console
Now let's add the setup workflow. Add your application name and the setup workflow of the application. For example in the above screenshot you can see the setup workflow script for the [sample Go application](/docs/quickstart/samples-gin/).
-
.
+
.
### Step 3: Edit Keploy Configuration
diff --git a/versioned_docs/version-2.0.0/keploy-cloud/testgeneration.md b/versioned_docs/version-2.0.0/keploy-cloud/testgeneration.md
index 892d42c48..1a4a5a934 100644
--- a/versioned_docs/version-2.0.0/keploy-cloud/testgeneration.md
+++ b/versioned_docs/version-2.0.0/keploy-cloud/testgeneration.md
@@ -430,4 +430,4 @@ keploy generate-tests -c "java -jar
+
### ๐ช eBPF hooks loader
diff --git a/versioned_docs/version-2.0.0/quickstart/go-mux-sql.md b/versioned_docs/version-2.0.0/quickstart/go-mux-sql.md
index 5422fdfeb..6481ec294 100644
--- a/versioned_docs/version-2.0.0/quickstart/go-mux-sql.md
+++ b/versioned_docs/version-2.0.0/quickstart/go-mux-sql.md
@@ -367,7 +367,7 @@ Or simply wander over to your browser and visit `http://localhost:8010/products`
Did you spot the new test and mock scrolls in your project library? Awesome! ๐
-
+
### Run Tests ๐
diff --git a/versioned_docs/version-2.0.0/quickstart/java-spring-boot-mongo.md b/versioned_docs/version-2.0.0/quickstart/java-spring-boot-mongo.md
index 2deeb1c34..418053ff8 100644
--- a/versioned_docs/version-2.0.0/quickstart/java-spring-boot-mongo.md
+++ b/versioned_docs/version-2.0.0/quickstart/java-spring-boot-mongo.md
@@ -78,7 +78,7 @@ sudo mkdir -p /usr/local/bin && sudo mv /tmp/keploy /usr/local/bin && keploy
If everything goes right, your screen should look a bit like this:
-
+
## Run Application
diff --git a/versioned_docs/version-2.0.0/quickstart/java-spring-boot-openhospital.md b/versioned_docs/version-2.0.0/quickstart/java-spring-boot-openhospital.md
index d401d05cc..90c85c86b 100644
--- a/versioned_docs/version-2.0.0/quickstart/java-spring-boot-openhospital.md
+++ b/versioned_docs/version-2.0.0/quickstart/java-spring-boot-openhospital.md
@@ -76,7 +76,7 @@ Prerequisites For Binary:
keploy record -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.springframework.boot.loader.launch.JarLauncher"
```
-
+
## Start the frontend
@@ -88,7 +88,7 @@ npm start
```
Note: Login with username `admin` and password `admin`
-
+
If you followed all the steps correctly, you should see a UI similar to the one shown above.
@@ -104,10 +104,10 @@ keploy test -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.sp
๐ Hooray! You've made it to the end of the binary section! ๐
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-2.0.0/quickstart/java-spring-boot-xml.md b/versioned_docs/version-2.0.0/quickstart/java-spring-boot-xml.md
index fb5754473..7ee6f82cc 100644
--- a/versioned_docs/version-2.0.0/quickstart/java-spring-boot-xml.md
+++ b/versioned_docs/version-2.0.0/quickstart/java-spring-boot-xml.md
@@ -139,7 +139,7 @@ If you encounter failing tests due to variable or irrelevant data, like timestam
**Example:**
-
+
Now you can start interacting with the UI and Keploy will automatically create the testcases and mocks for it in a folder named 'keploy'.
@@ -132,7 +132,7 @@ Here we just need to change the command used to start the application.
keploy record -c "docker compose up" --container-name javaApp --build-delay 100
```
-
+
## Running the testcases using Keploy
@@ -141,10 +141,10 @@ keploy test -c "docker compose up" --container-name javaApp --build-delay 50 --d
```
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-2.0.0/quickstart/node-express-mongoose.md b/versioned_docs/version-2.0.0/quickstart/node-express-mongoose.md
index 69bda4e82..c0205995d 100644
--- a/versioned_docs/version-2.0.0/quickstart/node-express-mongoose.md
+++ b/versioned_docs/version-2.0.0/quickstart/node-express-mongoose.md
@@ -108,11 +108,11 @@ keploy test -c "docker compose up" --container-name "nodeMongoApp" --build-delay
Your results should be looking all _snazzy_, like this:
-
+
Worry not, just add the ever-changing fields (like our **ts** here) to the **noise parameter** to **dodge those assertions**.
-
+
### Wrapping it up ๐
@@ -181,7 +181,7 @@ Student registration successful!
๐ Woohoo! Give yourself a pat on the back! With that simple spell, you've conjured up a test case with a mock! Explore the **Keploy directory** and you'll discover your handiwork in `test-1.yml` and `mocks.yml`.
-
+
Now, the real fun begins. Let's weave more spells!
@@ -205,7 +205,7 @@ sudo -E env PATH=$PATH keploy test -c "node src/app.js" --delay 10
Worry not, just add the ever-changing fields (like our **ts** here) to the **noise parameter** to **dodge those assertions**.
-
+
### Wrapping it up ๐
diff --git a/versioned_docs/version-2.0.0/quickstart/node-jwt-sql.md b/versioned_docs/version-2.0.0/quickstart/node-jwt-sql.md
index a7a66fc04..4f8b78610 100644
--- a/versioned_docs/version-2.0.0/quickstart/node-jwt-sql.md
+++ b/versioned_docs/version-2.0.0/quickstart/node-jwt-sql.md
@@ -92,7 +92,7 @@ we will get the output:
We will get the following output in our terminal
-
+
Let's go ahead create few more testcases for different endpoints!
@@ -173,7 +173,7 @@ sudo -E env PATH=$PATH keploy test -c 'npm run app.js' --delay 10
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
-
+
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
@@ -187,7 +187,7 @@ But for this application, the Token expiration is 10 mins so let's go ahead and
Now, let's run the keploy in test mode again:-
-
+
### Wrapping it up ๐
@@ -235,7 +235,7 @@ we will get the output:
We will get the following output in our terminal
-
+
Let's go ahead create few more testcases for different endpoints!
@@ -315,7 +315,7 @@ keploy test -c 'sudo docker-compose up' --container-name "jwtSqlApp" --delay 10
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
-
+
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
@@ -328,7 +328,7 @@ But for this application, the Token expiration is 10 mins so let's go ahead and
Now, let's run the keploy in test mode again:-
-
+
### Wrapping it up ๐
diff --git a/versioned_docs/version-2.0.0/quickstart/sample-ts.md b/versioned_docs/version-2.0.0/quickstart/sample-ts.md
index ae17fec52..f95875074 100644
--- a/versioned_docs/version-2.0.0/quickstart/sample-ts.md
+++ b/versioned_docs/version-2.0.0/quickstart/sample-ts.md
@@ -208,7 +208,7 @@ We will run the keploy in record mode with docker-compose to start our applicati
keploy record -c "sudo docker-compose up" --containerName "ts-nhost"
```
-
+
### Generate the testcases
@@ -265,9 +265,9 @@ keploy test -c 'sudo docker-compose up' --containerName "ts-nhost" --delay 10
This is what your response should look like!
-
+
-
+
## Wrapping it up ๐
diff --git a/versioned_docs/version-2.0.0/quickstart/samples-go-gin-mongo.md b/versioned_docs/version-2.0.0/quickstart/samples-go-gin-mongo.md
index 775b6271b..dcd29cf75 100644
--- a/versioned_docs/version-2.0.0/quickstart/samples-go-gin-mongo.md
+++ b/versioned_docs/version-2.0.0/quickstart/samples-go-gin-mongo.md
@@ -58,7 +58,7 @@ keploy record -c "docker compose up" --container-name "ginMongoApp"
Getting logs like this? Perfect! ๐
-
+
๐ฅ Challenge time! Generate some test cases. How? Just **make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -176,7 +176,7 @@ Or just type `http://localhost:8080/Lhr4BWAi` in your browser. Your choice!
Spotted the new test and mock files in your project? High five! ๐
-
+
Want to see if everything works as expected?
@@ -192,7 +192,7 @@ keploy test -c "docker compose up" --container-name "ginMongoApp" --delay 10
Your results should be looking all _snazzy_, like this:
-
+
Did you spot that the ts (timestamp) is showing some differences? Yep, time has a way of doing that! ๐ฐ๏ธ
@@ -200,7 +200,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.ts` to noise in `test-x.yaml`.
-
+
Run that keploy record command once more and watch as everything falls into place with all tests passing!๐
@@ -226,7 +226,7 @@ wsl ~
First things first, update the MongoDB URL to `localhost:27017` on **line 21** of our trusty `main.go` file.
-
+
### ๐ Kickstart MongoDB
@@ -247,7 +247,7 @@ keploy record -c "go run main.go handler.go"
Keep an eye out for the `-c `flag! It's the command charm to run the app. Whether you're using `go run main.go handler.go` or the binary path like `./test-app-url-shortener`, it's your call.
If you're seeing logs that resemble the ones below, you're on the right track:
-
+
Alright! With the app alive and kicking, let's weave some test cases. Making some API calls! Postman, Hoppscotch, or the classic curl - pick your wand.
@@ -365,7 +365,7 @@ Or just type `http://localhost:8080/Lhr4BWAi` in your browser. Your choice!
Spotted the new test and mock files in your project? High five! ๐
-
+
Want to see if everything works as expected?
@@ -381,7 +381,7 @@ keploy test -c "docker compose up" --container-name "ginMongoApp" --delay 10
Your results should be looking all _snazzy_, like this:
-
+
Did you spot that the ts (timestamp) is showing some differences? Yep, time has a way of doing that! ๐ฐ๏ธ
@@ -389,7 +389,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.ts` to noise in `test-x.yaml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
diff --git a/versioned_docs/version-2.0.0/quickstart/samples-java.md b/versioned_docs/version-2.0.0/quickstart/samples-java.md
index 9909b6ae4..39376c476 100644
--- a/versioned_docs/version-2.0.0/quickstart/samples-java.md
+++ b/versioned_docs/version-2.0.0/quickstart/samples-java.md
@@ -205,7 +205,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.timestamp` to noise in `keploy.yml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
@@ -227,7 +227,7 @@ Here we just need to change the command used to start the application.
keploy record -c "docker compose up" --container-name javaApp --build-delay 100
```
-
+
Now let's run a few tests to capture some more scenarios:
@@ -281,10 +281,10 @@ keploy test -c "docker compose up" --container-name javaApp --build-delay 50 --d
```
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-2.0.0/quickstart/sanic-mongo.md b/versioned_docs/version-2.0.0/quickstart/sanic-mongo.md
index d0b6ef42b..69a2ed2b0 100644
--- a/versioned_docs/version-2.0.0/quickstart/sanic-mongo.md
+++ b/versioned_docs/version-2.0.0/quickstart/sanic-mongo.md
@@ -68,7 +68,7 @@ keploy record -c "python3 server.py"
You should be able to see this in your terminal
-
+
๐ฅ**Make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -158,6 +158,6 @@ spec:
This is how your terminal would look like :
-
+
You can experiment with different API calls, modify the database response in mocks.yml, or adjust the request or response in test-x.yml. Then, run the tests again to see the change in response
diff --git a/versioned_docs/version-2.0.0/running-keploy/docker-tls.md b/versioned_docs/version-2.0.0/running-keploy/docker-tls.md
index 9d3cb4d5b..fa90819b0 100644
--- a/versioned_docs/version-2.0.0/running-keploy/docker-tls.md
+++ b/versioned_docs/version-2.0.0/running-keploy/docker-tls.md
@@ -13,7 +13,7 @@ keywords:
- running-guide
---
-### Recording Testcases and Data Mocks
+
_Voila!! The Generated Testcases have provided with 58% coverage๐_
@@ -147,7 +147,7 @@ keploy gen --source-file-path="app.go" \
We will get following output : -
-
+
_Voila!! The Generated Testcases have provided with 71% coverage in just 2 iterations ๐_
diff --git a/versioned_docs/version-2.0.0/server/index.md b/versioned_docs/version-2.0.0/server/index.md
index 9d8246bda..912b8e80b 100644
--- a/versioned_docs/version-2.0.0/server/index.md
+++ b/versioned_docs/version-2.0.0/server/index.md
@@ -7,6 +7,6 @@ sidebar_label: Installation
Let's get Keploy up and running on your Windows, Linux, or macOS machine, so you can start crafting test cases in
minutes. โฑ๏ธ
-- [Windows](versioned_docs/version-2.0.0/server/windows/installation.md)
+
By generating additional tests that exercise different parts of your codebase, you can increase the percentage of code that is covered by your tests. For example, in case of NodeJS application you can use Jest. Jest provides a built-in code coverage tool that can help you measure the effectiveness of your tests and identify areas of the code that need additional testing. By adding Keploy SDK with Jest, you can easily generate test cases and increase your code coverage. Let's create a `Keploy.test.js`
diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/end-to-end-testing.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/end-to-end-testing.md
index 9f8d8b26e..7469e96dd 100644
--- a/versioned_docs/version-3.0.0/concepts/reference/glossary/end-to-end-testing.md
+++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/end-to-end-testing.md
@@ -45,7 +45,7 @@ Despite the challenges, E2E testing is an important part of the software develop
Keploy generate E2E API tests with built-in-mocks or stubs by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
### How Keploy works?
diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/microservice-testing.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/microservice-testing.md
index 96e839c32..03e820465 100644
--- a/versioned_docs/version-3.0.0/concepts/reference/glossary/microservice-testing.md
+++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/microservice-testing.md
@@ -41,7 +41,7 @@ Microservice testing is the process of validating individual components of a mic
## Overcoming Challenges with Keploy
Keploy is an innovative testing tool designed to address many of the challenges associated with microservices testing. Here's how it helps:
-
+
+
Since these data mocks are generated based on the real-time capturing of API calls from your application, they will be from real-world scenarios. This can help to ensure that the data mocks are accurate and that it represents the real data as closely as possible. As well as, it makes the data maintenance process easier by providing a same environment for testing. This can help to identify the source of bugs more easily.
diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/stubs.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/stubs.md
index 29c3b5fda..a921cfa7c 100644
--- a/versioned_docs/version-3.0.0/concepts/reference/glossary/stubs.md
+++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/stubs.md
@@ -50,6 +50,6 @@ Overall, stubs are a valuable tool for software development and testing. They ca
Keploy can generate dependency stubs in addition to the testcases by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
Since the data stubs are generated based on the real-time capturing of API calls from your application, they will be from real-world scenarios. This can help to ensure that the mock data is accurate and that it represents the real data as closely as possible. As well as, it makes the data maintenance process easier by providing a same environment for testing. This can help to identify the source of bugs more easily.
diff --git a/versioned_docs/version-3.0.0/concepts/what-are-keploy-features.md b/versioned_docs/version-3.0.0/concepts/what-are-keploy-features.md
index c3c5cdee3..d3e6c0746 100644
--- a/versioned_docs/version-3.0.0/concepts/what-are-keploy-features.md
+++ b/versioned_docs/version-3.0.0/concepts/what-are-keploy-features.md
@@ -32,7 +32,7 @@ Keploy has [native integrations](/concepts/general-glossary.md#4-interoperabilit
like `go-test`, `jUnit`, `jest`, `pyTest`. Keploy gives combined test-coverage and can also be integrated in existing CI
pipelines easily within `go-test`, `jUnit`, `jest`, `pyTest` workflows.
-
+
Run tests with mocks anywhere you likeโ**locally on the CLI**, in your **CI pipeline**, or even across a **Kubernetes
cluster**. It's testing wherever you want it! ๐
@@ -52,7 +52,7 @@ favorite API management tools like Postman or even Curl to generate test cases.
Keploy automatically [mocks](/concepts/general-glossary.md#1-api-data-mocking) network/external dependencies for **all
CRUD operations** with correct responses.
-
+
Once recorded, you have the flexibility to replay and simulate the same flow with mutations/write calls locally or
within your CI environment without needing to connect to external services/dependencies.
@@ -60,12 +60,12 @@ within your CI environment without needing to connect to external services/depen
No more data dumps, stubs, or mocks for dependencies like DBs, internal services, or third-party services like twilio,
shopify, or stripe are required anymore. ๐ก
-
+
[Idempotency](/concepts/general-glossary.md#2-idempotency) guarantees are also **not required** in the application.
Multiple Reads after write operations can be replicated automatically too. ๐
-[//]: # '
'
+[//]: # '
'
## โป๏ธ What are Keploy's multi-purpose mocks?
@@ -95,7 +95,7 @@ timestamps, random values) to ensure high quality tests.
As the application serves the API, Keploy re-run that API request with the captured dependency mocks.
-[//]: # '
'
+[//]: # '
'
Keploy identifies differences in API responses, marking them as random/noisy fields. ๐งโ
diff --git a/versioned_docs/version-3.0.0/concepts/what-is-keploy.md b/versioned_docs/version-3.0.0/concepts/what-is-keploy.md
index b7dc137b9..ed3217ed1 100644
--- a/versioned_docs/version-3.0.0/concepts/what-is-keploy.md
+++ b/versioned_docs/version-3.0.0/concepts/what-is-keploy.md
@@ -26,7 +26,7 @@ Keploy is an open-source, AI-powered testing agent that generates backend API te
Keploy creates backend **API tests with built-in-mocks** or stubs **by recording your application network calls** making
your testing process not only faster than unit tests but also incredibly efficient.
-
+
Keploy acts a proxy in your application that captures and replays all network interaction served to application from any
source.
@@ -39,7 +39,7 @@ Now, when the application serves an API, all the unique network interactions are
test-case.
+
+
## Keploy X GSoC
diff --git a/versioned_docs/version-3.0.0/hacktoberfest/contribution-guide.md b/versioned_docs/version-3.0.0/hacktoberfest/contribution-guide.md
index 8efbe4b43..ecd6a6402 100644
--- a/versioned_docs/version-3.0.0/hacktoberfest/contribution-guide.md
+++ b/versioned_docs/version-3.0.0/hacktoberfest/contribution-guide.md
@@ -28,7 +28,7 @@ Anyone around the globe who desires to help drive the growth of open source and
#### Non-code contributions include:
--
+
Let's see what broke and fix it.
@@ -41,14 +41,14 @@ Let's see what broke and fix it.
keploy console
```
+
+
- Select the **latest** test report to make edits.
@@ -62,7 +62,7 @@ Edit test-cases locally using keploy console.
- โป๏ธ Re-Record Test Suite
- ๐๏ธ Delete Test Report
-
+
> โ๏ธ Note that the changes can be made by editing the latest test report only.
@@ -70,11 +70,11 @@ Edit test-cases locally using keploy console.
Noisy fields are ignored for assertion when the test-cases runs. Say, `Date` and `Content-Length` are two headers that are not static and can change with each request. We can mark these fields as noisy.
-
+
You'd see the changes in the test-case file locally, new noisy fields are added under noise param in the test case.
-
+
### Normalise Test Report or Test Case
diff --git a/versioned_docs/version-3.0.0/keploy-cloud/new-application.md b/versioned_docs/version-3.0.0/keploy-cloud/new-application.md
index c5b1d1d3b..196152b0d 100644
--- a/versioned_docs/version-3.0.0/keploy-cloud/new-application.md
+++ b/versioned_docs/version-3.0.0/keploy-cloud/new-application.md
@@ -39,7 +39,7 @@ To add the new application to Keploy Cloud, you need to login to [Keploy Console
Now let's add the setup workflow. Add your application name and the setup workflow of the application. For example in the above screenshot you can see the setup workflow script for the [sample Go application](/docs/quickstart/samples-gin/).
-
.
+
.
### Step 3: Edit Keploy Configuration
diff --git a/versioned_docs/version-3.0.0/keploy-cloud/testgeneration.md b/versioned_docs/version-3.0.0/keploy-cloud/testgeneration.md
index 2bd23fb2a..e21c5a295 100644
--- a/versioned_docs/version-3.0.0/keploy-cloud/testgeneration.md
+++ b/versioned_docs/version-3.0.0/keploy-cloud/testgeneration.md
@@ -434,4 +434,4 @@ keploy generate-tests -c "java -jar
+
### ๐ช eBPF hooks loader
diff --git a/versioned_docs/version-3.0.0/quickstart/code-coverage.md b/versioned_docs/version-3.0.0/quickstart/code-coverage.md
index 562505d30..4b7befbc6 100644
--- a/versioned_docs/version-3.0.0/quickstart/code-coverage.md
+++ b/versioned_docs/version-3.0.0/quickstart/code-coverage.md
@@ -25,7 +25,7 @@ import TabItem from '@theme/TabItem';
Code coverage is a **metric that measures how much of your source code is executed while running automated tests**.
It helps teams understand the quality of their tests and identify untested areas of the codebase.
-
+
High code coverage does not always mean good tests, but it ensures that critical parts of your application are not left untested.
@@ -37,7 +37,7 @@ High code coverage does not always mean good tests, but it ensures that critical
Schema coverage measures how much of your **API schema** (endpoints, request/response fields, contracts) is exercised during testing.
-
+
- Ensures all API fields are validated at least once
- Detects missing test cases for optional/edge fields
@@ -61,7 +61,7 @@ Branch coverage measures whether **all possible paths (if/else, switch cases, lo
Statement coverage measures how many **individual lines/statements of code** are executed at least once during testing.
-
+
- Easier to achieve than branch coverage
- Provides a quick baseline of test completeness
diff --git a/versioned_docs/version-3.0.0/quickstart/go-fasthttp-postgres.md b/versioned_docs/version-3.0.0/quickstart/go-fasthttp-postgres.md
index 36b88d688..dfe398fd2 100644
--- a/versioned_docs/version-3.0.0/quickstart/go-fasthttp-postgres.md
+++ b/versioned_docs/version-3.0.0/quickstart/go-fasthttp-postgres.md
@@ -66,7 +66,7 @@ Keep an eye out for the `-c` flag! It's the command charm to run the app. Whethe
If you're seeing logs that resemble the ones below, you're on the right track:
-
+
Alright! With the app alive and kicking, let's weave some test cases. Making some API calls! Postman, Hoppscotch,
@@ -107,7 +107,7 @@ keploy test -c "./app" --delay 5
When all is said and done, your test results should look a little something like this:
-
+
Final thoughts? Dive deeper! Try different API calls, tweak the DB response in the `mocks.yml`, or fiddle with the request or response in `test-x.yml`. Run the tests again and see the magic unfold!
diff --git a/versioned_docs/version-3.0.0/quickstart/go-mux-mysql.md b/versioned_docs/version-3.0.0/quickstart/go-mux-mysql.md
index e60547df6..ffa13612a 100644
--- a/versioned_docs/version-3.0.0/quickstart/go-mux-mysql.md
+++ b/versioned_docs/version-3.0.0/quickstart/go-mux-mysql.md
@@ -161,7 +161,7 @@ go build -o main
sudo -E PATH=$PATH keploy record -c "./main"
```
-
+
### Generate testcases
@@ -211,7 +211,7 @@ No need to set up dependencies like MySQL or write mocks for your testing. The a
We will get output something like this:
+" alt="Sample Keploy test header" width="100%" style={{ borderRadius: '5px' }} loading="lazy" decoding="async"/>
### Wrapping it up ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/go-mux-sql.md b/versioned_docs/version-3.0.0/quickstart/go-mux-sql.md
index 0f9dc05ef..34d41b984 100644
--- a/versioned_docs/version-3.0.0/quickstart/go-mux-sql.md
+++ b/versioned_docs/version-3.0.0/quickstart/go-mux-sql.md
@@ -389,7 +389,7 @@ Or simply wander over to your browser and visit `http://localhost:8010/products`
Did you spot the new test and mock scrolls in your project library? Awesome! ๐
-
+
### Run Tests ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/java-spring-boot-openhospital.md b/versioned_docs/version-3.0.0/quickstart/java-spring-boot-openhospital.md
index db80fb926..fcfeff51d 100644
--- a/versioned_docs/version-3.0.0/quickstart/java-spring-boot-openhospital.md
+++ b/versioned_docs/version-3.0.0/quickstart/java-spring-boot-openhospital.md
@@ -79,7 +79,7 @@ Prerequisites For Binary:
keploy record -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.springframework.boot.loader.launch.JarLauncher"
```
-
+
## Start the frontend
@@ -92,7 +92,7 @@ npm start
```
Note: Login with username `admin` and password `admin`
-
+
If you followed all the steps correctly, you should see a UI similar to the one shown above.
@@ -108,10 +108,10 @@ keploy test -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.sp
๐ Hooray! You've made it to the end of the binary section! ๐
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-3.0.0/quickstart/java-spring-boot-xml.md b/versioned_docs/version-3.0.0/quickstart/java-spring-boot-xml.md
index 9dab7d810..2a3204177 100644
--- a/versioned_docs/version-3.0.0/quickstart/java-spring-boot-xml.md
+++ b/versioned_docs/version-3.0.0/quickstart/java-spring-boot-xml.md
@@ -119,7 +119,7 @@ If you encounter failing tests due to variable or irrelevant data, like timestam
**Example:**
-
+
```yaml
globalNoise:
@@ -132,7 +132,7 @@ globalNoise:
After updating `keploy.yml` with the above configuration, rerun your tests, and the issue should be resolved.
-
+
## Wrapping Up ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/java-spring-postgres.md b/versioned_docs/version-3.0.0/quickstart/java-spring-postgres.md
index 5bed7a5f5..e4c6270bd 100644
--- a/versioned_docs/version-3.0.0/quickstart/java-spring-postgres.md
+++ b/versioned_docs/version-3.0.0/quickstart/java-spring-postgres.md
@@ -104,7 +104,7 @@ docker run -e POSTGRES_USER=petclinic -e POSTGRES_PASSWORD=petclinic -e POSTGRES
keploy record -c "java -jar target/spring-petclinic-rest-3.0.2.jar"
```
-
+
Now you can start interacting with the UI and Keploy will automatically create the testcases and mocks for it in a folder named 'keploy'.
@@ -161,7 +161,7 @@ Prerequisites For API backend Binary:
keploy record -c "docker compose up" --container-name javaApp --build-delay 100
```
-
+
## Running the testcases using Keploy
@@ -170,10 +170,10 @@ keploy test -c "docker compose up" --container-name javaApp --build-delay 50 --d
```
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md b/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md
index 3b2fb44a2..b59652e89 100644
--- a/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md
+++ b/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md
@@ -111,7 +111,7 @@ kubectl get pods
Wait until all pods are in the **Running** state.
-
+
### 5. Access the Application
@@ -150,7 +150,7 @@ https://app.keploy.io
- Connect a new cluster
+" alt="Sample Keploy K8s proxy" width="100%" style={{ borderRadius: '5px' }} loading="lazy" decoding="async"/>
### 3. Configure Cluster Details
@@ -163,7 +163,7 @@ Provide the following information:
http://localhost:8080
```
-
+
This allows the Keploy Proxy to observe and record live traffic from your Kubernetes application.
@@ -173,7 +173,7 @@ Note: For this quickstart, I am running it locally. If you are running your appl
Once you have provided the cluster details, you can install the Keploy Proxy in your Kubernetes cluster using Helm.
-
+
### 5. Verify the Installation
@@ -185,7 +185,7 @@ Note: The Keploy Proxy will be installed in the `keploy` namespace.
kubectl get pods -n keploy
```
-
+
Note: You need to port-forward the Keploy Proxy when running this setup on a local machine.
@@ -197,55 +197,55 @@ kubectl port-forward -n keploy svc/k8s-proxy 8080:8080
Once the Keploy Proxy is installed, you can view the list of running pods in the dashboard.
-
+
### 7. Start Recording
You can start recording live traffic from any of your pods by clicking Start Recording. For this quickstart, the `apigateway` pod is used.
-
+
### 8. Keploy is ready to Capture Live Traffic
Send a request to your API Gateway pod, and Keploy will capture the traffic.
-
+
### 9. Record Live Traffic
Once you have sent a request to your API Gateway pod, you can see the live traffic being captured.
-
+
### 10. Stop Recording
Once you have sent a request to your API Gateway pod, you can stop recording by clicking Stop Recording. To view the list of recordings, navigate to the recordings page, where you can see the captured traffic.
-
+
### 11. Generate Tests using AI
Did you notice something interesting in the dashboard? Once you have recorded a test, you can use AI to increase coverage. To generate additional tests, click **Use AI for Tests**.
-
+
### 12. Verify the Generation settings
Once you click **Use AI for Tests**, you can view the generation settings.
-
+
### 13. Verify the Generation
Once initiated, you can see the AI start generating test cases from the recorded traffic. The recorded traffic is used as input to create additional test cases.
-
+
### 14. View the Test Cases
After test generation, you can view the total number of test suites categorized as accepted, buggy, and rejected.
-
+
### Conclusion
diff --git a/versioned_docs/version-3.0.0/quickstart/nextjs-postgres.md b/versioned_docs/version-3.0.0/quickstart/nextjs-postgres.md
index bf72505e6..a107f99fd 100644
--- a/versioned_docs/version-3.0.0/quickstart/nextjs-postgres.md
+++ b/versioned_docs/version-3.0.0/quickstart/nextjs-postgres.md
@@ -49,7 +49,7 @@ Ready, set, record! Here's how:
sudo -E env PATH=$PATH keploy record -c 'npm run dev'
```
-
+
Alright, magician! With the app alive and kicking, let's weave some test cases. The spell? Making some API calls!
@@ -82,7 +82,7 @@ This will return the response:
curl -X GET http://localhost:3000/api/users
```
-
+
Give yourself a pat on the back! With that simple spell, you've conjured up test cases with a mock! Explore the **Keploy directory** and you'll discover your handiwork in `test-1.yml` and `mocks.yml`.
@@ -96,7 +96,7 @@ Time to put things to the test ๐งช
sudo -E env PATH=$PATH keploy test -c "npm run dev" --delay 10
```
-
+
> The `--delay` flag? Oh, that's just giving your app a little breather (in seconds) before the test cases come knocking.
diff --git a/versioned_docs/version-3.0.0/quickstart/node-express-mongoose.md b/versioned_docs/version-3.0.0/quickstart/node-express-mongoose.md
index 0cdd64204..691bf9c4f 100644
--- a/versioned_docs/version-3.0.0/quickstart/node-express-mongoose.md
+++ b/versioned_docs/version-3.0.0/quickstart/node-express-mongoose.md
@@ -52,7 +52,7 @@ Fire up the application and mongoDB instance with Keploy. Keep an eye on the two
keploy record -c "docker compose up" --container-name "nodeMongoApp" --build-delay 50
```
-
+
๐ฅ Challenge time! Generate some test cases. How? Just **make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -99,11 +99,11 @@ Time to put things to the test ๐งช
keploy test -c "docker compose up" --container-name "nodeMongoApp" --build-delay 50 --delay 10
```
-
+
> The `--delay` flag? Oh, that's just giving your app a little breather (in seconds) before the test cases come knocking.
-
+
### Wrapping it up ๐
@@ -162,7 +162,7 @@ Ready, set, record! Here's how:
sudo -E env PATH=$PATH keploy record -c 'node src/app.js'
```
-
+
Keep an eye out for the `-c `flag! It's the command charm to run the app.
@@ -211,11 +211,11 @@ Ready to put your spells to the test?
sudo -E env PATH=$PATH keploy test -c "node src/app.js" --delay 10
```
-
+
output should look like
-
+
### Wrapping it up ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/node-jwt-sql.md b/versioned_docs/version-3.0.0/quickstart/node-jwt-sql.md
index d188c4242..c23dbba69 100644
--- a/versioned_docs/version-3.0.0/quickstart/node-jwt-sql.md
+++ b/versioned_docs/version-3.0.0/quickstart/node-jwt-sql.md
@@ -61,7 +61,7 @@ docker-compose up -d
sudo -E env PATH=$PATH keploy record -c 'node app.js'
```
-
+
### Let's Generate the testcases.
@@ -87,7 +87,7 @@ we will get the output:
We will get the following output in our terminal
-
+
Let's go ahead create few more testcases for different endpoints!
@@ -168,7 +168,7 @@ sudo -E env PATH=$PATH keploy test -c 'npm run app.js' --delay 10
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
-
+
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `keploy.yml` on line 21 under `globalNoise`. The file would look like:-
@@ -187,7 +187,7 @@ But for this application, the Token expiration is 10 mins so let's go ahead and
Now, let's run the keploy in test mode again:-
-
+
But wait โ one test is still failing due to the time-freezing. To try out the time-freezing feature, you can use Keploy Enterprise.
@@ -230,7 +230,7 @@ We will run the keploy in record mode with docker-compose to start our applicati
keploy record -c "docker compose up" --container-name "jwtSqlApp"
```
-
+
#### Let's generate the testcases.
@@ -256,7 +256,7 @@ we will get the output:
We will get the following output in our terminal
-
+
Let's go ahead create few more testcases for different endpoints!
@@ -336,7 +336,7 @@ keploy test -c 'sudo docker compose up' --container-name "jwtSqlApp" --delay 10
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
-
+
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `keploy.yml` on line 21 under `globalNoise`. The file would look like:-
@@ -355,7 +355,7 @@ But for this application, the Token expiration is 10 mins so let's go ahead and
Now, let's run the keploy in test mode again:-
-
+
But wait โ one test is still failing due to the time-freezing. To try out the time-freezing feature, you can use Keploy Enterprise.
diff --git a/versioned_docs/version-3.0.0/quickstart/python-microservices.md b/versioned_docs/version-3.0.0/quickstart/python-microservices.md
index f972b24c3..78d2b82d0 100644
--- a/versioned_docs/version-3.0.0/quickstart/python-microservices.md
+++ b/versioned_docs/version-3.0.0/quickstart/python-microservices.md
@@ -55,7 +55,7 @@ cd ecommerce_sample_app
_Note: You can view the **architecture diagram** of the application_
-
+
#### Start the Microservices
@@ -69,7 +69,7 @@ To start capturing API test cases, use the following command:
keploy record -c "docker compose up" --container-name="order_service" --build-delay 40 --path="./order_service" --config-path="./order_service"
```
-
+
Now the question arises how to make an API call? Weโve made it simple! You can just import the Postman collection and try sending an API call.
@@ -1053,49 +1053,49 @@ code={`
**Step 1: If youโve already downloaded the collection, upload it.**
-
+
**Step 2: After the upload is complete, you will see the Ecommerce Microservices collection in the left panel. Open the collection to continue.**
-
+
**Step 3: Before sending any requests, ensure you have generated a JWT token. Click on User Service. Use the Login API and enter the following credentials: `Username: admin` and `Password: admin123`. After a successful login, you will receive a JWT token. Copy the token and paste it into your Environment settings.**
-
+
-
+
**Step 4: We need to create a user before placing an order. So, create a user using the Create User API.**
-
+
**Step 5: Then, create an address for the user.**
-
+
**Step 6: Once youโre done creating the user details, letโs fetch the product details. This will be helpful when placing an order.**
-
+
**Step 7: Create an order, but before that, copy the mouse_id to place the order.**
-
+
**Step 8: You can verify it using the List Order API.**
-
+
**Step 9: Once youโve created an order, use the Payment API to pay for the order.**
-
+
**Step 10: You can use the Get Order API to check the status of your order.**
-
+
> _Note: You can see that Keploy only captures the network calls related to the order service. It canโt capture other network calls because we are recording only for the order service._
-
+
### Stop the Recording
@@ -1313,7 +1313,7 @@ Now, letโs run the tests that were automatically generated by Keploy. Use this
keploy test -c "docker compose up" --containerName="order_service" --delay 30 --path="./order_service" --config-path="./order_service"
```
-
+
The `--delay` flag gives the app a short pause (in seconds) before running the tests. After the tests finish, you can inspect the results and tweak the test data in the `mocks.yml` or `test-x.yml` files.
@@ -1323,31 +1323,31 @@ Keploy also helps you track **test coverage** for your app.
The coverage files will be generated automatically by Keploy. You can find those files in the coverage directory.Click on any one of the HTML files to see the test coverage.
-
+
**Let's see the overall coverage report:**
-
+
**Let's see the overall coverage report by functions:**
-
+
**Once youโve got the coverage, letโs check the test reports in the Keploy Dashboard.**
-
+
**Letโs take a look at the Test Reports section.**
-
+
**Now, letโs go to the individual Test Report section and review the output.**
-
+
**Two tests have failed โ letโs check why they failed.**
-
+
**From the dashboard, you can see the diff that explains why it failed.**
@@ -1365,17 +1365,17 @@ Use the following link to install the [Chrome Extension](https://chromewebstore.
**Also, please verify that the Keploy Chrome Extension is installed and running.**
-
+
Once done, Go to [Keploy Enterprise UI](https://app.keploy.io) to try out Keploy API Testing. Once you sign in, youโll see a dashboard like this:
-
+
After reaching this step, provide your application URL and the working cURL commands. If the e-commerce application isnโt already running, start it using `docker compose up`.
**Step 1: Let's provide the curl command in the import curl section**
-
+
Use the following cURL command to import:
@@ -1386,7 +1386,7 @@ curl --location --request POST 'http://localhost:8083/api/v1/orders/d08d8383-57c
**Step 2: Once you provide the input, you will see a response. This means we are able to reach your application and are now ready to generate tests. Weโre just performing a validation before generating the test cases.**
-
+
**Step 3: Next, itโs time to provide the input โ such as cURL commands, Postman collections, or an OpenAPI schema. Remember, the more input or content you provide, the better your test cases will be. For this demo, weโll use Postman collections and cURL commands.**
@@ -2361,7 +2361,7 @@ code={`
_Paste the collections in the postman collections section._
-
+
**Also copy the curl commands:**
@@ -2503,7 +2503,7 @@ curl --request GET \
_Paste the cURL commands in the cURL section._
-
+
**Also copy the openapi schema for the order service**
@@ -2753,43 +2753,43 @@ security:
_Also Paste the OpenAPI schema into the Schema Document section. Once completed, you will be able to view the schema coverage._
-
+
**Step 4: After providing the OpenAPI schema, cURL commands, and Postman collection, click the Generate API Tests button. Then, review and confirm the generation settings. In this example, the port is changed to 8083, which means the application gateway will run on port 8083 to access all services.**
-
+
**Step 5: After completing the previous steps, click the Generate API Test button to automatically create test cases for your application.**
-
+
**Step 6: You can see the test suites created by Keploy. Click on an individual test suite to view the request, response, and variables.**
-
+
**Step 7: To visualize the steps, click the Visualize button. This will display a visual representation of the test flow.**
-
+
**Step 8: One of the test suites is marked as buggy. This means our application has some issues that Keploy detected. If youโre sure itโs not actually buggy, you can mark it as โNot Buggy.**
-
+
**Step 9: After generating the test, click the Run Tests button to execute it. Ensure that Private Mode is turned on before running the tests.**
-
+
**Step 10: After completion, youโll be able to see the executed test results.**
-
+
**Step 11: To view detailed reports, including test run count, pass/fail status, and other insights, go to the Test Report section.**
-
+
**Step 12: To visualize analytics such as daily API test runs, test activity, and HTTP methods, navigate to the Dashboard section. It provides a complete overview of your testing insights.**
-
+
## Conclusion ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/sample-ts.md b/versioned_docs/version-3.0.0/quickstart/sample-ts.md
index 494fd5001..bf9366082 100644
--- a/versioned_docs/version-3.0.0/quickstart/sample-ts.md
+++ b/versioned_docs/version-3.0.0/quickstart/sample-ts.md
@@ -237,7 +237,7 @@ We will run the keploy in record mode with docker-compose to start our applicati
keploy record -c "sudo docker compose up" --containerName "ts-nhost"
```
-
+
### Generate the testcases
@@ -294,9 +294,9 @@ keploy test -c 'sudo docker compose up' --containerName "ts-nhost" --delay 10
This is what your response should look like!
-
+
-
+
## Wrapping it up ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/samples-echo.md b/versioned_docs/version-3.0.0/quickstart/samples-echo.md
index ee4bd8e61..033eb20a3 100644
--- a/versioned_docs/version-3.0.0/quickstart/samples-echo.md
+++ b/versioned_docs/version-3.0.0/quickstart/samples-echo.md
@@ -87,7 +87,7 @@ curl http://localhost:8082/GuwHCgoQ
Now both these API calls were captured as **editable** testcases and written to `keploy/tests` folder. The keploy directory would also have `mocks` file that contains all the outputs of postgres operations. Here's what the folder structure look like:
-
+
Now, let's see the magic! โจ๐ซ
@@ -103,7 +103,7 @@ keploy test -c "docker compose up" --container-name "echoApp" --build-delay 50 -
output should look like
-
+
So no need to setup fake database/apis like Postgres or write mocks for them. Keploy automatically mocks them and, **The application thinks it's talking to Postgres ๐**
@@ -153,7 +153,7 @@ go build -o echo-psql-url-shortener
sudo -E PATH=$PATH keploy record -c "./echo-psql-url-shortener"
```
-
+
### Generate testcases
@@ -203,7 +203,7 @@ The application thinks it's talking to postgres ๐
We will get output something like this:
-
+
### Wrapping it up ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/samples-go-gin-mongo.md b/versioned_docs/version-3.0.0/quickstart/samples-go-gin-mongo.md
index 068de8345..595eb36fe 100644
--- a/versioned_docs/version-3.0.0/quickstart/samples-go-gin-mongo.md
+++ b/versioned_docs/version-3.0.0/quickstart/samples-go-gin-mongo.md
@@ -50,7 +50,7 @@ keploy record -c "docker compose up" --container-name "ginMongoApp"
Getting logs like this? Perfect! ๐
-
+
๐ฅ Challenge time! Generate some test cases. How? Just **make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -168,7 +168,7 @@ Or just type `http://localhost:8080/Lhr4BWAi` in your browser. Your choice!
Spotted the new test and mock files in your project? High five! ๐
-
+
Want to see if everything works as expected?
@@ -184,7 +184,7 @@ keploy test -c "docker compose up" --container-name "ginMongoApp" --delay 10
Your results should be looking all _snazzy_, like this:
-
+
Did you spot that the ts (timestamp) is showing some differences? Yep, time has a way of doing that! ๐ฐ๏ธ
@@ -192,7 +192,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.ts` to noise in `test-x.yaml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
@@ -231,7 +231,7 @@ wsl ~
First things first, update the MongoDB URL to `localhost:27017` on **line 21** of our trusty `main.go` file.
-
+
### ๐ Kickstart MongoDB
@@ -368,7 +368,7 @@ Or just type `http://localhost:8080/Lhr4BWAi` in your browser. Your choice!
Spotted the new test and mock files in your project? High five! ๐
-
+
Want to see if everything works as expected?
@@ -390,7 +390,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.ts` to noise in `test-x.yaml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
diff --git a/versioned_docs/version-3.0.0/quickstart/samples-java.md b/versioned_docs/version-3.0.0/quickstart/samples-java.md
index 63e909dec..47fba3042 100644
--- a/versioned_docs/version-3.0.0/quickstart/samples-java.md
+++ b/versioned_docs/version-3.0.0/quickstart/samples-java.md
@@ -204,7 +204,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.timestamp` to noise in `keploy.yml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
@@ -240,7 +240,7 @@ mvn clean install -Dmaven.test.skip=true
keploy record -c "docker compose up" --container-name javaApp --build-delay 100
```
-
+
Now let's run a few tests to capture some more scenarios:
@@ -294,10 +294,10 @@ keploy test -c "docker compose up" --container-name javaApp --build-delay 50 --d
```
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-3.0.0/quickstart/sanic-mongo.md b/versioned_docs/version-3.0.0/quickstart/sanic-mongo.md
index bf98e5d99..786a94d2b 100644
--- a/versioned_docs/version-3.0.0/quickstart/sanic-mongo.md
+++ b/versioned_docs/version-3.0.0/quickstart/sanic-mongo.md
@@ -70,7 +70,7 @@ keploy record -c "python3 server.py"
You should be able to see this in your terminal
-
+
๐ฅ**Make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -160,6 +160,6 @@ spec:
This is how your terminal would look like :
-
+
You can experiment with different API calls, modify the database response in mocks.yml, or adjust the request or response in test-x.yml. Then, run the tests again to see the change in response
diff --git a/versioned_docs/version-3.0.0/running-keploy/api-testing-chrome-extension.md b/versioned_docs/version-3.0.0/running-keploy/api-testing-chrome-extension.md
index 587c8e4ec..b6ad11c03 100644
--- a/versioned_docs/version-3.0.0/running-keploy/api-testing-chrome-extension.md
+++ b/versioned_docs/version-3.0.0/running-keploy/api-testing-chrome-extension.md
@@ -9,7 +9,7 @@ import ProductTier from '@site/src/components/ProductTier';
+
Install the extension, hit **Record API Calls**, exercise your web app, then press **Generate Tests** to send the captured traffic to Keploy.
@@ -35,7 +35,7 @@ Install the extension, hit **Record API Calls**, exercise your web app, then pre
## Quick-start workflow
-
+
1. **Log in** with the same email you use on app.keploy.io.
2. Click **Record API Calls**.
diff --git a/versioned_docs/version-3.0.0/running-keploy/api-testing-tool-ai-powered.md b/versioned_docs/version-3.0.0/running-keploy/api-testing-tool-ai-powered.md
index b88f9868c..8ed16e7e4 100644
--- a/versioned_docs/version-3.0.0/running-keploy/api-testing-tool-ai-powered.md
+++ b/versioned_docs/version-3.0.0/running-keploy/api-testing-tool-ai-powered.md
@@ -43,7 +43,7 @@ keywords:
## ๐ Keploy's API Test Generator
-
+
AI-powered testing engine that turns your API specs or traffic into stable, end-to-end test suites โ no scripts, mocks, or manual setup required.
@@ -63,7 +63,7 @@ Every test includes:
- Deduplication and flaky test detection
- Self-healing for minor API changes
-
+
Whether you're a developer, SDET, or QA manager โ Keploy helps you increase test coverage, reduce test debt, and ensure reliable releases across environments.
@@ -106,6 +106,6 @@ Keploy supports multiple ways to generate test cases depending on the API access
Keploy is built with security-first principles and is compliant with major industry standards:
-
+
Your data and test traffic are handled securely, with the option to run Keploy entirely within your network using our self-hosted agent or BYOLLM infrastructure. To Learn more on our [security page](https://trust.keploy.io).
diff --git a/versioned_docs/version-3.0.0/running-keploy/docker-tls.md b/versioned_docs/version-3.0.0/running-keploy/docker-tls.md
index 3132303a3..8eaef7317 100644
--- a/versioned_docs/version-3.0.0/running-keploy/docker-tls.md
+++ b/versioned_docs/version-3.0.0/running-keploy/docker-tls.md
@@ -17,7 +17,7 @@ import ProductTier from '@site/src/components/ProductTier';
+
Click on **Add**.
@@ -43,7 +43,7 @@ Choose:
- **All repositories** if you want the functionality across your GitHub organization.
- Authorize the app to complete the installation.
-
+
### Step 2. Make a Code Change and Open a Pull Request
@@ -53,7 +53,7 @@ Once the app is installed:
- Push your changes and **create a pull request (PR)** as usual.
- The **Keploy PR Agent** will automatically detect the changes and leave a comment on the PR.
-
+
### Step 3. Trigger Unit Test Generation
@@ -63,7 +63,7 @@ In the PR comment left by Keploy:
- You will be redirected to the Keploy service, where the unit test generation process begins.
- The PR Agent uses code semantics and the power of LLMs to understand your code changes and generate meaningful unit tests.
-
+
### Step 4. View the Generated Tests and Summary
@@ -74,7 +74,7 @@ Once the process is complete:
- All the **unit test files** generated for your recent changes.
- A **test summary** presented in a **clean tabular format** showing: - File names - Number of test cases - Coverage details - Edge cases handled (if any)
-
+
You can review, modify, or directly merge the PR with complete confidence that your changes are well-tested.
With Keploy PR Agent, testing is no longer a bottleneck - itโs built right into your workflow.
diff --git a/versioned_docs/version-3.0.0/running-keploy/utg-vsc-extension.md b/versioned_docs/version-3.0.0/running-keploy/utg-vsc-extension.md
index deffc6f11..f95d12840 100644
--- a/versioned_docs/version-3.0.0/running-keploy/utg-vsc-extension.md
+++ b/versioned_docs/version-3.0.0/running-keploy/utg-vsc-extension.md
@@ -52,7 +52,7 @@ You can install the Keploy extension using either of the following methods:
- Click **Install**.
-
+
**Method 2: Direct Link / VS Code Marketplace**
@@ -60,7 +60,7 @@ You can install the Keploy extension using either of the following methods:
- Click **Install** and follow the prompts to open it in VS Code.
-
+
### 2. Generate Unit Tests in a Single Click
@@ -71,7 +71,7 @@ Once the extension is installed:
3. Youโll see a simple interface with a button labeled **โGenerate Unit Tests.โ**
4. Click the button - thatโs it!
-
+
Keploy will analyze your codebase and automatically generate all relevant unit test files, covering:
@@ -89,7 +89,7 @@ After clicking **Generate Unit Tests**, Keploy will:
- Provide complete test coverage with little to no boilerplate code.
-
+
All tests are:
diff --git a/versioned_docs/version-3.0.0/server/index.md b/versioned_docs/version-3.0.0/server/index.md
index 9d8246bda..912b8e80b 100644
--- a/versioned_docs/version-3.0.0/server/index.md
+++ b/versioned_docs/version-3.0.0/server/index.md
@@ -7,6 +7,6 @@ sidebar_label: Installation
Let's get Keploy up and running on your Windows, Linux, or macOS machine, so you can start crafting test cases in
minutes. โฑ๏ธ
-- [Windows](versioned_docs/version-2.0.0/server/windows/installation.md)
+
By generating additional tests that exercise different parts of your codebase, you can increase the percentage of code that is covered by your tests. For example, in case of NodeJS application you can use Jest. Jest provides a built-in code coverage tool that can help you measure the effectiveness of your tests and identify areas of the code that need additional testing. By adding Keploy SDK with Jest, you can easily generate test cases and increase your code coverage. Let's create a `Keploy.test.js`
diff --git a/versioned_docs/version-4.0.0/concepts/reference/glossary/end-to-end-testing.md b/versioned_docs/version-4.0.0/concepts/reference/glossary/end-to-end-testing.md
index 9f8d8b26e..7469e96dd 100644
--- a/versioned_docs/version-4.0.0/concepts/reference/glossary/end-to-end-testing.md
+++ b/versioned_docs/version-4.0.0/concepts/reference/glossary/end-to-end-testing.md
@@ -45,7 +45,7 @@ Despite the challenges, E2E testing is an important part of the software develop
Keploy generate E2E API tests with built-in-mocks or stubs by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
### How Keploy works?
diff --git a/versioned_docs/version-4.0.0/concepts/reference/glossary/microservice-testing.md b/versioned_docs/version-4.0.0/concepts/reference/glossary/microservice-testing.md
index 96e839c32..03e820465 100644
--- a/versioned_docs/version-4.0.0/concepts/reference/glossary/microservice-testing.md
+++ b/versioned_docs/version-4.0.0/concepts/reference/glossary/microservice-testing.md
@@ -41,7 +41,7 @@ Microservice testing is the process of validating individual components of a mic
## Overcoming Challenges with Keploy
Keploy is an innovative testing tool designed to address many of the challenges associated with microservices testing. Here's how it helps:
-
+
+
Since these data mocks are generated based on the real-time capturing of API calls from your application, they will be from real-world scenarios. This can help to ensure that the data mocks are accurate and that it represents the real data as closely as possible. As well as, it makes the data maintenance process easier by providing a same environment for testing. This can help to identify the source of bugs more easily.
diff --git a/versioned_docs/version-4.0.0/concepts/reference/glossary/stubs.md b/versioned_docs/version-4.0.0/concepts/reference/glossary/stubs.md
index 29c3b5fda..a921cfa7c 100644
--- a/versioned_docs/version-4.0.0/concepts/reference/glossary/stubs.md
+++ b/versioned_docs/version-4.0.0/concepts/reference/glossary/stubs.md
@@ -50,6 +50,6 @@ Overall, stubs are a valuable tool for software development and testing. They ca
Keploy can generate dependency stubs in addition to the testcases by recording your application network calls making your testing process not only faster than unit tests but also incredibly efficient.
-
+
Since the data stubs are generated based on the real-time capturing of API calls from your application, they will be from real-world scenarios. This can help to ensure that the mock data is accurate and that it represents the real data as closely as possible. As well as, it makes the data maintenance process easier by providing a same environment for testing. This can help to identify the source of bugs more easily.
diff --git a/versioned_docs/version-4.0.0/concepts/what-are-keploy-features.md b/versioned_docs/version-4.0.0/concepts/what-are-keploy-features.md
index 9b91bcc87..8637ee58d 100644
--- a/versioned_docs/version-4.0.0/concepts/what-are-keploy-features.md
+++ b/versioned_docs/version-4.0.0/concepts/what-are-keploy-features.md
@@ -42,7 +42,7 @@ Keploy has [native integrations](/concepts/general-glossary.md#4-interoperabilit
like `go-test`, `jUnit`, `jest`, `pyTest`. Keploy gives combined test-coverage and can also be integrated in existing CI
pipelines easily within `go-test`, `jUnit`, `jest`, `pyTest` workflows.
-
+
Run tests with mocks anywhere you likeโ**locally on the CLI**, in your **CI pipeline**, or even across a **Kubernetes
cluster**. It's testing wherever you want it! ๐
@@ -60,7 +60,7 @@ favorite API management tools like Postman or even Curl to generate test cases.
Keploy automatically [mocks](/concepts/general-glossary.md#1-api-data-mocking) network/external dependencies for **all
CRUD operations** with correct responses.
-
+
Once recorded, you have the flexibility to replay and simulate the same flow with mutations/write calls locally or
within your CI environment without needing to connect to external services/dependencies.
@@ -68,12 +68,12 @@ within your CI environment without needing to connect to external services/depen
No more data dumps, stubs, or mocks for dependencies like DBs, internal services, or third-party services like twilio,
shopify, or stripe are required anymore. ๐ก
-
+
[Idempotency](/concepts/general-glossary.md#2-idempotency) guarantees are also **not required** in the application.
Multiple Reads after write operations can be replicated automatically too. ๐
-[//]: # '
'
+[//]: # '
'
## โป๏ธ Multi-Purpose Mocks
@@ -97,7 +97,7 @@ timestamps, random values) to ensure high quality tests.
As the application serves the API, Keploy re-run that API request with the captured dependency mocks.
-[//]: # '
'
+[//]: # '
'
Keploy identifies differences in API responses, marking them as random/noisy fields. ๐งโ
diff --git a/versioned_docs/version-4.0.0/concepts/what-is-keploy.md b/versioned_docs/version-4.0.0/concepts/what-is-keploy.md
index fc5b9032b..f3961bb18 100644
--- a/versioned_docs/version-4.0.0/concepts/what-is-keploy.md
+++ b/versioned_docs/version-4.0.0/concepts/what-is-keploy.md
@@ -36,7 +36,7 @@ Keploy is an open-source, AI-powered testing agent and sandboxing platform that
Keploy creates backend **API tests with built-in-mocks** or stubs **by recording your application network calls** making
your testing process not only faster than unit tests but also incredibly efficient.
-
+
Keploy acts a proxy in your application that captures and replays all network interaction served to application from any
source.
@@ -49,7 +49,7 @@ Now, when the application serves an API, all the unique network interactions are
test-case.
+
+
## Keploy X GSoC
diff --git a/versioned_docs/version-4.0.0/hacktoberfest/contribution-guide.md b/versioned_docs/version-4.0.0/hacktoberfest/contribution-guide.md
index 933ea050f..6f0190a2b 100644
--- a/versioned_docs/version-4.0.0/hacktoberfest/contribution-guide.md
+++ b/versioned_docs/version-4.0.0/hacktoberfest/contribution-guide.md
@@ -29,7 +29,7 @@ Anyone around the globe who desires to help drive the growth of open source and
#### Non-code contributions include:
--
+
Let's see what broke and fix it.
@@ -42,14 +42,14 @@ Let's see what broke and fix it.
keploy console
```
+
+
- Select the **latest** test report to make edits.
@@ -63,7 +63,7 @@ Edit test-cases locally using keploy console.
- โป๏ธ Re-Record Test Suite
- ๐๏ธ Delete Test Report
-
+
> โ๏ธ Note that the changes can be made by editing the latest test report only.
@@ -71,11 +71,11 @@ Edit test-cases locally using keploy console.
Noisy fields are ignored for assertion when the test-cases runs. Say, `Date` and `Content-Length` are two headers that are not static and can change with each request. We can mark these fields as noisy.
-
+
You'd see the changes in the test-case file locally, new noisy fields are added under noise param in the test case.
-
+
### Normalise Test Report or Test Case
diff --git a/versioned_docs/version-4.0.0/keploy-cloud/new-application.md b/versioned_docs/version-4.0.0/keploy-cloud/new-application.md
index c5b1d1d3b..196152b0d 100644
--- a/versioned_docs/version-4.0.0/keploy-cloud/new-application.md
+++ b/versioned_docs/version-4.0.0/keploy-cloud/new-application.md
@@ -39,7 +39,7 @@ To add the new application to Keploy Cloud, you need to login to [Keploy Console
Now let's add the setup workflow. Add your application name and the setup workflow of the application. For example in the above screenshot you can see the setup workflow script for the [sample Go application](/docs/quickstart/samples-gin/).
-
.
+
.
### Step 3: Edit Keploy Configuration
diff --git a/versioned_docs/version-4.0.0/keploy-cloud/testgeneration.md b/versioned_docs/version-4.0.0/keploy-cloud/testgeneration.md
index 07f1cc5ee..98da6f45f 100644
--- a/versioned_docs/version-4.0.0/keploy-cloud/testgeneration.md
+++ b/versioned_docs/version-4.0.0/keploy-cloud/testgeneration.md
@@ -435,4 +435,4 @@ keploy generate-tests -c "java -jar
+
### ๐ช eBPF hooks loader
diff --git a/versioned_docs/version-4.0.0/quickstart/code-coverage.md b/versioned_docs/version-4.0.0/quickstart/code-coverage.md
index 24abcb386..fb8d3969c 100644
--- a/versioned_docs/version-4.0.0/quickstart/code-coverage.md
+++ b/versioned_docs/version-4.0.0/quickstart/code-coverage.md
@@ -25,7 +25,7 @@ import TabItem from '@theme/TabItem';
Code coverage is a **metric that measures how much of your source code is executed while running automated tests**.
It helps teams understand the quality of their tests and identify untested areas of the codebase.
-
+
High code coverage does not always mean good tests, but it ensures that critical parts of your application are not left untested.
@@ -37,7 +37,7 @@ High code coverage does not always mean good tests, but it ensures that critical
Schema coverage measures how much of your **API schema** (endpoints, request/response fields, contracts) is exercised during testing.
-
+
- Ensures all API fields are validated at least once
- Detects missing test cases for optional/edge fields
@@ -61,7 +61,7 @@ Branch coverage measures whether **all possible paths (if/else, switch cases, lo
Statement coverage measures how many **individual lines/statements of code** are executed at least once during testing.
-
+
- Easier to achieve than branch coverage
- Provides a quick baseline of test completeness
diff --git a/versioned_docs/version-4.0.0/quickstart/go-fasthttp-postgres.md b/versioned_docs/version-4.0.0/quickstart/go-fasthttp-postgres.md
index 48291e50a..226e2f3ce 100644
--- a/versioned_docs/version-4.0.0/quickstart/go-fasthttp-postgres.md
+++ b/versioned_docs/version-4.0.0/quickstart/go-fasthttp-postgres.md
@@ -66,7 +66,7 @@ Keep an eye out for the `-c` flag! It's the command charm to run the app. Whethe
If you're seeing logs that resemble the ones below, you're on the right track:
-
+
Alright! With the app alive and kicking, let's weave some test cases. Making some API calls! Postman, Hoppscotch,
@@ -107,7 +107,7 @@ keploy test -c "./app" --delay 5
When all is said and done, your test results should look a little something like this:
-
+
Final thoughts? Dive deeper! Try different API calls, tweak the DB response in the `mocks.yml`, or fiddle with the request or response in `test-x.yml`. Run the tests again and see the magic unfold!
diff --git a/versioned_docs/version-4.0.0/quickstart/go-mux-mysql.md b/versioned_docs/version-4.0.0/quickstart/go-mux-mysql.md
index 88b313c26..5e267c5da 100644
--- a/versioned_docs/version-4.0.0/quickstart/go-mux-mysql.md
+++ b/versioned_docs/version-4.0.0/quickstart/go-mux-mysql.md
@@ -161,7 +161,7 @@ go build -o main
sudo -E PATH=$PATH keploy record -c "./main"
```
-
+
### Generate testcases
@@ -211,7 +211,7 @@ No need to set up dependencies like MySQL or write mocks for your testing. The a
We will get output something like this:
+" alt="Sample Keploy test header" width="100%" style={{ borderRadius: '5px' }} loading="lazy" decoding="async"/>
### Wrapping it up ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/go-mux-sql.md b/versioned_docs/version-4.0.0/quickstart/go-mux-sql.md
index 83498fbc4..0eb8b8444 100644
--- a/versioned_docs/version-4.0.0/quickstart/go-mux-sql.md
+++ b/versioned_docs/version-4.0.0/quickstart/go-mux-sql.md
@@ -389,7 +389,7 @@ Or simply wander over to your browser and visit `http://localhost:8010/products`
Did you spot the new test and mock scrolls in your project library? Awesome! ๐
-
+
### Run Tests ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/java-spring-boot-openhospital.md b/versioned_docs/version-4.0.0/quickstart/java-spring-boot-openhospital.md
index db80fb926..fcfeff51d 100644
--- a/versioned_docs/version-4.0.0/quickstart/java-spring-boot-openhospital.md
+++ b/versioned_docs/version-4.0.0/quickstart/java-spring-boot-openhospital.md
@@ -79,7 +79,7 @@ Prerequisites For Binary:
keploy record -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.springframework.boot.loader.launch.JarLauncher"
```
-
+
## Start the frontend
@@ -92,7 +92,7 @@ npm start
```
Note: Login with username `admin` and password `admin`
-
+
If you followed all the steps correctly, you should see a UI similar to the one shown above.
@@ -108,10 +108,10 @@ keploy test -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.sp
๐ Hooray! You've made it to the end of the binary section! ๐
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-4.0.0/quickstart/java-spring-boot-xml.md b/versioned_docs/version-4.0.0/quickstart/java-spring-boot-xml.md
index 9dab7d810..2a3204177 100644
--- a/versioned_docs/version-4.0.0/quickstart/java-spring-boot-xml.md
+++ b/versioned_docs/version-4.0.0/quickstart/java-spring-boot-xml.md
@@ -119,7 +119,7 @@ If you encounter failing tests due to variable or irrelevant data, like timestam
**Example:**
-
+
```yaml
globalNoise:
@@ -132,7 +132,7 @@ globalNoise:
After updating `keploy.yml` with the above configuration, rerun your tests, and the issue should be resolved.
-
+
## Wrapping Up ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/java-spring-postgres.md b/versioned_docs/version-4.0.0/quickstart/java-spring-postgres.md
index 5bed7a5f5..e4c6270bd 100644
--- a/versioned_docs/version-4.0.0/quickstart/java-spring-postgres.md
+++ b/versioned_docs/version-4.0.0/quickstart/java-spring-postgres.md
@@ -104,7 +104,7 @@ docker run -e POSTGRES_USER=petclinic -e POSTGRES_PASSWORD=petclinic -e POSTGRES
keploy record -c "java -jar target/spring-petclinic-rest-3.0.2.jar"
```
-
+
Now you can start interacting with the UI and Keploy will automatically create the testcases and mocks for it in a folder named 'keploy'.
@@ -161,7 +161,7 @@ Prerequisites For API backend Binary:
keploy record -c "docker compose up" --container-name javaApp --build-delay 100
```
-
+
## Running the testcases using Keploy
@@ -170,10 +170,10 @@ keploy test -c "docker compose up" --container-name javaApp --build-delay 50 --d
```
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-4.0.0/quickstart/k8s-proxy.md b/versioned_docs/version-4.0.0/quickstart/k8s-proxy.md
index 3b2fb44a2..b59652e89 100644
--- a/versioned_docs/version-4.0.0/quickstart/k8s-proxy.md
+++ b/versioned_docs/version-4.0.0/quickstart/k8s-proxy.md
@@ -111,7 +111,7 @@ kubectl get pods
Wait until all pods are in the **Running** state.
-
+
### 5. Access the Application
@@ -150,7 +150,7 @@ https://app.keploy.io
- Connect a new cluster
+" alt="Sample Keploy K8s proxy" width="100%" style={{ borderRadius: '5px' }} loading="lazy" decoding="async"/>
### 3. Configure Cluster Details
@@ -163,7 +163,7 @@ Provide the following information:
http://localhost:8080
```
-
+
This allows the Keploy Proxy to observe and record live traffic from your Kubernetes application.
@@ -173,7 +173,7 @@ Note: For this quickstart, I am running it locally. If you are running your appl
Once you have provided the cluster details, you can install the Keploy Proxy in your Kubernetes cluster using Helm.
-
+
### 5. Verify the Installation
@@ -185,7 +185,7 @@ Note: The Keploy Proxy will be installed in the `keploy` namespace.
kubectl get pods -n keploy
```
-
+
Note: You need to port-forward the Keploy Proxy when running this setup on a local machine.
@@ -197,55 +197,55 @@ kubectl port-forward -n keploy svc/k8s-proxy 8080:8080
Once the Keploy Proxy is installed, you can view the list of running pods in the dashboard.
-
+
### 7. Start Recording
You can start recording live traffic from any of your pods by clicking Start Recording. For this quickstart, the `apigateway` pod is used.
-
+
### 8. Keploy is ready to Capture Live Traffic
Send a request to your API Gateway pod, and Keploy will capture the traffic.
-
+
### 9. Record Live Traffic
Once you have sent a request to your API Gateway pod, you can see the live traffic being captured.
-
+
### 10. Stop Recording
Once you have sent a request to your API Gateway pod, you can stop recording by clicking Stop Recording. To view the list of recordings, navigate to the recordings page, where you can see the captured traffic.
-
+
### 11. Generate Tests using AI
Did you notice something interesting in the dashboard? Once you have recorded a test, you can use AI to increase coverage. To generate additional tests, click **Use AI for Tests**.
-
+
### 12. Verify the Generation settings
Once you click **Use AI for Tests**, you can view the generation settings.
-
+
### 13. Verify the Generation
Once initiated, you can see the AI start generating test cases from the recorded traffic. The recorded traffic is used as input to create additional test cases.
-
+
### 14. View the Test Cases
After test generation, you can view the total number of test suites categorized as accepted, buggy, and rejected.
-
+
### Conclusion
diff --git a/versioned_docs/version-4.0.0/quickstart/nextjs-postgres.md b/versioned_docs/version-4.0.0/quickstart/nextjs-postgres.md
index bf72505e6..a107f99fd 100644
--- a/versioned_docs/version-4.0.0/quickstart/nextjs-postgres.md
+++ b/versioned_docs/version-4.0.0/quickstart/nextjs-postgres.md
@@ -49,7 +49,7 @@ Ready, set, record! Here's how:
sudo -E env PATH=$PATH keploy record -c 'npm run dev'
```
-
+
Alright, magician! With the app alive and kicking, let's weave some test cases. The spell? Making some API calls!
@@ -82,7 +82,7 @@ This will return the response:
curl -X GET http://localhost:3000/api/users
```
-
+
Give yourself a pat on the back! With that simple spell, you've conjured up test cases with a mock! Explore the **Keploy directory** and you'll discover your handiwork in `test-1.yml` and `mocks.yml`.
@@ -96,7 +96,7 @@ Time to put things to the test ๐งช
sudo -E env PATH=$PATH keploy test -c "npm run dev" --delay 10
```
-
+
> The `--delay` flag? Oh, that's just giving your app a little breather (in seconds) before the test cases come knocking.
diff --git a/versioned_docs/version-4.0.0/quickstart/node-express-mongoose.md b/versioned_docs/version-4.0.0/quickstart/node-express-mongoose.md
index 5f182b9e4..ff4454e60 100644
--- a/versioned_docs/version-4.0.0/quickstart/node-express-mongoose.md
+++ b/versioned_docs/version-4.0.0/quickstart/node-express-mongoose.md
@@ -52,7 +52,7 @@ Fire up the application and mongoDB instance with Keploy. Keep an eye on the two
keploy record -c "docker compose up" --container-name "nodeMongoApp" --build-delay 50
```
-
+
๐ฅ Challenge time! Generate some test cases. How? Just **make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -99,11 +99,11 @@ Time to put things to the test ๐งช
keploy test -c "docker compose up" --container-name "nodeMongoApp" --build-delay 50 --delay 10
```
-
+
> The `--delay` flag? Oh, that's just giving your app a little breather (in seconds) before the test cases come knocking.
-
+
### Wrapping it up ๐
@@ -162,7 +162,7 @@ Ready, set, record! Here's how:
sudo -E env PATH=$PATH keploy record -c 'node src/app.js'
```
-
+
Keep an eye out for the `-c `flag! It's the command charm to run the app.
@@ -211,11 +211,11 @@ Ready to put your spells to the test?
sudo -E env PATH=$PATH keploy test -c "node src/app.js" --delay 10
```
-
+
output should look like
-
+
### Wrapping it up ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/node-jwt-sql.md b/versioned_docs/version-4.0.0/quickstart/node-jwt-sql.md
index d188c4242..c23dbba69 100644
--- a/versioned_docs/version-4.0.0/quickstart/node-jwt-sql.md
+++ b/versioned_docs/version-4.0.0/quickstart/node-jwt-sql.md
@@ -61,7 +61,7 @@ docker-compose up -d
sudo -E env PATH=$PATH keploy record -c 'node app.js'
```
-
+
### Let's Generate the testcases.
@@ -87,7 +87,7 @@ we will get the output:
We will get the following output in our terminal
-
+
Let's go ahead create few more testcases for different endpoints!
@@ -168,7 +168,7 @@ sudo -E env PATH=$PATH keploy test -c 'npm run app.js' --delay 10
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
-
+
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `keploy.yml` on line 21 under `globalNoise`. The file would look like:-
@@ -187,7 +187,7 @@ But for this application, the Token expiration is 10 mins so let's go ahead and
Now, let's run the keploy in test mode again:-
-
+
But wait โ one test is still failing due to the time-freezing. To try out the time-freezing feature, you can use Keploy Enterprise.
@@ -230,7 +230,7 @@ We will run the keploy in record mode with docker-compose to start our applicati
keploy record -c "docker compose up" --container-name "jwtSqlApp"
```
-
+
#### Let's generate the testcases.
@@ -256,7 +256,7 @@ we will get the output:
We will get the following output in our terminal
-
+
Let's go ahead create few more testcases for different endpoints!
@@ -336,7 +336,7 @@ keploy test -c 'sudo docker compose up' --container-name "jwtSqlApp" --delay 10
Our testcases will fail as the token would expire and new Token will generated again when we are using testmode. To make sure that testcases do not fail, we have use [timeFreezing](https://keploy.io/docs/keploy-cloud/time-freezing/).
-
+
But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `keploy.yml` on line 21 under `globalNoise`. The file would look like:-
@@ -355,7 +355,7 @@ But for this application, the Token expiration is 10 mins so let's go ahead and
Now, let's run the keploy in test mode again:-
-
+
But wait โ one test is still failing due to the time-freezing. To try out the time-freezing feature, you can use Keploy Enterprise.
diff --git a/versioned_docs/version-4.0.0/quickstart/python-microservices.md b/versioned_docs/version-4.0.0/quickstart/python-microservices.md
index f972b24c3..78d2b82d0 100644
--- a/versioned_docs/version-4.0.0/quickstart/python-microservices.md
+++ b/versioned_docs/version-4.0.0/quickstart/python-microservices.md
@@ -55,7 +55,7 @@ cd ecommerce_sample_app
_Note: You can view the **architecture diagram** of the application_
-
+
#### Start the Microservices
@@ -69,7 +69,7 @@ To start capturing API test cases, use the following command:
keploy record -c "docker compose up" --container-name="order_service" --build-delay 40 --path="./order_service" --config-path="./order_service"
```
-
+
Now the question arises how to make an API call? Weโve made it simple! You can just import the Postman collection and try sending an API call.
@@ -1053,49 +1053,49 @@ code={`
**Step 1: If youโve already downloaded the collection, upload it.**
-
+
**Step 2: After the upload is complete, you will see the Ecommerce Microservices collection in the left panel. Open the collection to continue.**
-
+
**Step 3: Before sending any requests, ensure you have generated a JWT token. Click on User Service. Use the Login API and enter the following credentials: `Username: admin` and `Password: admin123`. After a successful login, you will receive a JWT token. Copy the token and paste it into your Environment settings.**
-
+
-
+
**Step 4: We need to create a user before placing an order. So, create a user using the Create User API.**
-
+
**Step 5: Then, create an address for the user.**
-
+
**Step 6: Once youโre done creating the user details, letโs fetch the product details. This will be helpful when placing an order.**
-
+
**Step 7: Create an order, but before that, copy the mouse_id to place the order.**
-
+
**Step 8: You can verify it using the List Order API.**
-
+
**Step 9: Once youโve created an order, use the Payment API to pay for the order.**
-
+
**Step 10: You can use the Get Order API to check the status of your order.**
-
+
> _Note: You can see that Keploy only captures the network calls related to the order service. It canโt capture other network calls because we are recording only for the order service._
-
+
### Stop the Recording
@@ -1313,7 +1313,7 @@ Now, letโs run the tests that were automatically generated by Keploy. Use this
keploy test -c "docker compose up" --containerName="order_service" --delay 30 --path="./order_service" --config-path="./order_service"
```
-
+
The `--delay` flag gives the app a short pause (in seconds) before running the tests. After the tests finish, you can inspect the results and tweak the test data in the `mocks.yml` or `test-x.yml` files.
@@ -1323,31 +1323,31 @@ Keploy also helps you track **test coverage** for your app.
The coverage files will be generated automatically by Keploy. You can find those files in the coverage directory.Click on any one of the HTML files to see the test coverage.
-
+
**Let's see the overall coverage report:**
-
+
**Let's see the overall coverage report by functions:**
-
+
**Once youโve got the coverage, letโs check the test reports in the Keploy Dashboard.**
-
+
**Letโs take a look at the Test Reports section.**
-
+
**Now, letโs go to the individual Test Report section and review the output.**
-
+
**Two tests have failed โ letโs check why they failed.**
-
+
**From the dashboard, you can see the diff that explains why it failed.**
@@ -1365,17 +1365,17 @@ Use the following link to install the [Chrome Extension](https://chromewebstore.
**Also, please verify that the Keploy Chrome Extension is installed and running.**
-
+
Once done, Go to [Keploy Enterprise UI](https://app.keploy.io) to try out Keploy API Testing. Once you sign in, youโll see a dashboard like this:
-
+
After reaching this step, provide your application URL and the working cURL commands. If the e-commerce application isnโt already running, start it using `docker compose up`.
**Step 1: Let's provide the curl command in the import curl section**
-
+
Use the following cURL command to import:
@@ -1386,7 +1386,7 @@ curl --location --request POST 'http://localhost:8083/api/v1/orders/d08d8383-57c
**Step 2: Once you provide the input, you will see a response. This means we are able to reach your application and are now ready to generate tests. Weโre just performing a validation before generating the test cases.**
-
+
**Step 3: Next, itโs time to provide the input โ such as cURL commands, Postman collections, or an OpenAPI schema. Remember, the more input or content you provide, the better your test cases will be. For this demo, weโll use Postman collections and cURL commands.**
@@ -2361,7 +2361,7 @@ code={`
_Paste the collections in the postman collections section._
-
+
**Also copy the curl commands:**
@@ -2503,7 +2503,7 @@ curl --request GET \
_Paste the cURL commands in the cURL section._
-
+
**Also copy the openapi schema for the order service**
@@ -2753,43 +2753,43 @@ security:
_Also Paste the OpenAPI schema into the Schema Document section. Once completed, you will be able to view the schema coverage._
-
+
**Step 4: After providing the OpenAPI schema, cURL commands, and Postman collection, click the Generate API Tests button. Then, review and confirm the generation settings. In this example, the port is changed to 8083, which means the application gateway will run on port 8083 to access all services.**
-
+
**Step 5: After completing the previous steps, click the Generate API Test button to automatically create test cases for your application.**
-
+
**Step 6: You can see the test suites created by Keploy. Click on an individual test suite to view the request, response, and variables.**
-
+
**Step 7: To visualize the steps, click the Visualize button. This will display a visual representation of the test flow.**
-
+
**Step 8: One of the test suites is marked as buggy. This means our application has some issues that Keploy detected. If youโre sure itโs not actually buggy, you can mark it as โNot Buggy.**
-
+
**Step 9: After generating the test, click the Run Tests button to execute it. Ensure that Private Mode is turned on before running the tests.**
-
+
**Step 10: After completion, youโll be able to see the executed test results.**
-
+
**Step 11: To view detailed reports, including test run count, pass/fail status, and other insights, go to the Test Report section.**
-
+
**Step 12: To visualize analytics such as daily API test runs, test activity, and HTTP methods, navigate to the Dashboard section. It provides a complete overview of your testing insights.**
-
+
## Conclusion ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/sample-ts.md b/versioned_docs/version-4.0.0/quickstart/sample-ts.md
index 494fd5001..bf9366082 100644
--- a/versioned_docs/version-4.0.0/quickstart/sample-ts.md
+++ b/versioned_docs/version-4.0.0/quickstart/sample-ts.md
@@ -237,7 +237,7 @@ We will run the keploy in record mode with docker-compose to start our applicati
keploy record -c "sudo docker compose up" --containerName "ts-nhost"
```
-
+
### Generate the testcases
@@ -294,9 +294,9 @@ keploy test -c 'sudo docker compose up' --containerName "ts-nhost" --delay 10
This is what your response should look like!
-
+
-
+
## Wrapping it up ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/samples-echo.md b/versioned_docs/version-4.0.0/quickstart/samples-echo.md
index dd0742cdc..c21b3f716 100644
--- a/versioned_docs/version-4.0.0/quickstart/samples-echo.md
+++ b/versioned_docs/version-4.0.0/quickstart/samples-echo.md
@@ -87,7 +87,7 @@ curl http://localhost:8082/GuwHCgoQ
Now both these API calls were captured as **editable** testcases and written to `keploy/tests` folder. The keploy directory would also have `mocks` file that contains all the outputs of postgres operations. Here's what the folder structure look like:
-
+
Now, let's see the magic! โจ๐ซ
@@ -103,7 +103,7 @@ keploy test -c "docker compose up" --container-name "echoApp" --build-delay 50 -
output should look like
-
+
So no need to setup fake database/apis like Postgres or write mocks for them. Keploy automatically mocks them and, **The application thinks it's talking to Postgres ๐**
@@ -153,7 +153,7 @@ go build -o echo-psql-url-shortener
sudo -E PATH=$PATH keploy record -c "./echo-psql-url-shortener"
```
-
+
### Generate testcases
@@ -203,7 +203,7 @@ The application thinks it's talking to postgres ๐
We will get output something like this:
-
+
### Wrapping it up ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/samples-go-gin-mongo.md b/versioned_docs/version-4.0.0/quickstart/samples-go-gin-mongo.md
index 262e6d63c..887e038b7 100644
--- a/versioned_docs/version-4.0.0/quickstart/samples-go-gin-mongo.md
+++ b/versioned_docs/version-4.0.0/quickstart/samples-go-gin-mongo.md
@@ -50,7 +50,7 @@ keploy record -c "docker compose up" --container-name "ginMongoApp"
Getting logs like this? Perfect! ๐
-
+
๐ฅ Challenge time! Generate some test cases. How? Just **make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -168,7 +168,7 @@ Or just type `http://localhost:8080/Lhr4BWAi` in your browser. Your choice!
Spotted the new test and mock files in your project? High five! ๐
-
+
Want to see if everything works as expected?
@@ -184,7 +184,7 @@ keploy test -c "docker compose up" --container-name "ginMongoApp" --delay 10
Your results should be looking all _snazzy_, like this:
-
+
Did you spot that the ts (timestamp) is showing some differences? Yep, time has a way of doing that! ๐ฐ๏ธ
@@ -192,7 +192,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.ts` to noise in `test-x.yaml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
@@ -231,7 +231,7 @@ wsl ~
First things first, update the MongoDB URL to `localhost:27017` on **line 21** of our trusty `main.go` file.
-
+
### ๐ Kickstart MongoDB
@@ -368,7 +368,7 @@ Or just type `http://localhost:8080/Lhr4BWAi` in your browser. Your choice!
Spotted the new test and mock files in your project? High five! ๐
-
+
Want to see if everything works as expected?
@@ -390,7 +390,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.ts` to noise in `test-x.yaml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
diff --git a/versioned_docs/version-4.0.0/quickstart/samples-java.md b/versioned_docs/version-4.0.0/quickstart/samples-java.md
index 63e909dec..47fba3042 100644
--- a/versioned_docs/version-4.0.0/quickstart/samples-java.md
+++ b/versioned_docs/version-4.0.0/quickstart/samples-java.md
@@ -204,7 +204,7 @@ Worry not, just add the ever-changing fields (like our **ts** here) to the **noi
> Pro tip: Add `body.timestamp` to noise in `keploy.yml`.
-
+
Run that `keploy test` command once more and watch as everything falls into place with all tests passing! ๐
@@ -240,7 +240,7 @@ mvn clean install -Dmaven.test.skip=true
keploy record -c "docker compose up" --container-name javaApp --build-delay 100
```
-
+
Now let's run a few tests to capture some more scenarios:
@@ -294,10 +294,10 @@ keploy test -c "docker compose up" --container-name javaApp --build-delay 50 --d
```
Your CLI should look something like this
-
+
This is a summary of the test cases recorded
-
+
Here `delay` is the time it takes for your application to get started, after which Keploy will start running the testcases. If your application takes longer than 10s to get started, you can change the `delay` accordingly.
`buildDelay` is the time that it takes for the image to get built. This is useful when you are building the docker image from your docker compose file itself.
diff --git a/versioned_docs/version-4.0.0/quickstart/sanic-mongo.md b/versioned_docs/version-4.0.0/quickstart/sanic-mongo.md
index bf98e5d99..786a94d2b 100644
--- a/versioned_docs/version-4.0.0/quickstart/sanic-mongo.md
+++ b/versioned_docs/version-4.0.0/quickstart/sanic-mongo.md
@@ -70,7 +70,7 @@ keploy record -c "python3 server.py"
You should be able to see this in your terminal
-
+
๐ฅ**Make some API calls**. Postman, Hoppscotch or even curl - take your pick!
@@ -160,6 +160,6 @@ spec:
This is how your terminal would look like :
-
+
You can experiment with different API calls, modify the database response in mocks.yml, or adjust the request or response in test-x.yml. Then, run the tests again to see the change in response
diff --git a/versioned_docs/version-4.0.0/running-keploy/api-testing-chrome-extension.md b/versioned_docs/version-4.0.0/running-keploy/api-testing-chrome-extension.md
index 64c8f8dcb..ba1cf2029 100644
--- a/versioned_docs/version-4.0.0/running-keploy/api-testing-chrome-extension.md
+++ b/versioned_docs/version-4.0.0/running-keploy/api-testing-chrome-extension.md
@@ -9,7 +9,7 @@ import ProductTier from '@site/src/components/ProductTier';
+
Install the extension, hit **Record API Calls**, exercise your web app, then press **Generate Tests** to send the captured traffic to Keploy.
@@ -35,7 +35,7 @@ Install the extension, hit **Record API Calls**, exercise your web app, then pre
## Quick-start workflow
-
+
1. **Log in** with the same email you use on app.keploy.io.
2. Click **Record API Calls**.
diff --git a/versioned_docs/version-4.0.0/running-keploy/api-testing-tool-ai-powered.md b/versioned_docs/version-4.0.0/running-keploy/api-testing-tool-ai-powered.md
index b88f9868c..8ed16e7e4 100644
--- a/versioned_docs/version-4.0.0/running-keploy/api-testing-tool-ai-powered.md
+++ b/versioned_docs/version-4.0.0/running-keploy/api-testing-tool-ai-powered.md
@@ -43,7 +43,7 @@ keywords:
## ๐ Keploy's API Test Generator
-
+
AI-powered testing engine that turns your API specs or traffic into stable, end-to-end test suites โ no scripts, mocks, or manual setup required.
@@ -63,7 +63,7 @@ Every test includes:
- Deduplication and flaky test detection
- Self-healing for minor API changes
-
+
Whether you're a developer, SDET, or QA manager โ Keploy helps you increase test coverage, reduce test debt, and ensure reliable releases across environments.
@@ -106,6 +106,6 @@ Keploy supports multiple ways to generate test cases depending on the API access
Keploy is built with security-first principles and is compliant with major industry standards:
-
+
Your data and test traffic are handled securely, with the option to run Keploy entirely within your network using our self-hosted agent or BYOLLM infrastructure. To Learn more on our [security page](https://trust.keploy.io).
diff --git a/versioned_docs/version-4.0.0/running-keploy/docker-tls.md b/versioned_docs/version-4.0.0/running-keploy/docker-tls.md
index 3132303a3..8eaef7317 100644
--- a/versioned_docs/version-4.0.0/running-keploy/docker-tls.md
+++ b/versioned_docs/version-4.0.0/running-keploy/docker-tls.md
@@ -17,7 +17,7 @@ import ProductTier from '@site/src/components/ProductTier';
+
Click on **Add**.
@@ -43,7 +43,7 @@ Choose:
- **All repositories** if you want the functionality across your GitHub organization.
- Authorize the app to complete the installation.
-
+
### Step 2. Make a Code Change and Open a Pull Request
@@ -53,7 +53,7 @@ Once the app is installed:
- Push your changes and **create a pull request (PR)** as usual.
- The **Keploy PR Agent** will automatically detect the changes and leave a comment on the PR.
-
+
### Step 3. Trigger Unit Test Generation
@@ -63,7 +63,7 @@ In the PR comment left by Keploy:
- You will be redirected to the Keploy service, where the unit test generation process begins.
- The PR Agent uses code semantics and the power of LLMs to understand your code changes and generate meaningful unit tests.
-
+
### Step 4. View the Generated Tests and Summary
@@ -74,7 +74,7 @@ Once the process is complete:
- All the **unit test files** generated for your recent changes.
- A **test summary** presented in a **clean tabular format** showing: - File names - Number of test cases - Coverage details - Edge cases handled (if any)
-
+
You can review, modify, or directly merge the PR with complete confidence that your changes are well-tested.
With Keploy PR Agent, testing is no longer a bottleneck - itโs built right into your workflow.
diff --git a/versioned_docs/version-4.0.0/running-keploy/utg-vsc-extension.md b/versioned_docs/version-4.0.0/running-keploy/utg-vsc-extension.md
index deffc6f11..f95d12840 100644
--- a/versioned_docs/version-4.0.0/running-keploy/utg-vsc-extension.md
+++ b/versioned_docs/version-4.0.0/running-keploy/utg-vsc-extension.md
@@ -52,7 +52,7 @@ You can install the Keploy extension using either of the following methods:
- Click **Install**.
-
+
**Method 2: Direct Link / VS Code Marketplace**
@@ -60,7 +60,7 @@ You can install the Keploy extension using either of the following methods:
- Click **Install** and follow the prompts to open it in VS Code.
-
+
### 2. Generate Unit Tests in a Single Click
@@ -71,7 +71,7 @@ Once the extension is installed:
3. Youโll see a simple interface with a button labeled **โGenerate Unit Tests.โ**
4. Click the button - thatโs it!
-
+
Keploy will analyze your codebase and automatically generate all relevant unit test files, covering:
@@ -89,7 +89,7 @@ After clicking **Generate Unit Tests**, Keploy will:
- Provide complete test coverage with little to no boilerplate code.
-
+
All tests are:
diff --git a/versioned_docs/version-4.0.0/server/index.md b/versioned_docs/version-4.0.0/server/index.md
index a929b81a7..6f6e23718 100644
--- a/versioned_docs/version-4.0.0/server/index.md
+++ b/versioned_docs/version-4.0.0/server/index.md
@@ -8,6 +8,6 @@ description: "Get Keploy installed on Windows, Linux, or macOS โ choose your p
Let's get Keploy up and running on your Windows, Linux, or macOS machine, so you can start crafting test cases in
minutes. โฑ๏ธ
-- [Windows](versioned_docs/version-2.0.0/server/windows/installation.md)