diff --git a/static/img/Keploy-record-openhospital.png b/static/img/Keploy-record-openhospital.png new file mode 100644 index 000000000..f89541e9a Binary files /dev/null and b/static/img/Keploy-record-openhospital.png differ diff --git a/static/img/Keploy-test-openhospital.png b/static/img/Keploy-test-openhospital.png new file mode 100644 index 000000000..131214961 Binary files /dev/null and b/static/img/Keploy-test-openhospital.png differ diff --git a/static/img/Testcases-results-openhospital.png b/static/img/Testcases-results-openhospital.png new file mode 100644 index 000000000..0b466b449 Binary files /dev/null and b/static/img/Testcases-results-openhospital.png differ diff --git a/static/img/openhospital-ui.png b/static/img/openhospital-ui.png new file mode 100644 index 000000000..950b22937 Binary files /dev/null and b/static/img/openhospital-ui.png differ diff --git a/static/img/result-openhospital.png b/static/img/result-openhospital.png new file mode 100644 index 000000000..487a6ffe4 Binary files /dev/null and b/static/img/result-openhospital.png differ diff --git a/versioned_docs/version-2.0.0/ci-cd/github.md b/versioned_docs/version-2.0.0/ci-cd/github.md index 6aa74bfb4..b45a181de 100644 --- a/versioned_docs/version-2.0.0/ci-cd/github.md +++ b/versioned_docs/version-2.0.0/ci-cd/github.md @@ -122,8 +122,8 @@ _And... voila! You have successfully integrated keploy in GitHub CI pipeline ## GitHub Actions -GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow unde `.github/workflow` with the name `keploy-test.yml`: - -GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow unde `.github/workflow` with the name `keploy-test.yml`: - +GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow under `.github/workflow` with the name `keploy-test.yml`: - +GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow under `.github/workflow` with the name `keploy-test.yml`: - ```yaml jobs: diff --git a/versioned_docs/version-2.0.0/dependencies/http.md b/versioned_docs/version-2.0.0/dependencies/http.md index f2e5f1634..c31d27bf5 100644 --- a/versioned_docs/version-2.0.0/dependencies/http.md +++ b/versioned_docs/version-2.0.0/dependencies/http.md @@ -39,7 +39,7 @@ The http parser is basically divided into two sections, `encode` and `decode`, t So in the record mode, the encode function is provided with the initial request, which is written to the destination connection and checked if the request is chunked, if it is then parser keeps reading the request from the client connection and write it to the destination connection. -Next, if the request contains the expect header or not. The expect header is used by a client when sending very large requests. So it is basically used to ask the server if it is ready to accept such a large req or not, if it is, then the server responds with a `"100-continue"` response. This is what we also check by writing the request to the destination connection and reading the respnse from it. We start reading the response and we handle chunking in that case as well. Then finally, keploy parse the request and response to store it in mocks. +Next, if the request contains the expect header or not. The expect header is used by a client when sending very large requests. So it is basically used to ask the server if it is ready to accept such a large req or not, if it is, then the server responds with a `"100-continue"` response. This is what we also check by writing the request to the destination connection and reading the response from it. We start reading the response and we handle chunking in that case as well. Then finally, keploy parse the request and response to store it in mocks. Hope this helps you out, if you still have any questions, reach out to us . 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 afe37efac..ee385da9a 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 @@ -37,20 +37,23 @@ import InstallationGuide from '../concepts/installation.md' This project has Three parts - the UI, Core and API, since Keploy is a backend testing platform, we need to start the Backend of the project using Keploy and run the frontend as it is. +If you want to try this quickstart setup on a Mac, use Lima. If you're on Windows, use WSL. + ## Setup the Core ```bash git clone https://github.com/keploy/openhospital-core git checkout integration-with-keploy -sudo apt install -y maven mvn clean install -DskipTests=true -sudo docker compose up +docker compose up ``` +Note: If you face any issues while setting up the database, please try running docker compose up again. The issue should not occur the second time. + ## Setup the Backend -Now it's time to setup the backend of our application. Let's Download the Openhospital API and get started. +Now it's time to setup the backend of our application. Let's Install the Openhospital API and get started. ```bash git clone https://github.com/keploy/openhospital-api @@ -58,7 +61,7 @@ git checkout integration-with-keploy mvn clean install -DskipTests=true ``` -You can start the Backend using Keploy cli: +Now it's time to start the Backend using Keploy cli: # Instructions For Starting Using Binary @@ -74,6 +77,8 @@ Prerequisites For Binary: keploy record -c "java -cp "target/openhospital-api-0.1.0.jar:rsc/:static/" org.springframework.boot.loader.launch.JarLauncher" ``` +Sample Keploy Record Java + ## Start the frontend ```bash @@ -84,6 +89,9 @@ npm start ``` Note: Login with username `admin` and password `admin` +Sample Keploy Record Java + +If you followed all the steps correctly, you should see a UI similar to the one shown above. Now you can start interacting with the UI and Keploy will automatically create the testcases and mocks for it in a folder named 'keploy' @@ -96,6 +104,12 @@ 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 +Sample Keploy Test Java + +This is a summary of the test cases recorded +Sample Keploy Test Summary Java + 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-jwt-sql.md b/versioned_docs/version-2.0.0/quickstart/node-jwt-sql.md index 5acf282b0..b8d6264f2 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 @@ -175,8 +175,8 @@ Our testcases will fail as the token would expire and new Token will generated a Sample Keploy Test Result Node JWT -But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10mins. 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 10mins. 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:- +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:- ``` noise: @@ -319,7 +319,7 @@ Our testcases will fail as the token would expire and new Token will generated a Sample Keploy Test Result Node JWT -But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10mins. 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:- ``` noise: diff --git a/versioned_docs/version-2.0.0/server/sdk-installation/python.md b/versioned_docs/version-2.0.0/server/sdk-installation/python.md index 735d0092d..bf79db7ca 100644 --- a/versioned_docs/version-2.0.0/server/sdk-installation/python.md +++ b/versioned_docs/version-2.0.0/server/sdk-installation/python.md @@ -32,7 +32,7 @@ To get the coverage data for your unit tests: coverage run --data-file=.coverage.unit test_program.py ``` -Here, test_program.py is the unit test program you want to run, and --data-file is set to .coverage.unit becuase, by default, raw coverage data would be written to .coverage which is where coverage data for keploy tests is present, so to avoid overwritting we pass a new file through data-file flag. +Here, test_program.py is the unit test program you want to run, and --data-file is set to .coverage.unit because, by default, raw coverage data would be written to .coverage which is where coverage data for keploy tests is present, so to avoid overwriting we pass a new file through data-file flag. > Note: If you face any problems with running the coverage library, you can refer to the documentation.