diff --git a/content/llms-full-root.txt b/content/llms-full-root.txt index 133254993..54136cb2a 100644 --- a/content/llms-full-root.txt +++ b/content/llms-full-root.txt @@ -72,7 +72,7 @@ Key architectural components: ### How Test Mode Works 1. Keploy replays recorded test cases using `keploy test -c ""` 2. Recorded API requests are sent to the application -3. Dependency responses are served from recorded mocks (no real external calls) +3. Dependency responses are served from recorded mocks (no real external calls; the open-source Keploy relays Redis calls to the real server) 4. Application responses are compared against recorded expected responses 5. Noise detection filters out non-deterministic differences 6. Test results are reported with pass/fail status and detailed diffs @@ -89,7 +89,7 @@ Key architectural components: - MongoDB: Full CRUD operation mocking - PostgreSQL: Query-level mocking and replay - HTTP/HTTPS: External API call mocking -- Redis: Command-level mocking +- Redis (and servers that speak Redis's protocol, such as Valkey, KeyDB and Dragonfly): Command-level mocking in Keploy Enterprise only (https://keploy.io/docs/keploy-cloud/cloud-installation/), which is the `keploy` that https://keploy.io/install.sh installs by default (https://keploy.io/docs/server/installation/); a free account is enough to record and replay with it, and free-tier runs are subject to a usage allowance. The open-source Keploy passes Redis calls through to the real Redis server in record and test, records no Redis mocks, and logs that the Redis calls are skipped. Natively on macOS and Windows, Keploy understands HTTP/HTTPS, MySQL and MongoDB calls; calls to other services (PostgreSQL, Redis, Kafka, gRPC, SQS, …) are captured only as raw bytes and usually don't replay. For those, run Keploy with Docker (or on Linux or WSL). diff --git a/versioned_docs/version-4.0.0/dependencies/index.md b/versioned_docs/version-4.0.0/dependencies/index.md index 88f40770e..644e469cd 100644 --- a/versioned_docs/version-4.0.0/dependencies/index.md +++ b/versioned_docs/version-4.0.0/dependencies/index.md @@ -2,10 +2,10 @@ id: index title: Supported Dependencies sidebar_label: Supported Dependencies -description: "List of dependencies supported by Keploy for traffic interception — MongoDB, PostgreSQL, HTTP, and Redis." +description: "List of dependencies supported by Keploy for traffic interception — MongoDB, PostgreSQL, HTTP, and Redis (Keploy Enterprise)." --- - [MongoDB](/dependencies/mongo/) - [PostgreSQL](/dependencies/postgres) - [HTTP](/dependencies/http) -- [Redis](/dependencies/redis) +- [Redis](/dependencies/redis) — [Keploy Enterprise](/docs/keploy-cloud/cloud-installation/) only (a free account is enough); the open-source `keploy` passes Redis calls through to the real server diff --git a/versioned_docs/version-4.0.0/dependencies/redis.md b/versioned_docs/version-4.0.0/dependencies/redis.md index afbeff3e0..1b714b52b 100644 --- a/versioned_docs/version-4.0.0/dependencies/redis.md +++ b/versioned_docs/version-4.0.0/dependencies/redis.md @@ -2,9 +2,24 @@ id: redis title: Redis Support sidebar_label: Redis Support -description: "How Keploy intercepts and mocks Redis wire protocol traffic — RESP parsing for automated test recording and replay." +description: "How Keploy Enterprise records and mocks Redis (RESP) traffic, and how the open-source Keploy passes Redis calls through." --- +:::note Recording and mocking Redis needs Keploy Enterprise + +Keploy records and mocks Redis calls, and calls to servers that speak Redis's protocol such as Valkey, KeyDB and Dragonfly, only in [Keploy Enterprise](/docs/keploy-cloud/cloud-installation/), which is the `keploy` that the [install script](/docs/server/installation/) installs by default. A free account is enough to record and replay with it; free-tier runs are subject to a usage allowance. + +The open-source `keploy` is the `keploy` that you build from the open-source repository, install with `curl --silent -O -L https://keploy.io/install.sh && source install.sh --oss`, download from the keploy/keploy GitHub releases, or run from the `ghcr.io/keploy/keploy` image. It detects a Redis connection by its first command, which Redis client libraries send as a RESP array. It then passes the connection through to the real Redis server, in `keploy record` and in `keploy test` alike: + +- It records no Mocks for that connection and serves none. Test-Sets that Keploy Enterprise or some earlier open-source releases recorded hold Redis calls as `Redis` Mocks: the open-source `keploy` skips those, and logs a warning each time it loads the Test-Set, with how many it skipped. Test-Sets from other open-source releases hold them as `Generic` Mocks. It leaves those out of the replay too, and logs a warning once per run that it does, so those Test-Sets need Redis running as well. +- It logs a warning, once for each Redis address, that the Redis calls are skipped, with a link to the [Keploy Enterprise page](/docs/keploy-cloud/cloud-installation/) that this note links to above. +- Redis must be running while `keploy test` runs, with the data the recorded tests expect. The app reads and writes the live Redis, and the recording and every earlier test run wrote to it too, so a key that was written, changed, or expired since the recording can change the app's responses. +- `keploy test` connects to Redis directly. If the app reached Redis through an HTTP `CONNECT` proxy when it was recorded, Redis must be reachable from `keploy` without that proxy: on a network that lets traffic out only through the proxy, `keploy test` can't reach Redis. + +When a connection doesn't open with a RESP array that names a Redis command the open-source `keploy` knows, such as an inline command typed in a telnet session, a command of a Redis module it doesn't know, or a command only a Redis-compatible server has, such as Tile38's `NEARBY`, it doesn't detect the connection as Redis. It records the connection as `Generic` Mocks, as before. + +::: + ## Introduction The Redis wire protocol is a simple, text-based protocol used to communicate with the Redis server over a TCP/IP socket. It follows a request-response model where the client sends a command to the server, and the server responds with a reply. @@ -19,6 +34,8 @@ For more information, check out Redis serialization protocol specification from ## How it works ? +Keploy Enterprise records and replays Redis calls on Linux, and in Docker or WSL. Natively on macOS and Windows, Keploy doesn't understand Redis calls, so use Docker on macOS, and Docker or WSL on Windows. + ### Record Mode In record mode, the encode function is utilized. Its primary responsibility is to process incoming user traffic and store this data in mock files. For Redis specifically, the function starts by reading the first 5 bytes of the incoming call to identify the type of call. diff --git a/versioned_docs/version-4.0.0/keploy-cloud/installation.md b/versioned_docs/version-4.0.0/keploy-cloud/installation.md index 48d2fb9ba..73e09d5d2 100644 --- a/versioned_docs/version-4.0.0/keploy-cloud/installation.md +++ b/versioned_docs/version-4.0.0/keploy-cloud/installation.md @@ -18,6 +18,12 @@ import ProductTier from '@site/src/components/ProductTier'; This guide covers installing **Keploy**, the key features available on the Enterprise plan, and steps to get started. It is designed to help teams quickly adopt Keploy and integrate it into their development and testing workflows. +:::note Redis works with a free account + +The `keploy` that the [install script](/docs/server/installation/) installs by default (without `--oss`) is Keploy Enterprise. It records and mocks Redis on Linux and in Docker or WSL, and a free account is enough for that: recording and mocking Redis does not need the Enterprise plan that the rest of this page describes. See [Redis Support](/docs/dependencies/redis/). + +::: + ### Requesting the Enterprise Plan To use the features on this page, your Keploy account needs to be on the Enterprise plan. diff --git a/versioned_docs/version-4.0.0/quickstart/flask-redis.md b/versioned_docs/version-4.0.0/quickstart/flask-redis.md index 5a4b2d87f..058a3b48b 100644 --- a/versioned_docs/version-4.0.0/quickstart/flask-redis.md +++ b/versioned_docs/version-4.0.0/quickstart/flask-redis.md @@ -56,10 +56,18 @@ text: "Run keploy test -c \"CMD_TO_RUN_APP\" --delay 10 to replay the recorded t import ProductTier from '@site/src/components/ProductTier'; - + 🪄 Dive into the world of Student CRUD Apps and see how seamlessly Keploy integrated with Flask and Redis. Buckle up, it's gonna be a fun ride! 🎢 +:::note Recording and mocking Redis needs Keploy Enterprise + +Keploy records this app's Redis calls as Mocks, and replays them in `keploy test`, only in [Keploy Enterprise](/docs/keploy-cloud/cloud-installation/), which is the `keploy` that the [install script](/docs/server/installation/) installs by default. A free account is enough to record and replay with it; free-tier runs are subject to a usage allowance. + +The open-source `keploy` is the `keploy` that you build from the open-source repository, install with `curl --silent -O -L https://keploy.io/install.sh && source install.sh --oss`, download from the keploy/keploy GitHub releases, or run from the `ghcr.io/keploy/keploy` image. It passes the Redis calls through to the real Redis server in `keploy record` and in `keploy test`, records no Redis Mocks, and logs a warning that the Redis calls are skipped. With it, Redis must be running while `keploy test` runs, and the app reads and writes the live Redis: a test whose response depends on Redis data, such as the IDs this app takes from a Redis counter, can fail. See [Redis Support](/docs/dependencies/redis/). + +::: + import Link from '@docusaurus/Link' import EnterpriseInstallReminder from '@site/src/components/EnterpriseInstallReminder'; diff --git a/versioned_docs/version-4.0.0/quickstart/go-gin-redis.md b/versioned_docs/version-4.0.0/quickstart/go-gin-redis.md index f533b2d5b..99ebbed30 100644 --- a/versioned_docs/version-4.0.0/quickstart/go-gin-redis.md +++ b/versioned_docs/version-4.0.0/quickstart/go-gin-redis.md @@ -58,10 +58,18 @@ import ProductTier from '@site/src/components/ProductTier'; # Using Docker Compose 🐳 - + A sample user authentication app to test Keploy integration capabilities using Gin and Redis. +:::note Recording and mocking Redis needs Keploy Enterprise + +Keploy records this app's Redis calls as Mocks, and replays them in `keploy test`, only in [Keploy Enterprise](/docs/keploy-cloud/cloud-installation/), which is the `keploy` that the [install script](/docs/server/installation/) installs by default. A free account is enough to record and replay with it; free-tier runs are subject to a usage allowance. + +The open-source `keploy` is the `keploy` that you build from the open-source repository, install with `curl --silent -O -L https://keploy.io/install.sh && source install.sh --oss`, download from the keploy/keploy GitHub releases, or run from the `ghcr.io/keploy/keploy` image. It passes the Redis calls through to the real Redis server in `keploy record` and in `keploy test`, records no Redis Mocks, and logs a warning that the Redis calls are skipped. With it, Redis must be running while `keploy test` runs, and the app reads and writes the live Redis: the OTP verification test fails, because replaying the OTP request stores a new random OTP in Redis, and the recorded OTP no longer matches it. See [Redis Support](/docs/dependencies/redis/). + +::: + ### Clone a sample user authentication app 🧪 @@ -190,56 +198,44 @@ curl: | --header 'Postman-Token: 2db91281-a5bf-49e0-be0d-c6293c833910' \ ``` -This is how `mocks.yml` generated would look like:- +Keploy Enterprise records no Mock for the app's `PING`. This excerpt of the `mocks.yaml` it writes for these calls leaves out the timestamps and the Mocks for the `HELLO` and `CLIENT SETINFO` commands with which the Redis client opens its connection: ```yaml - version: api.keploy.io/v1beta2 - kind: Generic - name: mocks - spec: - metadata: {} - genericrequests: - - origin: client - message: - - type: string - data: "*1\r\n$4\r\nping\r\n" - genericresponses: - - origin: server - message: - - type: string - data: "+PONG\r\n" - --- - version: api.keploy.io/v1beta2 - kind: Generic - name: mocks - spec: - metadata: {} - genericrequests: - - origin: client - message: - - type: string - data: "*5\r\n$3\r\nset\r\n$19\r\nsomething@gmail.com\r\n$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n$2\r\nex\r\n$5\r\n14400\r\n" - genericresponses: - - origin: server - message: - - type: string - data: "+OK\r\n" - --- - version: api.keploy.io/v1beta2 - kind: Generic - name: mocks - spec: - metadata: {} - genericrequests: - - origin: client - message: - - type: string - data: "*2\r\n$3\r\nget\r\n$19\r\nsomething@gmail.com\r\n" - genericresponses: - - origin: server - message: - - type: string - data: "$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n" +version: api.keploy.io/v1beta1 +kind: Redis +name: mock-3 +spec: + metadata: + connID: "0" + RequestBin: + - origin: client + message: + - type: string + data: "*5\r\n$3\r\nset\r\n$19\r\nsomething@gmail.com\r\n$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n$2\r\nex\r\n$5\r\n14400\r\n" + ResponseBin: + - origin: server + message: + - type: string + data: "+OK\r\n" +connectionId: "0" +--- +version: api.keploy.io/v1beta1 +kind: Redis +name: mock-4 +spec: + metadata: + connID: "0" + RequestBin: + - origin: client + message: + - type: string + data: "*2\r\n$3\r\nget\r\n$19\r\nsomething@gmail.com\r\n" + ResponseBin: + - origin: server + message: + - type: string + data: "$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n" +connectionId: "0" ``` Want to see if everything works as expected? @@ -268,12 +264,20 @@ Happy coding! ✨👩‍💻👨‍💻✨ # Running App Locally on Linux/WSL 🐧 - + A sample user authentication app to test Keploy integration capabilities using Gin and Redis. This section runs on Linux or WSL. On macOS, or on Windows without WSL, use the [Docker steps](#using-docker-compose-) instead — natively there, Keploy captures Redis calls only as raw bytes, which usually don't replay. +:::note Recording and mocking Redis needs Keploy Enterprise + +Keploy records this app's Redis calls as Mocks, and replays them in `keploy test`, only in [Keploy Enterprise](/docs/keploy-cloud/cloud-installation/), which is the `keploy` that the [install script](/docs/server/installation/) installs by default. A free account is enough to record and replay with it; free-tier runs are subject to a usage allowance. + +The open-source `keploy` is the `keploy` that you build from the open-source repository, install with `curl --silent -O -L https://keploy.io/install.sh && source install.sh --oss`, download from the keploy/keploy GitHub releases, or run from the `ghcr.io/keploy/keploy` image. It passes the Redis calls through to the real Redis server in `keploy record` and in `keploy test`, records no Redis Mocks, and logs a warning that the Redis calls are skipped. With it, Redis must be running while `keploy test` runs, and the app reads and writes the live Redis: the OTP verification test fails, because replaying the OTP request stores a new random OTP in Redis, and the recorded OTP no longer matches it. See [Redis Support](/docs/dependencies/redis/). + +::: + ### Clone a sample user authentication app 🧪 @@ -403,56 +407,44 @@ curl: | --header 'Postman-Token: 2db91281-a5bf-49e0-be0d-c6293c833910' \ ``` -This is how `mocks.yml` generated would look like:- +Keploy Enterprise records no Mock for the app's `PING`. This excerpt of the `mocks.yaml` it writes for these calls leaves out the timestamps and the Mocks for the `HELLO` and `CLIENT SETINFO` commands with which the Redis client opens its connection: ```yaml - version: api.keploy.io/v1beta2 - kind: Generic - name: mocks - spec: - metadata: {} - genericrequests: - - origin: client - message: - - type: string - data: "*1\r\n$4\r\nping\r\n" - genericresponses: - - origin: server - message: - - type: string - data: "+PONG\r\n" - --- - version: api.keploy.io/v1beta2 - kind: Generic - name: mocks - spec: - metadata: {} - genericrequests: - - origin: client - message: - - type: string - data: "*5\r\n$3\r\nset\r\n$19\r\nsomething@gmail.com\r\n$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n$2\r\nex\r\n$5\r\n14400\r\n" - genericresponses: - - origin: server - message: - - type: string - data: "+OK\r\n" - --- - version: api.keploy.io/v1beta2 - kind: Generic - name: mocks - spec: - metadata: {} - genericrequests: - - origin: client - message: - - type: string - data: "*2\r\n$3\r\nget\r\n$19\r\nsomething@gmail.com\r\n" - genericresponses: - - origin: server - message: - - type: string - data: "$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n" +version: api.keploy.io/v1beta1 +kind: Redis +name: mock-3 +spec: + metadata: + connID: "0" + RequestBin: + - origin: client + message: + - type: string + data: "*5\r\n$3\r\nset\r\n$19\r\nsomething@gmail.com\r\n$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n$2\r\nex\r\n$5\r\n14400\r\n" + ResponseBin: + - origin: server + message: + - type: string + data: "+OK\r\n" +connectionId: "0" +--- +version: api.keploy.io/v1beta1 +kind: Redis +name: mock-4 +spec: + metadata: + connID: "0" + RequestBin: + - origin: client + message: + - type: string + data: "*2\r\n$3\r\nget\r\n$19\r\nsomething@gmail.com\r\n" + ResponseBin: + - origin: server + message: + - type: string + data: "$38\r\n{\"otp\":5486,\"username\":\"shivamsourav\"}\r\n" +connectionId: "0" ``` Want to see if everything works as expected? diff --git a/versioned_docs/version-4.0.0/running-keploy/mock-your-tests.md b/versioned_docs/version-4.0.0/running-keploy/mock-your-tests.md index 2b89cbc31..5bf363308 100644 --- a/versioned_docs/version-4.0.0/running-keploy/mock-your-tests.md +++ b/versioned_docs/version-4.0.0/running-keploy/mock-your-tests.md @@ -31,6 +31,12 @@ The recorded mocks act as virtual services for your dependencies, which makes th - `keploy mock replay -c ""` runs your tests again with those calls served from the mock set, so the real dependencies can be **offline**. +:::note Redis must be running with the open-source Keploy + +The open-source `keploy` (for example, installed with `--oss`) neither records nor mocks Redis: it passes your tests' Redis calls through to the real Redis server in `keploy mock record` and in `keploy mock replay`, so any Redis server your tests use must be running and reachable during the replay too. [Keploy Enterprise](/docs/keploy-cloud/cloud-installation/), which the [install script](/docs/server/installation/) installs by default, records and mocks Redis. A free account is enough to record and replay with it; free-tier runs are subject to a usage allowance. See [Redis Support](/docs/dependencies/redis/). + +::: + Keploy propagates your test runner's **exit code**, so it drops straight into CI. Using VS Code? The [Keploy VS Code extension](/docs/running-keploy/utg-vscode-extension/) @@ -44,7 +50,8 @@ explains the messages the panel shows when a run fails. # 1. Record the dependency calls your tests make (real dependencies must be up) keploy mock record -c "pytest" -# 2. Replay — the dependencies can now be down; your tests run against the mocks +# 2. Replay — your tests run against the mocks, so the dependencies can now be +# down (with the open-source keploy, Redis must stay up) keploy mock replay -c "pytest" ```