How to run the project

This project has been prepared in Cucumber BDD framework using Java. In order to run the project from the terminal, Maven should be installed on the computer and the API should be working at http://localhost:8080/docs (by cloning the assignment and then cd YOUR_FOLDER/SdetAssignment/Assignment1/nodejs-server-server-generated and running npm start) . Running ways:

• Running mvn clean verify on the terminal directly runs the project with current selected tag (@wip over the feature).

• In order to run other tagged scenario (e.g for running only @get tagged scenarios) you can run as the following: mvn clean verify -Dcucumber.filter.tags="@get"

• You can also run by clicking Maven on the right upper side of IntelliJ and then first click clear and click verify.

• By running through MAVEN, Cucumber report is created showing all the passed and failed steps, and failed step logs under target/cucumber-html-reports/overview-failures.html:

• Finally, you can also run by clicking the run button near the public class CukesRunner src/test/java/api/runners/CukesRunner.java. If you can change the tags = "@wip" but this way does not produce fancy cucumber-html-report, instead it only produce the default html report: target/default-html-reports/index.html

Feature Files

They are copied in the features folder for your ease but their original project paths are:

Assignment 1 feature file path is: src/test/resources/features/api.feature

Assignment 2 feature file path is: src/test/resources/features/example.feature

Description of the automation used to execute the project:

• Cucumber BDD framework and Rest-assured library is used for automation.
• GET, POST requests are sent to the API using Rest-assured library.
• Under the utilities package ApiUtils.getData method was created to send a GET request. By using the URL defined for GET request in the OpenAPI, content type and the token and Rest-assured library, this method returns a Response object after the GET request.
• Under the utilities package ApiUtils.sendData method was created to send a POST request. By using the URL defined for POST request in the OpenAPI, content type, messageBody (to be post) and the token and Rest-assured library, returns a Response object after the POST request.
• Using the response objects the expected, actual response properties and texts are asserted using JUnit assertions.
• CukesRunner at src/test/java/api/runners/CukesRunner.java connects all the step_definitions (Java code written for testing), feature files and reporting plugins, such that Cucumber report and default html report are automatically generated in the target folder after running the code in Maven. target/cucumber-html-reports/overview-features.html
• Note: Although the steps with Given generally do not need assertion, I also wrote two methods: patternMatches for valid email check and AssertNoDuplicate for duplicate ids in src/test/java/api/utilities/ApiUtils.java and used them to assert the Given conditions automatically.

Description of the project structure and used packages

• In the pom.xml file Maven , rest-assured, cucumber and junit dependencies are placed and Maven is refreshed.
• configuration.properties is useful place to save some information (like token, uri, email, password) centrally without hard coding in the script. This data can be read using ConfigurationReader.java file under utilities package. By calling this reader with the key required the values are retrieved without explicitly writing the values. token=Bearer fakeToken uri=http://localhost:8080
• Feature file and the test scenario steps are written in plain English of Gherkin language under src/test/resources/features.
• In the CukesRunner, dryRun = True creates the blank step definition snippets which are connected to the feature file.
• The code for every step has been written in src/test/java/api/step_definitions/ApiStepdefs.java
• Under utilities package useful methods are created ApiUtils.java to be able to use directly in the step definitions.
• In the CukesRunner at src/test/java/api/runners/CukesRunner.java, the paths of the feature file and step definitions are placed, and the tagname is placed to according to which tagged scenarios we want to run.
• The code can be run through terminal thanks to the build made by Maven, and the reports are seen in the target folder after the run.

How you would have improved it if you had more time?

• API post request is not working properly in this API, for every post it doesn't change anything in the api. Also there is no GET method for user, the posted user is not seen in the API. Moreover, there is no PUT or PATCH method in general having at least PUt method is a must. the current API has a POST for only sending an amount. This kind of partial change is generally made by PATCH instead. The posted amount also does not change anything. Moreover, status codes written in the documentations are not matching with the API. e.g. API response should be 201 instead of 200. I assumed 200 during testing, as this is a minor design issue.
• If API were worked properly, I could test after each post by a get request whether the request is satisfied or not.
• More negative testing could be done. In fact my code is useful also to do also negative testing, by changing user email or risklevel.
• Schema validation could be done.