fix: openhospital-docs-images-added

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:

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 .
 

versioned_docs/version-2.0.0/quickstart/java-spring-boot-openhospital.md

@@ -37,28 +37,31 @@ 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
 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"
 ```
 
+<img src="/docs/img/Keploy-record-openhospital.png" alt="Sample Keploy Record Java" width="100%" style={{ borderRadius: '5px' }} />
+
 ## Start the frontend
 
 ```bash
@@ -84,6 +89,9 @@ npm start
 ```
 
 Note: Login with username `admin` and password `admin`
+<img src="/docs/img/openhospital-ui.png" alt="Sample Keploy Record Java" width="100%" style={{ borderRadius: '5px' }} />
+
+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
+<img src="/docs/img/Keploy-test-openhospital.png" alt="Sample Keploy Test Java" width="100%" style={{ borderRadius: '5px' }} />
+
+This is a summary of the test cases recorded
+<img src="/docs/img/result-openhospital.png" alt="Sample Keploy Test Summary Java" width="100%" style={{ borderRadius: '5px' }} />
+
 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.
 

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
 
 <img src="/docs/img/jwt-test-fail.png" alt="Sample Keploy Test Result Node JWT" width="100%" style={{ borderRadius: '5px' }} />
 
-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
 
 <img src="/docs/img/jwt-test-fail.png" alt="Sample Keploy Test Result Node JWT" width="100%" style={{ borderRadius: '5px' }} />
 
-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:

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.