Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mock example #2

Open
wants to merge 47 commits into
base: main
Choose a base branch
from
Open

Mock example #2

wants to merge 47 commits into from

Conversation

sreepathysois
Copy link
Collaborator

Version 1 of Schdeuler Test Harness with Gherkin Feature and Step_Defs Implementation Codes
Mock_Example Branch is Created to Open API Test Harness of Scheduler BB against Mock Server using BDD Approach for Testing

Description

Updated Scheduler Open API Spec File is tested using BDD Approach using Gherkin Feature File to specify Smoke, Positive/Happy Regression and Negative Unit and Regression tresting Scenarios with relevant Examples. API Testing is implemented using Mockoon-CLI as a Mock example and Pytest-BDD is used to write test implementation codes.

Changes Compared to main Branch

Feature Files for all request of Open API Endpoints and implementation Codes are Uploaded in test/Folder of mock_example Branch.
API Spec of Scheduler is updated in api/ folder.
Docker-Compose based config file to provision Mockoon Container and Test Environment is uploaded to examples/mock Folder,

Motivation and Context

Create a Version 1 Test Harness to test Scheduler API Compatability with GovStack Standards

How Has This Been Tested?

Mock Example is tested using CircleCI Config to Provision Mock Server and Generate Test Results in JSON Format and Also generate Test Summary Results.

@KarolinaKopacz KarolinaKopacz self-requested a review May 17, 2023 08:35
Copy link

@KarolinaKopacz KarolinaKopacz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really good job @sreepathysois !
I added some comments. They apply to all .feature files.

I also have small suggestion. Your PR is large. It is a good practice to add a smaller PR (in this case breaking this pull request into smaller ones) because it is easier and faster to check such code. It's also easier to make corrections, especially if they are repeated in other files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants