From 340c44458e00db5a0bc143f5628e8c8656848ef4 Mon Sep 17 00:00:00 2001 From: Achanandhi-M Date: Wed, 24 Dec 2025 17:06:21 +0530 Subject: [PATCH] docs: add Kubernetes proxy quickstart and revamp sidebar Signed-off-by: Achanandhi-M --- docs/hacktoberfest/contribution-guide.md | 1 + docusaurus.config.js | 4 - src/components/EnterpriseInstallReminder.js | 2 +- src/components/Product.js | 10 +- .../concepts/what-is-a-keploy-sdk.md | 1 + .../hacktoberfest/contribution-guide.md | 1 + .../version-1.0.0/java/integration.md | 6 + .../java/quickstart/spring-sql.md | 5 + .../glossary/behaviour-driven-development.md | 11 + .../reference/glossary/integration-testing.md | 11 + .../glossary/microservice-testing.md | 1 + .../glossary/software-testing-life-cycle.md | 7 + .../glossary/test-driven-development.md | 1 + .../concepts/what-is-a-keploy-ebpf.md | 1 + .../glossary/behaviour-driven-development.md | 11 + .../reference/glossary/integration-testing.md | 11 + .../glossary/microservice-testing.md | 1 + .../glossary/software-testing-life-cycle.md | 7 + .../glossary/test-driven-development.md | 1 + .../concepts/what-is-a-keploy-ebpf.md | 1 + .../version-3.0.0/installation/windows.md | 1 + .../version-3.0.0/quickstart/k8s-proxy.md | 250 ++++++++++++++++++ .../running-keploy/api-testing-webhook.md | 1 + .../running-keploy/configuration-file.md | 2 + .../running-keploy/risk-profile-analysis.md | 2 + .../self-healing-ai-api-tests.md | 6 + .../version-3.0.0-sidebars.json | 71 ++--- 27 files changed, 381 insertions(+), 46 deletions(-) create mode 100644 versioned_docs/version-3.0.0/quickstart/k8s-proxy.md diff --git a/docs/hacktoberfest/contribution-guide.md b/docs/hacktoberfest/contribution-guide.md index a94466809..78bbf333c 100644 --- a/docs/hacktoberfest/contribution-guide.md +++ b/docs/hacktoberfest/contribution-guide.md @@ -19,6 +19,7 @@ If you’ve ever wanted to contribute to open source, now is your chance! You ca Anyone around the globe who desires to help drive the growth of open source and make positive contributions to an ever-growing community. All backgrounds and skill levels are encouraged to participate. - Code Contributribution to Keploy Projects includes: + - Bug fixes - New features - Design diff --git a/docusaurus.config.js b/docusaurus.config.js index 0c72a3da8..fbed23c6c 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -127,10 +127,6 @@ module.exports = { label: "API Testing (AI)", to: "/running-keploy/api-test-generator", }, - { - label: "Unit Testing", - to: "/running-keploy/utg-pr-agent", - }, ], }, { diff --git a/src/components/EnterpriseInstallReminder.js b/src/components/EnterpriseInstallReminder.js index 5d3c04b2b..1723d3adb 100644 --- a/src/components/EnterpriseInstallReminder.js +++ b/src/components/EnterpriseInstallReminder.js @@ -21,7 +21,7 @@ export default function EnterpriseInstallReminder() { return (

- Don’t have Keploy installed yet? + Don’t have Keploy Enterprise installed yet?

Before running this sample, make sure Keploy Enterprise version is diff --git a/src/components/Product.js b/src/components/Product.js index 424749fbe..9d01e9fdc 100644 --- a/src/components/Product.js +++ b/src/components/Product.js @@ -9,7 +9,7 @@ function UTG() {

  • @@ -25,15 +25,13 @@ function UTG() { fill="#FF914D" /> -

    - Unit Testing Agent -

    +

    K8s Agent

    • - Generate reliable, validated tests as you code, ensuring - coverage and stability. + Live record and replay your tests in your k8s cluster, + ensuring coverage and stability.

    diff --git a/versioned_docs/version-1.0.0/concepts/what-is-a-keploy-sdk.md b/versioned_docs/version-1.0.0/concepts/what-is-a-keploy-sdk.md index 428984d67..4a0c2316e 100644 --- a/versioned_docs/version-1.0.0/concepts/what-is-a-keploy-sdk.md +++ b/versioned_docs/version-1.0.0/concepts/what-is-a-keploy-sdk.md @@ -14,6 +14,7 @@ keywords: A Keploy SDK is a language-specific library that offers APIs to do the following: 1. Capture all the network calls like + - API Request - Dependency calls - API Response 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 8e1acb7bb..d52f408d2 100644 --- a/versioned_docs/version-1.0.0/hacktoberfest/contribution-guide.md +++ b/versioned_docs/version-1.0.0/hacktoberfest/contribution-guide.md @@ -19,6 +19,7 @@ If you’ve ever wanted to contribute to open source, now is your chance! You ca Anyone around the globe who desires to help drive the growth of open source and make positive contributions to an ever-growing community. All backgrounds and skill levels are encouraged to participate. - Code Contributribution to Keploy Projects includes: + - Bug fixes - New features - Design diff --git a/versioned_docs/version-1.0.0/java/integration.md b/versioned_docs/version-1.0.0/java/integration.md index 1199bdc19..eaa143186 100644 --- a/versioned_docs/version-1.0.0/java/integration.md +++ b/versioned_docs/version-1.0.0/java/integration.md @@ -34,13 +34,17 @@ Sync dependencies or to _build.gradle_: compile 'io.keploy:keploy-sdk:1.0.13' 2. Install Keploy Jar + - Download the latest jar from [here](https://search.maven.org/artifact/io.keploy/keploy-sdk/1.2.6/jar) (eg: 1.2.6) to mock external/internal dependency calls like DB queries, GMaps, S3 etc.. + - Add the jar into the `main` directory + - Add `-javaagent:` prefix with absolute classpath of Keploy jar downloaded above (For example: `-javaagent:/Users/jhon/project/src/main/agent-1.2.5.jar`) You can set this through 3 ways:- + 1. {'<'}details{'>'}{'<'}summary{'>'} Using Intellij {'<'}/summary{'>'} @@ -71,6 +75,7 @@ Sync dependencies or to _build.gradle_: ## Supported Frameworks - **For Spring based application** + - Add `@Import(KeployMiddleware.class)` below `@SpringBootApplication` in your main class. ```java @@ -88,6 +93,7 @@ Sync dependencies or to _build.gradle_: ``` - **For Java EE application** + - Specify the below filter above all other filters and servlets in the **web.xml** file. ```xml diff --git a/versioned_docs/version-1.0.0/java/quickstart/spring-sql.md b/versioned_docs/version-1.0.0/java/quickstart/spring-sql.md index c7a01f4ad..c52e14eda 100644 --- a/versioned_docs/version-1.0.0/java/quickstart/spring-sql.md +++ b/versioned_docs/version-1.0.0/java/quickstart/spring-sql.md @@ -39,12 +39,15 @@ Sync dependencies or to _build.gradle_: 2. Install Keploy Jar - Download the latest jar from [here](https://search.maven.org/artifact/io.keploy/keploy-sdk/1.2.6/jar) (eg: 1.2.6) to mock external/internal dependency calls like DB queries, GMaps, S3 etc.. + - Add the jar into the `main` directory + - **Copy** `-javaagent:` prefix with absolute classpath of Keploy jar downloaded above (For example: `-javaagent:/Users/jhon/project/src/main/agent-1.2.5.jar`) You can set this through 3 ways:- + 1. {'<'}details{'>'}{'<'}summary{'>'} Using Intellij {'<'}/summary{'>'} @@ -178,10 +181,12 @@ _NOTE: You will be required to set the `javaagent` again in your test profile ju ``` - **Using IDE:** _(for local use-case we prefer running tests via IDE)_ + 1. Run your application. 2. You can also run the application with coverage to see the test coverage. - **Using CLI** + 1. Add maven-surefire-plugin to your `pom.xml`. In ` ` **don't** add jacoco agent if you don't want coverage report. {'<'}details{'>'}{'<'}summary{'>'} diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/behaviour-driven-development.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/behaviour-driven-development.md index ddc28d460..ca31c3200 100644 --- a/versioned_docs/version-2.0.0/concepts/reference/glossary/behaviour-driven-development.md +++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/behaviour-driven-development.md @@ -29,21 +29,26 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ## BDD Fundamentals 1. **Collaboration and Communication:** + - BDD fosters close collaboration among developers, testers, and business stakeholders. - Open communication ensures that everyone has a shared understanding of the requirements and desired behavior. 2. **User Stories:** + - BDD starts with user stories written from the perspective of the end user, typically formatted as: "As a [role], I want [feature] so that [benefit]." 3. **Scenarios and Examples:** + - Detailed scenarios illustrate specific behaviors of the software using the Given-When-Then format. - These scenarios serve as clear acceptance criteria that define when a user story is complete. 4. **Gherkin Language:** + - BDD employs Gherkin, a simple, human-readable syntax that uses keywords like Given, When, Then, And, and But to structure scenarios. 5. **Acceptance Criteria:** + - Scenarios double as acceptance criteria, ensuring all functional requirements are testable and clearly defined. 6. **Automated Testing:** @@ -52,12 +57,15 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ## Techniques of BDD 1. **Three Amigos Meetings:** + - A collaborative session involving a developer, tester, and business analyst to discuss and refine user stories and scenarios, ensuring alignment across teams. 2. **Example Mapping:** + - A technique to break down user stories into concrete examples, helping to identify edge cases and clarify requirements. 3. **Writing Gherkin Scenarios:** + - Scenarios are written in Gherkin syntax. For example: ```gherkin Scenario: User logs in successfully @@ -67,6 +75,7 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ``` 4. **Automating Scenarios with BDD Tools:** + - Tools like Cucumber, SpecFlow, Behave, JBehave, Gauge, and Reqnroll parse Gherkin syntax and link it to executable test code. For example, using Cucumber with Java: ```java @@ -87,9 +96,11 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ``` 5. **Continuous Integration (CI) and Continuous Delivery (CD):** + - BDD scenarios are integrated into CI/CD pipelines to run automated tests with every build, ensuring that new changes do not break existing functionality. 6. **Living Documentation:** + - BDD scenarios act as up-to-date documentation that evolves with the system, making it accessible and understandable to both technical and non-technical stakeholders. 7. **Refactoring:** diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/integration-testing.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/integration-testing.md index 335464753..d878a3e5a 100644 --- a/versioned_docs/version-2.0.0/concepts/reference/glossary/integration-testing.md +++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/integration-testing.md @@ -38,24 +38,31 @@ Integration testing can be performed using a variety of techniques, including: ### Challenges of Traditional Integration Testing Method 1. **Complexity of Systems:** + - It can be difficult to integrate different modules, parts, and outside services into complex software programs, requiring extensive testing techniques. The requirement to make sure that every component of the system handles data consistently and communicates effectively gives rise to this complexity. Furthermore, the dependencies, configurations, and functional properties of various modules may differ, which may lead to unexpected challenges during integration. 2. **Dependency Management:** + - Managing dependencies between components and ensuring they function together harmoniously can be complex, especially in distributed systems. Dependencies can include shared libraries, APIs, databases, and third-party services. Each dependency may have its own versioning, configuration, and compatibility requirements, which can lead to conflicts and integration issues. It is additionally challenging to identify and fix issues when changes to one component have a ripple effect on others. To ensure that every component function as a whole, detailed documentation, version control, and automated testing are necessary for effective dependency management. 3. **Data Management:** + - Handling realistic test data scenarios, ensuring data integrity, and maintaining consistency across different testing environments pose challenges in integration testing. Creating and managing test data that accurately reflects real-world scenarios can be time-consuming and complex. Additionally, ensuring that test data remains consistent across various environments (development, staging, production) is crucial to avoid discrepancies that could lead to false positives or negatives in test results. Furthermore, managing data versioning and synchronization between different modules and services adds another layer of complexity to the integration testing process. 4. **Environment Configuration:** + - Configuring testing environments to accurately reflect production while providing necessary isolation for testing is time-consuming and error-prone. Ensuring that the test environment mirrors the production environment in terms of hardware, software, network configurations, and data can be challenging. Differences between environments can lead to discrepancies in test results, making it difficult to identify true integration issues. Additionally, maintaining multiple environments for different stages of testing (development, staging, production) requires significant resources and coordination. Properly managing environment variables, secrets, and configurations across these environments adds another layer of complexity. 5. **Timing and Coordination:** + - Coordinating testing efforts across multiple teams or development cycles and ensuring all components are ready for testing at the same time require effective communication and coordination. This challenge is compounded by varying schedules, priorities, and resource availability among teams. Misalignment in timelines can lead to delays and bottlenecks, impacting the overall project timeline. Additionally, synchronizing test environments and ensuring consistent configurations across different teams can be difficult. Effective use of project management tools, regular status meetings, and clear documentation are essential to mitigate these challenges. 6. **Testing Third-Party Integrations:** + - Testing integration with third-party APIs, libraries, or services introduces complexity as teams have limited control over their behaviour and availability. These third-party components can change without notice, leading to unexpected failures. Additionally, rate limits, authentication issues, and network latency can further complicate testing. Ensuring compatibility with different versions and handling deprecated features also pose significant challenges. 7. **Regression Testing:** + - Managing regression testing across multiple integration points to ensure new features or changes do not introduce compatibility issues is challenging, especially in large systems. This involves verifying that existing functionalities continue to work as expected after modifications. The complexity increases with the number of integration points, as each point must be tested for potential side effects. Additionally, maintaining an up-to-date suite of regression tests can be resource-intensive, requiring continuous updates to test cases and test data to reflect the current state of the system. Automated regression testing tools can help, but they also require significant setup and maintenance efforts. 8. **Scalability and Performance Testing:** @@ -66,15 +73,19 @@ Addressing these challenges requires careful planning, collaboration between dev ### Overcoming Integration Testing Challenges with Keploy 1. **Complexity of Systems:** + - Keploy simplifies integration testing with its user-friendly platform and automation capabilities. It streamlines the testing process, even in complex systems, by providing an intuitive interface for recording interactions and generating test cases. 2. **Dependency Management:** + - Keploy automates stub generation, eliminating the need for manual creation of stubs or mock objects, which can be time-consuming and error-prone. Instead, it generates realistic stubs based on recorded interactions during the testing process. By using recorded interactions to create stubs, Keploy ensures that the dependencies are accurately simulated, leading to more reliable and comprehensive integration tests. 3. **Data Management:** + - Keploy addresses the challenges of data management in integration testing through its advanced features and capabilities. It automates the process of generating test data, which eliminates the need for manual data creation and reduces the risk of human error. This ensures that test data is always available and consistent across different test runs. 4. **Environment Configuration:** + - Keploy addresses the challenge of environment configuration in integration testing through its native integration feature, which simplifies the setup process and accelerates testing. It seamlessly integrates with your development setups, allowing for quick and easy configuration without the need for extensive manual setup. This reduces the time and effort required to mirror production environments for testing purposes. It also provides a way to isolate test environments, ensuring that tests do not interfere with each other and that the testing environment accurately reflects production. This isolation helps maintain the integrity of test results. 5. **Timing and Coordination:** 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 25c242808..96e839c32 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 @@ -26,6 +26,7 @@ Microservice testing is the process of validating individual components of a mic ## Challenges in Microservices Testing: - **Complex service dependencies** : + - Microservices often rely on other services, databases, or third-party APIs, making it challenging to test in isolation. - **Difficulty in replicating production environments** diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/software-testing-life-cycle.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/software-testing-life-cycle.md index 345a83ace..6ffe1864f 100644 --- a/versioned_docs/version-2.0.0/concepts/reference/glossary/software-testing-life-cycle.md +++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/software-testing-life-cycle.md @@ -20,30 +20,37 @@ Software Testing Life Cycle, more commonly known as STLC, is a process to test s Software Testing Life Cycle (STLC) comprises several phases that guide the testing process from inception to completion. The key phases include: 1. **Requirement Analysis**: + - **Objective**: Understand software requirements and define test objectives. - **Activities**: Review requirements, identify testable features, and plan test strategy. 2. **Test Planning**: + - **Objective**: Define test scope, resources, and timelines. - **Activities**: Develop test plan, determine testing types, and establish metrics. 3. **Test Design**: + - **Objective**: Create detailed test cases and scenarios. - **Activities**: Write test cases, define test data, and prioritize tests. 4. **Test Environment Setup**: + - **Objective**: Prepare the testing infrastructure. - **Activities**: Configure hardware, software, and test tools. 5. **Test Execution**: + - **Objective**: Execute test cases and identify defects. - **Activities**: Run tests, log results, and capture evidence. 6. **Defect Reporting**: + - **Objective**: Document and prioritize defects. - **Activities**: Report issues, classify severity, and assign to developers. 7. **Defect Retesting and Regression Testing**: + - **Objective**: Verify defect fixes and ensure no new issues arise. - **Activities**: Re-execute failed tests, perform regression testing, and validate fixes. diff --git a/versioned_docs/version-2.0.0/concepts/reference/glossary/test-driven-development.md b/versioned_docs/version-2.0.0/concepts/reference/glossary/test-driven-development.md index 57e59886e..163717493 100644 --- a/versioned_docs/version-2.0.0/concepts/reference/glossary/test-driven-development.md +++ b/versioned_docs/version-2.0.0/concepts/reference/glossary/test-driven-development.md @@ -61,6 +61,7 @@ TDD is particularly effective in scenarios such as: ### Core Principles - **Red-Green-Refactor Cycle:** + - **Red:** Write a test that fails. - **Green:** Write code to pass the test. - **Refactor:** Clean up the code while ensuring that tests still pass. diff --git a/versioned_docs/version-2.0.0/concepts/what-is-a-keploy-ebpf.md b/versioned_docs/version-2.0.0/concepts/what-is-a-keploy-ebpf.md index 866a832f9..1bdeb0830 100644 --- a/versioned_docs/version-2.0.0/concepts/what-is-a-keploy-ebpf.md +++ b/versioned_docs/version-2.0.0/concepts/what-is-a-keploy-ebpf.md @@ -14,6 +14,7 @@ keywords: A Keploy eBPF is a language-agnostic library that offers APIs to do the following: 1. Capture all the network calls like + - API Request - Dependency calls - API Response diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/behaviour-driven-development.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/behaviour-driven-development.md index 55da17d0d..aeae9d09b 100644 --- a/versioned_docs/version-3.0.0/concepts/reference/glossary/behaviour-driven-development.md +++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/behaviour-driven-development.md @@ -29,21 +29,26 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ## BDD Fundamentals 1. **Collaboration and Communication:** + - BDD fosters close collaboration among developers, testers, and business stakeholders. - Open communication ensures that everyone has a shared understanding of the requirements and desired behavior. 2. **User Stories:** + - BDD starts with user stories written from the perspective of the end user, typically formatted as: "As a [role], I want [feature] so that [benefit]." 3. **Scenarios and Examples:** + - Detailed scenarios illustrate specific behaviors of the software using the Given-When-Then format. - These scenarios serve as clear acceptance criteria that define when a user story is complete. 4. **Gherkin Language:** + - BDD employs Gherkin, a simple, human-readable syntax that uses keywords like Given, When, Then, And, and But to structure scenarios. 5. **Acceptance Criteria:** + - Scenarios double as acceptance criteria, ensuring all functional requirements are testable and clearly defined. 6. **Automated Testing:** @@ -52,12 +57,15 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ## Techniques of BDD 1. **Three Amigos Meetings:** + - A collaborative session involving a developer, tester, and business analyst to discuss and refine user stories and scenarios, ensuring alignment across teams. 2. **Example Mapping:** + - A technique to break down user stories into concrete examples, helping to identify edge cases and clarify requirements. 3. **Writing Gherkin Scenarios:** + - Scenarios are written in Gherkin syntax. For example: ```gherkin Scenario: User logs in successfully @@ -67,6 +75,7 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ``` 4. **Automating Scenarios with BDD Tools:** + - Tools like Cucumber, SpecFlow, Behave, JBehave, Gauge, and Reqnroll parse Gherkin syntax and link it to executable test code. For example, using Cucumber with Java: ```java @@ -87,9 +96,11 @@ Behavior Driven Development (BDD) is an Agile methodology that emphasizes collab ``` 5. **Continuous Integration (CI) and Continuous Delivery (CD):** + - BDD scenarios are integrated into CI/CD pipelines to run automated tests with every build, ensuring that new changes do not break existing functionality. 6. **Living Documentation:** + - BDD scenarios act as up-to-date documentation that evolves with the system, making it accessible and understandable to both technical and non-technical stakeholders. 7. **Refactoring:** diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/integration-testing.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/integration-testing.md index 681ae41f4..0d423fb12 100644 --- a/versioned_docs/version-3.0.0/concepts/reference/glossary/integration-testing.md +++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/integration-testing.md @@ -38,24 +38,31 @@ Integration testing can be performed using a variety of techniques, including: ### Challenges of Traditional Integration Testing Method 1. **Complexity of Systems:** + - It can be difficult to integrate different modules, parts, and outside services into complex software programs, requiring extensive testing techniques. The requirement to make sure that every component of the system handles data consistently and communicates effectively gives rise to this complexity. Furthermore, the dependencies, configurations, and functional properties of various modules may differ, which may lead to unexpected challenges during integration. 2. **Dependency Management:** + - Managing dependencies between components and ensuring they function together harmoniously can be complex, especially in distributed systems. Dependencies can include shared libraries, APIs, databases, and third-party services. Each dependency may have its own versioning, configuration, and compatibility requirements, which can lead to conflicts and integration issues. It is additionally challenging to identify and fix issues when changes to one component have a ripple effect on others. To ensure that every component function as a whole, detailed documentation, version control, and automated testing are necessary for effective dependency management. 3. **Data Management:** + - Handling realistic test data scenarios, ensuring data integrity, and maintaining consistency across different testing environments pose challenges in integration testing. Creating and managing test data that accurately reflects real-world scenarios can be time-consuming and complex. Additionally, ensuring that test data remains consistent across various environments (development, staging, production) is crucial to avoid discrepancies that could lead to false positives or negatives in test results. Furthermore, managing data versioning and synchronization between different modules and services adds another layer of complexity to the integration testing process. 4. **Environment Configuration:** + - Configuring testing environments to accurately reflect production while providing necessary isolation for testing is time-consuming and error-prone. Ensuring that the test environment mirrors the production environment in terms of hardware, software, network configurations, and data can be challenging. Differences between environments can lead to discrepancies in test results, making it difficult to identify true integration issues. Additionally, maintaining multiple environments for different stages of testing (development, staging, production) requires significant resources and coordination. Properly managing environment variables, secrets, and configurations across these environments adds another layer of complexity. 5. **Timing and Coordination:** + - Coordinating testing efforts across multiple teams or development cycles and ensuring all components are ready for testing at the same time require effective communication and coordination. This challenge is compounded by varying schedules, priorities, and resource availability among teams. Misalignment in timelines can lead to delays and bottlenecks, impacting the overall project timeline. Additionally, synchronizing test environments and ensuring consistent configurations across different teams can be difficult. Effective use of project management tools, regular status meetings, and clear documentation are essential to mitigate these challenges. 6. **Testing Third-Party Integrations:** + - Testing integration with third-party APIs, libraries, or services introduces complexity as teams have limited control over their behaviour and availability. These third-party components can change without notice, leading to unexpected failures. Additionally, rate limits, authentication issues, and network latency can further complicate testing. Ensuring compatibility with different versions and handling deprecated features also pose significant challenges. 7. **Regression Testing:** + - Managing regression testing across multiple integration points to ensure new features or changes do not introduce compatibility issues is challenging, especially in large systems. This involves verifying that existing functionalities continue to work as expected after modifications. The complexity increases with the number of integration points, as each point must be tested for potential side effects. Additionally, maintaining an up-to-date suite of regression tests can be resource-intensive, requiring continuous updates to test cases and test data to reflect the current state of the system. Automated regression testing tools can help, but they also require significant setup and maintenance efforts. 8. **Scalability and Performance Testing:** @@ -66,15 +73,19 @@ Addressing these challenges requires careful planning, collaboration between dev ### Overcoming Integration Testing Challenges with Keploy 1. **Complexity of Systems:** + - Keploy simplifies integration testing with its user-friendly platform and automation capabilities. It streamlines the testing process, even in complex systems, by providing an intuitive interface for recording interactions and generating test cases. 2. **Dependency Management:** + - Keploy automates stub generation, eliminating the need for manual creation of stubs or mock objects, which can be time-consuming and error-prone. Instead, it generates realistic stubs based on recorded interactions during the testing process. By using recorded interactions to create stubs, Keploy ensures that the dependencies are accurately simulated, leading to more reliable and comprehensive integration tests. 3. **Data Management:** + - Keploy addresses the challenges of data management in integration testing through its advanced features and capabilities. It automates the process of generating test data, which eliminates the need for manual data creation and reduces the risk of human error. This ensures that test data is always available and consistent across different test runs. 4. **Environment Configuration:** + - Keploy addresses the challenge of environment configuration in integration testing through its native integration feature, which simplifies the setup process and accelerates testing. It seamlessly integrates with your development setups, allowing for quick and easy configuration without the need for extensive manual setup. This reduces the time and effort required to mirror production environments for testing purposes. It also provides a way to isolate test environments, ensuring that tests do not interfere with each other and that the testing environment accurately reflects production. This isolation helps maintain the integrity of test results. 5. **Timing and Coordination:** 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 25c242808..96e839c32 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 @@ -26,6 +26,7 @@ Microservice testing is the process of validating individual components of a mic ## Challenges in Microservices Testing: - **Complex service dependencies** : + - Microservices often rely on other services, databases, or third-party APIs, making it challenging to test in isolation. - **Difficulty in replicating production environments** diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/software-testing-life-cycle.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/software-testing-life-cycle.md index f88caf4af..634165238 100644 --- a/versioned_docs/version-3.0.0/concepts/reference/glossary/software-testing-life-cycle.md +++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/software-testing-life-cycle.md @@ -20,30 +20,37 @@ Software Testing Life Cycle, more commonly known as STLC, is a process to test s Software Testing Life Cycle (STLC) comprises several phases that guide the testing process from inception to completion. The key phases include: 1. **Requirement Analysis**: + - **Objective**: Understand software requirements and define test objectives. - **Activities**: Review requirements, identify testable features, and plan test strategy. 2. **Test Planning**: + - **Objective**: Define test scope, resources, and timelines. - **Activities**: Develop test plan, determine testing types, and establish metrics. 3. **Test Design**: + - **Objective**: Create detailed test cases and scenarios. - **Activities**: Write test cases, define test data, and prioritize tests. 4. **Test Environment Setup**: + - **Objective**: Prepare the testing infrastructure. - **Activities**: Configure hardware, software, and test tools. 5. **Test Execution**: + - **Objective**: Execute test cases and identify defects. - **Activities**: Run tests, log results, and capture evidence. 6. **Defect Reporting**: + - **Objective**: Document and prioritize defects. - **Activities**: Report issues, classify severity, and assign to developers. 7. **Defect Retesting and Regression Testing**: + - **Objective**: Verify defect fixes and ensure no new issues arise. - **Activities**: Re-execute failed tests, perform regression testing, and validate fixes. diff --git a/versioned_docs/version-3.0.0/concepts/reference/glossary/test-driven-development.md b/versioned_docs/version-3.0.0/concepts/reference/glossary/test-driven-development.md index ee18dc5d6..416c2e293 100644 --- a/versioned_docs/version-3.0.0/concepts/reference/glossary/test-driven-development.md +++ b/versioned_docs/version-3.0.0/concepts/reference/glossary/test-driven-development.md @@ -62,6 +62,7 @@ TDD is particularly effective in scenarios such as: ### Core Principles - **Red-Green-Refactor Cycle:** + - **Red:** Write a test that fails. - **Green:** Write code to pass the test. - **Refactor:** Clean up the code while ensuring that tests still pass. diff --git a/versioned_docs/version-3.0.0/concepts/what-is-a-keploy-ebpf.md b/versioned_docs/version-3.0.0/concepts/what-is-a-keploy-ebpf.md index 866a832f9..1bdeb0830 100644 --- a/versioned_docs/version-3.0.0/concepts/what-is-a-keploy-ebpf.md +++ b/versioned_docs/version-3.0.0/concepts/what-is-a-keploy-ebpf.md @@ -14,6 +14,7 @@ keywords: A Keploy eBPF is a language-agnostic library that offers APIs to do the following: 1. Capture all the network calls like + - API Request - Dependency calls - API Response diff --git a/versioned_docs/version-3.0.0/installation/windows.md b/versioned_docs/version-3.0.0/installation/windows.md index 19c5c6166..dcf04c19d 100644 --- a/versioned_docs/version-3.0.0/installation/windows.md +++ b/versioned_docs/version-3.0.0/installation/windows.md @@ -31,6 +31,7 @@ If you already have WSL, Go to Step 2. 1. **Enable WSL** Make sure you’re on: + - **Windows 10** (version 2004 or later, build 19041+) - **Windows 11** diff --git a/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md b/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md new file mode 100644 index 000000000..ff2c494dd --- /dev/null +++ b/versioned_docs/version-3.0.0/quickstart/k8s-proxy.md @@ -0,0 +1,250 @@ +--- +id: k8s-proxy +title: K8s Record Replay +description: The following sample app to test Keploy integration capabilities using NextJS,Drizzle and Postgres. +tags: + - K8s + - Microservices + - Postgres +keyword: + - Kubernetes + - Record Replay + - API Test generator + - Auto Testcase generation +--- + +# Kubernetes Live Record & Replay using Keploy Proxy + +This guide demonstrates how to use **Keploy Proxy** to perform **live traffic recording and replay in a Kubernetes environment**. + +## Get the Sample Application + +Start by cloning the e-commerce sample application repository and switching to the Kubernetes setup branch. + +```bash +git clone https://github.com/keploy/ecommerce_sample_app.git +cd ecommerce_sample_app +git checkout k8s +``` + +This branch contains all Kubernetes manifests and configurations required for this guide. + +## Prerequisites + +Make sure you have the following installed: + +- **Docker** +- **Kind** +- **kubectl** +- **Helm** + +Verify installations: + +```bash +docker --version +kind --version +kubectl version --client +helm version +``` + +## Deployment Steps + +You can use the **Keploy Kubernetes proxy** with any Kubernetes cluster, whether it is running in production or in a local environment. For this quickstart, we use a local Kind cluster to provide an overview of how the Keploy Kubernetes proxy works. + +We’ll use an **e-commerce sample application** deployed on a local Kubernetes cluster (Kind) to demonstrate Keploy’s live record and replay capabilities with real microservices traffic. + +Note: If you already have a Kubernetes cluster running, you can skip the deployment steps. + +### 1. Create a Kind Cluster + +Create a local Kubernetes cluster named `ecommerce`: + +```bash +kind create cluster --name ecommerce +``` + +### 2. Build Docker Images Locally + +The application consists of multiple services. +Build the Docker images locally so they can be used inside the Kind cluster. + +```bash +docker build -t user-service:latest ./user_service +docker build -t product-service:latest ./product_service +docker build -t order-service:latest ./order_service +docker build -t apigateway:latest ./apigateway +``` + +### 3. Load Images into Kind + +Since the Kubernetes manifests use `imagePullPolicy: Never`, the images must be manually loaded into the Kind cluster. + +```bash +kind load docker-image user-service:latest --name ecommerce +kind load docker-image product-service:latest --name ecommerce +kind load docker-image order-service:latest --name ecommerce +kind load docker-image apigateway:latest --name ecommerce +``` + +> **Note** +> +> The `mysql:8.0` and `localstack/localstack:3.3` images will be pulled automatically by Kind if not present locally. +> You may also load them manually to speed up cluster startup. + +### 4. Deploy the Application + +Apply all Kubernetes manifests: + +```bash +kubectl apply -f k8s/ +``` + +Check the status of pods: + +```bash +kubectl get pods +``` + +Wait until all pods are in the **Running** state. + +Sample Keploy K8s proxy + +### 5. Access the Application + +The API Gateway is exposed via a **NodePort** service. + +For local environments use port-forwarding: + +```bash +kubectl port-forward service/apigateway 8083:8083 +``` + +Access the application at: + +``` +http://localhost:8083 +``` + +At this point, your e-commerce application is live and ready to receive traffic. + +--- + +## Enable Live Record & Replay with Keploy Proxy + +### 1. Open Keploy Dashboard + +Visit: + +``` +https://app.keploy.io +``` + +### 2. Add Your Kubernetes Cluster + +- Navigate to **Integration Testing** +- Click on **Clusters** +- Connect a new cluster + +Sample Keploy K8s proxy + +### 3. Configure Cluster Details + +Provide the following information: + +- **Cluster Name**: `ecommerce` +- **Ingress URL**: + + ``` + http://localhost:8080 + ``` + +Sample Keploy K8s proxy + +This allows the Keploy Proxy to observe and record live traffic from your Kubernetes application. + +Note: For this quickstart, I am running it locally. If you are running your application in production, provide the necessary ingress URL. + +### 4. Install the Keploy Proxy in your k8s Cluster + +Once you have provided the cluster details, you can install the Keploy Proxy in your Kubernetes cluster using Helm. + +Sample Keploy K8s proxy + +### 5. Verify the Installation + +Paste the Helm command into the terminal. Once the installation is complete, verify that the Keploy Proxy is running. + +Note: The Keploy Proxy will be installed in the `keploy` namespace. + +```bash +kubectl get pods -n keploy +``` + +Sample Keploy K8s proxy + +Note: You need to port-forward the Keploy Proxy when running this setup on a local machine. + +```bash +kubectl port-forward -n keploy svc/k8s-proxy 8080:8080 +``` + +### 6. Your Keploy Proxy is ready to record live traffic + +Once the Keploy Proxy is installed, you can view the list of running pods in the dashboard. + +Sample Keploy K8s proxy + +### 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. + +Sample Keploy K8s proxy + +### 8. Keploy is ready to Capture Live Traffic + +Send a request to your API Gateway pod, and Keploy will capture the traffic. + +Sample Keploy K8s proxy + +### 9. Record Live Traffic + +Once you have sent a request to your API Gateway pod, you can see the live traffic being captured. + +Sample Keploy K8s proxy + +### 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. + +Sample Keploy K8s proxy + +### 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**. + +Sample Keploy K8s proxy + +### 12. Verify the Generation settings + +Once you click **Use AI for Tests**, you can view the generation settings. + +Sample Keploy K8s proxy + +### 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. + +Sample Keploy K8s proxy + +### 14. View the Test Cases + +After test generation, you can view the total number of test suites categorized as accepted, buggy, and rejected. + +Sample Keploy K8s proxy + +### Conclusion + +In this quickstart, we demonstrated how to use the Keploy Proxy in Kubernetes to record live traffic and generate tests using AI—all without writing manual tests. This is only a quickstart; you can follow the same steps to record real, production-like traffic and generate tests using AI. + +Happy Testing with Keploy diff --git a/versioned_docs/version-3.0.0/running-keploy/api-testing-webhook.md b/versioned_docs/version-3.0.0/running-keploy/api-testing-webhook.md index 3e9ac3693..24da7a700 100644 --- a/versioned_docs/version-3.0.0/running-keploy/api-testing-webhook.md +++ b/versioned_docs/version-3.0.0/running-keploy/api-testing-webhook.md @@ -221,6 +221,7 @@ func main() { Keploy sends a webhook at two distinct points for every single test step: 1. **`PreExecute`:** Sent **before** the API request is made. + - **Purpose:** To act as a gatekeeper. Your server can inspect the `requestToSend` and decide whether to allow the step to proceed. - **Your Response:** Your server must return `{"pass": true}` to allow execution or `{"pass": false}` to deny it, effectively failing the step before it even runs. diff --git a/versioned_docs/version-3.0.0/running-keploy/configuration-file.md b/versioned_docs/version-3.0.0/running-keploy/configuration-file.md index ac8426771..e7d6631fd 100644 --- a/versioned_docs/version-3.0.0/running-keploy/configuration-file.md +++ b/versioned_docs/version-3.0.0/running-keploy/configuration-file.md @@ -105,7 +105,9 @@ The `record` section in the Keploy-config file allows you to define parameters f - **`delay`**: Delay in seconds before recording each request. Default is 5 seconds. - **`filters`**: API calls to the application to avoid recording. You can also control how these conditions are matched using matchType. + - **`matchType (optional)`**: Determines how urlMethods and headers are evaluated. + - **`"AND"`**: Both must match. - **`"OR"`**: Either can match. diff --git a/versioned_docs/version-3.0.0/running-keploy/risk-profile-analysis.md b/versioned_docs/version-3.0.0/running-keploy/risk-profile-analysis.md index 2739616f7..ac2574851 100644 --- a/versioned_docs/version-3.0.0/running-keploy/risk-profile-analysis.md +++ b/versioned_docs/version-3.0.0/running-keploy/risk-profile-analysis.md @@ -27,9 +27,11 @@ The **Risk Profile Analysis** feature addresses this by automatically categorizi When a test fails, it is now assigned a risk level: - **HIGH**: Indicates a likely breaking change to the API contract. This is the highest level of risk. + - **Triggers**: Status code changes, `Content-Type` header changes, removing fields from a JSON body, or changing the data type of a field (e.g., string to number). - **MEDIUM**: Indicates a change that might affect consumers but is not a direct contract violation. + - **Triggers**: Changes in header values (other than `Content-Type`), or changes to field values within a JSON body while new fields are also being added. - **LOW**: Indicates a backward-compatible, non-breaking change. diff --git a/versioned_docs/version-3.0.0/running-keploy/self-healing-ai-api-tests.md b/versioned_docs/version-3.0.0/running-keploy/self-healing-ai-api-tests.md index fd85a38a5..eed5f26de 100644 --- a/versioned_docs/version-3.0.0/running-keploy/self-healing-ai-api-tests.md +++ b/versioned_docs/version-3.0.0/running-keploy/self-healing-ai-api-tests.md @@ -24,21 +24,27 @@ Keploy can automatically fix failing test cases using its built-in AI engine. Th ### 🔧 How to Use Self-Healing 1. **Go to the Test Report** + - Navigate to the test report where failures are listed. 2. **Click on a Failed Test** + - Open the specific failing test case you'd like to fix. 3. **Click "Fix with AI"** + - This will trigger Keploy AI to update the assertions based on the current API response. 4. _(Optional)_ **Add Context** + - You can provide hints or expectations to help the AI fix it more precisely. 5. _(Optional)_ **Bulk Fix** + - From the **Test Suites** page, select multiple suites and click **"Fix with AI"** to heal them all in one go. 6. **Wait for AI to Heal** + - The process may take a few seconds to complete. 7. **Find Updated Tests** diff --git a/versioned_sidebars/version-3.0.0-sidebars.json b/versioned_sidebars/version-3.0.0-sidebars.json index 6268e0662..6b9da89aa 100644 --- a/versioned_sidebars/version-3.0.0-sidebars.json +++ b/versioned_sidebars/version-3.0.0-sidebars.json @@ -1,40 +1,5 @@ { "sidebarExplanation": [ - { - "type": "category", - "label": "API Testing", - "collapsed": true, - "items": [ - "running-keploy/api-test-generator", - { - "type": "category", - "label": "Getting Started", - "collapsed": false, - "items": [ - "running-keploy/generate-api-tests-using-ai", - "running-keploy/api-testing-chrome-extension" - ] - }, - { - "type": "category", - "label": "Test Operations", - "collapsed": false, - "items": [ - "running-keploy/review-and-improve-ai-generated-tests", - "running-keploy/share-tests", - "running-keploy/self-healing-ai-api-tests", - "running-keploy/run-ai-generated-api-tests", - "running-keploy/api-testing-cicd", - "running-keploy/api-testing-webhook" - ] - }, - { - "type": "doc", - "label": "FAQs", - "id": "keploy-explained/api-testing-faq" - } - ] - }, { "type": "category", "label": "Integration Testing", @@ -196,6 +161,7 @@ "label": "QuickStarts", "collapsed": true, "items": [ + "quickstart/k8s-proxy", "quickstart/samples-redis", "quickstart/flask-redis", "quickstart/samples-microservices" @@ -215,6 +181,41 @@ } ] }, + { + "type": "category", + "label": "API Testing", + "collapsed": true, + "items": [ + "running-keploy/api-test-generator", + { + "type": "category", + "label": "Getting Started", + "collapsed": false, + "items": [ + "running-keploy/generate-api-tests-using-ai", + "running-keploy/api-testing-chrome-extension" + ] + }, + { + "type": "category", + "label": "Test Operations", + "collapsed": false, + "items": [ + "running-keploy/review-and-improve-ai-generated-tests", + "running-keploy/share-tests", + "running-keploy/self-healing-ai-api-tests", + "running-keploy/run-ai-generated-api-tests", + "running-keploy/api-testing-cicd", + "running-keploy/api-testing-webhook" + ] + }, + { + "type": "doc", + "label": "FAQs", + "id": "keploy-explained/api-testing-faq" + } + ] + }, { "type": "category", "label": "Unit Testing",