diff --git a/docs/gsoc/contribution-guide.md b/docs/gsoc/contribution-guide.md
index a1a02f131..0bc8bd658 100644
--- a/docs/gsoc/contribution-guide.md
+++ b/docs/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/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/docusaurus.config.js b/docusaurus.config.js
index 25647b78a..5befb2ba0 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -53,7 +53,8 @@ module.exports = {
{name: "twitter:card", content: "summary_large_image"},
],
headTags: [
- // Preconnect tag
+ // ── Preconnect / DNS-prefetch for critical third-party origins ─────
+ // Keploy CDN
{
tagName: "link",
attributes: {
@@ -61,6 +62,53 @@ module.exports = {
href: "https://keploy.io/",
},
},
+ // Google Fonts (used by Docusaurus default theme)
+ {
+ tagName: "link",
+ attributes: {
+ rel: "preconnect",
+ href: "https://fonts.googleapis.com",
+ },
+ },
+ {
+ tagName: "link",
+ attributes: {
+ rel: "preconnect",
+ href: "https://fonts.gstatic.com",
+ crossorigin: "anonymous",
+ },
+ },
+ // Algolia search
+ {
+ tagName: "link",
+ attributes: {
+ rel: "preconnect",
+ href: "https://WZTL8PLCOD-dsn.algolia.net",
+ crossorigin: "anonymous",
+ },
+ },
+ // Analytics (dns-prefetch only — not render-blocking)
+ {
+ tagName: "link",
+ attributes: {
+ rel: "dns-prefetch",
+ href: "https://www.clarity.ms",
+ },
+ },
+ {
+ tagName: "link",
+ attributes: {
+ rel: "dns-prefetch",
+ href: "https://www.googletagmanager.com",
+ },
+ },
+ {
+ tagName: "link",
+ attributes: {
+ rel: "dns-prefetch",
+ href: "https://www.google-analytics.com",
+ },
+ },
{
tagName: "script",
attributes: {
diff --git a/netlify.toml b/netlify.toml
index 1c7d06f69..5e68b2a6b 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -8,3 +8,43 @@
## Note: if you are looking for Redirects
# they have been moved to /static/_redirects to make it more manageable - swyx
+
+# ── Performance: Cache headers ────────────────────────────────────────────────
+# Hashed JS/CSS bundles emitted by Docusaurus/webpack → safe to cache 1 year
+[[headers]]
+ for = "/assets/*"
+ [headers.values]
+ Cache-Control = "public, max-age=31536000, immutable"
+
+# Static images served from /img
+[[headers]]
+ for = "/img/*"
+ [headers.values]
+ Cache-Control = "public, max-age=86400, stale-while-revalidate=604800"
+
+# Fonts are NOT content-hashed (e.g. Roboto-Bold.woff2) so immutable is unsafe.
+# Use a 1-week cache with stale-while-revalidate instead.
+[[headers]]
+ for = "/fonts/*"
+ [headers.values]
+ Cache-Control = "public, max-age=604800, stale-while-revalidate=86400"
+
+# Static JS helpers (non-hashed scripts in /docs/js and /docs/scripts)
+[[headers]]
+ for = "/js/*"
+ [headers.values]
+ Cache-Control = "public, max-age=86400"
+
+[[headers]]
+ for = "/scripts/*"
+ [headers.values]
+ Cache-Control = "public, max-age=86400"
+
+# ── Security headers (improves PageSpeed Best Practices score) ──────────────
+[[headers]]
+ for = "/*"
+ [headers.values]
+ X-Frame-Options = "SAMEORIGIN"
+ X-Content-Type-Options = "nosniff"
+ Referrer-Policy = "strict-origin-when-cross-origin"
+ Permissions-Policy = "camera=(), microphone=(), geolocation=()"
diff --git a/src/components/responsive-player/ResponsivePlayer.js b/src/components/responsive-player/ResponsivePlayer.js
index d08af04c3..cfc543d82 100644
--- a/src/components/responsive-player/ResponsivePlayer.js
+++ b/src/components/responsive-player/ResponsivePlayer.js
@@ -1,5 +1,9 @@
-import React from "react";
-import ReactPlayer from "react-player";
+import React, {Suspense, lazy} from "react";
+
+// Lazy-load react-player so it is NOT included in the initial JS bundle.
+// react-player/lazy defers loading the actual player implementation until
+// the component is rendered, reducing the first-page-load JS payload.
+const ReactPlayer = lazy(() => import("react-player/lazy"));
function ResponsivePlayer({url, loop, playing}) {
return (
@@ -7,16 +11,29 @@ function ResponsivePlayer({url, loop, playing}) {
className="relative rounded-lg shadow-lg"
style={{paddingTop: "56.25%"}}
>
- {/* /* Player ratio: 100 / (1280 / 720) */}
-
without an explicit loading attribute
+ * should at minimum decode off the main thread.
+ */
+img:not([loading]) {
+ decoding: async;
+}
+
+/*
+ * Reduce paint layers for the announcement bar (it's a position:sticky
+ * element and can cause extra compositing cost on mobile).
+ * Using attribute substring selector to avoid relying on a hashed class name
+ * that changes between Docusaurus builds.
+ */
+[class*="announcementBar"] {
+ will-change: auto;
+ transform: translateZ(0);
+}
+
+/*
+ * Font-display: swap is configured per @font-face declaration in
+ * src/fonts. Docusaurus-injected Google Fonts links already include
+ * &display=swap in the URL, so no additional override is needed here.
+ */
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 257a0699e..042459e0b 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 6256f35c7..336927cfa 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 a943edf5b..e6441f6be 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 7f2c70d2d..abec446f0 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 88347dd09..ed7cdef20 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 6def4988c..eb3c46c28 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 680169b0d..56efeb7ed 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 0375ee20a..9cd8278e0 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 7d41d39e6..7ef158ec2 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 1afd00fb6..03c170cb7 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 a68da419e..8e53f8f3b 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
@@ -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-3.0.0/concepts/what-is-keploy.md b/versioned_docs/version-3.0.0/concepts/what-is-keploy.md
index 3c2f68212..8a58b6333 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
@@ -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-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 950ccc8c6..1830d5009 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 61667fe1a..044a8a1e5 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 efe019b5f..6992e06b5 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 8f2cb3457..b1d6d95da 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 2fb5e2cff..9ea2f1a81 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 56075a3f8..d77352759 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 f0813a5bb..6a92f05ec 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 a328ab7c9..1d6da3b41 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 f15335ea5..ae142af0d 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 855c02e61..fa3eb3603 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 8d4a1eeae..1ebd3b7de 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 cb583e310..e2883655b 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 024ee67fc..9dbf5fdb3 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 fd621b218..5b80372c1 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 421d6150e..9b7c224f7 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 84eed5372..58fce9c16 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 a41b9e256..ade56e054 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 a68da419e..8e53f8f3b 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
@@ -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-4.0.0/concepts/what-is-keploy.md b/versioned_docs/version-4.0.0/concepts/what-is-keploy.md
index 3c2f68212..8a58b6333 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
@@ -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-4.0.0/hacktoberfest/contribution-guide.md b/versioned_docs/version-4.0.0/hacktoberfest/contribution-guide.md
index 8efbe4b43..ecd6a6402 100644
--- a/versioned_docs/version-4.0.0/hacktoberfest/contribution-guide.md
+++ b/versioned_docs/version-4.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-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 2bd23fb2a..e21c5a295 100644
--- a/versioned_docs/version-4.0.0/keploy-cloud/testgeneration.md
+++ b/versioned_docs/version-4.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-4.0.0/quickstart/code-coverage.md b/versioned_docs/version-4.0.0/quickstart/code-coverage.md
index 950ccc8c6..1830d5009 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 61667fe1a..044a8a1e5 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 efe019b5f..6992e06b5 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 8f2cb3457..b1d6d95da 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 2fb5e2cff..9ea2f1a81 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 56075a3f8..d77352759 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 f0813a5bb..6a92f05ec 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 a328ab7c9..1d6da3b41 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 f15335ea5..ae142af0d 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 855c02e61..fa3eb3603 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 8d4a1eeae..1ebd3b7de 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 cb583e310..e2883655b 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 024ee67fc..9dbf5fdb3 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 fd621b218..5b80372c1 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 421d6150e..9b7c224f7 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 84eed5372..58fce9c16 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 a41b9e256..ade56e054 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 9d8246bda..912b8e80b 100644
--- a/versioned_docs/version-4.0.0/server/index.md
+++ b/versioned_docs/version-4.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)