OBPIH-5936 Add tests for REST APIs to avoid regression by chetanmaharishi · Pull Request #4360 · openboxes/openboxes

chetanmaharishi · 2023-10-27T15:40:36Z

First commit of Rest assured testing for ProductApi list

awalkowiak

@chetanmaharishi please don't use ; at the end of lines and add spaces around operators, before opening {, and after the if keyword.

kchelstowski

and as @awalkowiak said, add indents between {, (, ), + and remove ; as it is not necessary to write them in Groovy.

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

kchelstowski · 2023-10-30T16:48:53Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+import org.testng.annotations.BeforeClass;
+import org.testng.annotations.Test;
+
+import static io.restassured.RestAssured.*;


I would say importing everything from a package is not a good practice. We should import only what is needed. (Remove * and replace it with imports that are needed)

ok i will make this changes

kchelstowski · 2023-10-30T16:49:26Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+class ProductApiTest{
+
+    Map headers = [:]
+    String baseURI = "http://localhost:8080/openboxes";


I don't think if hardcoding this url is a good idea, but since I am not a good test-writer, I don't know if we can get an access to context path at this point.

Thanks @kchelstowski I was just going to mention this.

Note that the Rest Assured tests are executed in an isolated execution context (either as a separate process or on a separate machine) so it's sort of like running postman tests. Therefore, the API instance will be up and running before these tests are run which means we have the ability to change this URL when we execute the tests. We could even move these tests to a separate github repository to make it more clear that the tests are somewhat independent from the API. However, I don't want to do that because I want them to evolve together so we can create new tests in feature branches that live alongside the code.

I'm currently reading Testing Web APIs to see if there are any best practices to keep in mind when running these Rest Assured tests https://www.manning.com/books/testing-web-apis but I suspect that we should at least provide a default API URL in configuration that can be overridden by a system environment variable or external configuration file.

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

kchelstowski · 2023-10-30T16:50:04Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+        Assert.assertEquals(statusCode, 200);
+        Assert.assertEquals(data, []);
+    }
+}


add an empty line at the end of the file

jmiranda

Added some preliminary comments for now.

jmiranda · 2023-10-30T17:09:40Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+class ProductApiTest{
+
+    Map headers = [:]
+    String baseURI = "http://localhost:8080/openboxes";


Thanks @kchelstowski I was just going to mention this.

jmiranda · 2023-10-30T17:16:22Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+class ProductApiTest{
+
+    Map headers = [:]
+    String baseURI = "http://localhost:8080/openboxes";


Note that the Rest Assured tests are executed in an isolated execution context (either as a separate process or on a separate machine) so it's sort of like running postman tests. Therefore, the API instance will be up and running before these tests are run which means we have the ability to change this URL when we execute the tests. We could even move these tests to a separate github repository to make it more clear that the tests are somewhat independent from the API. However, I don't want to do that because I want them to evolve together so we can create new tests in feature branches that live alongside the code.

I'm currently reading Testing Web APIs to see if there are any best practices to keep in mind when running these Rest Assured tests https://www.manning.com/books/testing-web-apis but I suspect that we should at least provide a default API URL in configuration that can be overridden by a system environment variable or external configuration file.

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

3 more test case written 1. get demand of product 2. get demand summary of product 3. get summary of product

jmiranda · 2023-11-02T03:05:49Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+    void setup() {
+        if (!setupInitialized) {
+            RequestSpecification httpRequest = given().formParam("username", "admin").formParam("password", "password");
+            Response response = httpRequest.post(baseURI + "/auth/handleLogin");


Use the /api/login so you can pass the location ID there.

jmiranda · 2023-11-02T03:08:32Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+
+    void "read product list"() {
+        when: "/api/products end point called"
+        RequestSpecification httpRequest = given().header("Cookie", "${headers.Cookie}");


Make sure you pass an Accept header to ensure you get a JSON response.

RequestSpecification httpRequest = given().header("Accept", "application/json") .header("Cookie", "${headers.Cookie}")

Otherwise we get this when running tests

io.restassured.path.json.exception.JsonPathException: Failed to parse the JSON document at io.restassured.path.json.JsonPath$ExceptionCatcher.invoke(JsonPath.java:930) at io.restassured.path.json.JsonPath$4.doParseWith(JsonPath.java:895) at io.restassured.path.json.JsonPath$JsonParser.parseWith(JsonPath.java:975) at io.restassured.path.json.JsonPath.get(JsonPath.java:201) at unit.org.pih.warehouse.api.ProductApiTest.get demand of product(ProductApiTest.groovy:76) Caused by: groovy.json.JsonException: Lexing failed on line: 1, column: 1, while reading '<', no possible valid JSON value or punctuation could be recognized. at groovy.json.JsonLexer.nextToken(JsonLexer.java:87) at io.restassured.internal.path.json.ConfigurableJsonSlurper.parse(ConfigurableJsonSlurper.groovy:97) at io.restassured.internal.path.json.ConfigurableJsonSlurper.parseText(ConfigurableJsonSlurper.groovy:83) at io.restassured.path.json.JsonPath$4$1.method(JsonPath.java:893) at io.restassured.path.json.JsonPath$ExceptionCatcher.invoke(JsonPath.java:928) ... 4 more

jmiranda · 2023-11-02T03:09:39Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+
+    void setup() {
+        if (!setupInitialized) {
+            RequestSpecification httpRequest = given().formParam("username", "admin").formParam("password", "password");


Username and password should be @shared and should probably be configurable like the URL.

jmiranda · 2023-11-08T04:08:37Z

Can you guys review this PR again? And if possible, help us figure out what to do about the failing unit tests. Chetan thinks these REST API tests should be executed as unit tests because they don't require the application to be started i.e. we can tests another OpenBoxes instance somewhere else. Moving the tests to the integration test phase will create a lot more overhead, but I can't see another way of segmenting these REST API tests from the unit tests.

cc @awalkowiak @kchelstowski @alannadolny @drodzewicz

alannadolny

I will get back to this later to try to check the failing unit tests. (Unless someone else comes up with the solution 😄)

alannadolny · 2023-11-08T10:20:43Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+class ProductApiTest extends Specification {
+
+    @Shared
+    String baseURI = System.getProperty("server.host")?:"http://localhost"


Please add whitespace after and before the Elvis operators

Suggested change

String baseURI = System.getProperty("server.host")?:"http://localhost"

String baseURI = System.getProperty("server.host") ?: "http://localhost"

I actually hate the extra whitespace, but fine.

alannadolny · 2023-11-08T10:21:46Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+    String basePath = System.getProperty("server.path")?:"/openboxes"
+
+    @Shared
+    int port = System.getProperty("server.port")?Integer.valueOf(System.getProperty("server.port")):8080


Add the whitespace after and before the ternary operators

Suggested change

int port = System.getProperty("server.port")?Integer.valueOf(System.getProperty("server.port")):8080

int port = System.getProperty("server.port") ? Integer.valueOf(System.getProperty("server.port")) : 8080

remember about the other two below also

alannadolny · 2023-11-08T10:23:14Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+        JSONObject jsonObject = new JSONObject().
+                put("username", username).
+                put("password", password).
+                put("location", 1)


Those dots shouldn't be at the beginning of the next lines?

Suggested change

JSONObject jsonObject = new JSONObject().

put("username", username).

put("password", password).

put("location", 1)

JSONObject jsonObject = new JSONObject()

.put("username", username)

.put("password", password)

.put("location", 1)

Hmm, I've never seen that syntax. Do you have a reference for that somewhere in Java / Groovy docs?

The rest assured docs provide a bunch of examples that use the syntax I used above.
https://github.com/rest-assured/rest-assured/wiki/Usage

And it looks like IntelliJ sometimes breaks when using the period at the beginning of the line (this is for a package name, but still makes me wary)
https://youtrack.jetbrains.com/issue/IDEA-242633/Groovy-code-formatting-incorrectly-wraps-qualified-new-expression-which-leads-to-compiler-error

I've never seen that syntax 😅
I tried to search for breaking chain calls with the dot at the beginning, and I found a bunch of pages with this.

https://unibeautify.com/docs/option-break-chained-methods

Break on multiple chained calls prettier/prettier#1565

https://www.baeldung.com/java-config-spring-security

I can see it also in the spring security official docs https://spring.io/guides/gs/securing-web/

Ok, so there's some evidence for leading over trailing, so we should have a discussion about this. I guess I've mostly stayed to one line when chaining but I've only ever remembered seeing a trailing dot whenever I've seen chaining. I honestly don't recall ever seeing a leading dot.

Interesting discussion in the Ruby with mixed feelings.

standardrb/standard#75
https://www.reddit.com/r/ruby/comments/8sc7gx/leading_vs_trailing_dots_why_to_try_trailing_dots/

Phew I'm not insane

https://youtrack.jetbrains.com/issue/IDEA-123881/Code-Formatting-method-chain-wrapping-Java-configure-position-of-dot-operator#focus=Comments-27-1113618.0-0

@kchelstowski @alannadolny Ok, after giving this a few days to marinate, I think I'm starting to warm up to the leading dot. I'm not 100% sold yet and I don't necessarily want to apply the line per method convention (like in the following example). But the leading dot does make it more readable.

alannadolny · 2023-11-08T10:28:27Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+
+        // Get a single product to pass to the next test
+        when: "we attempt to share a product with the next test"
+        ProductResponse product = response.then().body().extract().jsonPath().getObject("data[0]", ProductResponse)


Shouldn't we add new lines when we are calling multiple methods at once? I think we should try to avoid long lines like that (for example, on the frontend we have configured eslint with a maximum length of 100). It is harder to read for example in code review, when the line is too long.

I don't mind breaking it up if there's a logical break (maybe after body and then again after jsonPath) but I also don't think it's necessary unless we go over the 100-120 character limit of the line. Which I'm guessing we are.

But I don't have a strong feeling. In fact, I don't mind the one line per method (example below). I just don't want these tests to be 1000s of lines unnecessarily.
https://www.baeldung.com/rest-assured-response

alannadolny · 2023-11-08T10:29:28Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+//        then: "data should not be null"
+//        Assert.assertNotNull(data)
+//        and: "product should not be null"
+//        Assert.assertNotNull(data.product, "Response should have product object")
+//        and: "product ID should not be null"
+//        Assert.assertEquals(data.product.id, productId, "Product id should match with requested id:${productId}")
+//        and: "demand should not be null"
+//        Assert.assertNotNull(data.demand, "Demand Object should not be null")


Should it be commented?

Chetan is supposed to turn those into rest assured asserts.

alannadolny · 2023-11-08T10:30:51Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+class ProductResponse {
+    String id


Add new line

Suggested change

class ProductResponse {

String id

class ProductResponse {

String id

I think there is no need to add an empty line here.
Lately I've been trying to do a research whether the properties should be even separated by an empty line if they don't contain any annotations above, but can't find any good resource about that.
I meant:

class ProductResponse { String id String productCode String name }

vs

class ProductResponse { String id String productCode String name }

I am a fan of adding a new line before each property (the first version), but if u think there is no need, it can stay

Can we spend some more time on the substance? This class is going to be removed once we deal with the inconsistences within our JSON responses. We just needed a temporary solution to write these reference implementation tests.

alannadolny · 2023-11-08T10:35:03Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+import static io.restassured.RestAssured.*
+import io.restassured.response.Response
+import static org.hamcrest.MatcherAssert.assertThat
+import static org.hamcrest.Matchers.is
+import static org.hamcrest.Matchers.notNullValue
+import static org.hamcrest.Matchers.lessThanOrEqualTo


I think import static should be placed below the "normal" imports. This is also the default behavior when we are adding new imports through Intellij. And also we shouldn't import things using *, because there can be a lot of unnecessary imported things (I think this change request was mentioned before, but I am not sure)

Suggested change

import static io.restassured.RestAssured.*

import io.restassured.response.Response

import static org.hamcrest.MatcherAssert.assertThat

import static org.hamcrest.Matchers.is

import static org.hamcrest.Matchers.notNullValue

import static org.hamcrest.Matchers.lessThanOrEqualTo

import io.restassured.response.Response

import static io.restassured.RestAssured.*

import static org.hamcrest.MatcherAssert.assertThat

import static org.hamcrest.Matchers.is

import static org.hamcrest.Matchers.notNullValue

import static org.hamcrest.Matchers.lessThanOrEqualTo

Check style seems to suggest the opposite.
https://checkstyle.sourceforge.io/checks/imports/importorder.html#:~:text=group%20of%20static%20imports%20is,and%20aren't%20separated%20internally

So let's find a definitive source or just ignore it.

Hm, I can see similar imports to this which I suggested in our code

If the static imports should be placed before normal imports (as I can see on the page you linked), then I am sorry for the confusion, I mean to keep those imports cleaner.

@alannadolny I honestly don't know what's best. When I saw the recommendation for putting static imports up top I was surprised. Just adding this to "we don't yet know the definitive answer" so we'll need to research it. I just don't want to spend too much time researching some of these syntax issues when we could be spending that time actually making tests work.

kchelstowski · 2023-11-08T11:00:52Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+import org.grails.web.json.JSONObject
+import spock.lang.Shared
+import spock.lang.Specification
+import static io.restassured.RestAssured.*


the * imports have not been fixed (I've mentioned that in my initial review)

I wish we had something like pmd checkstyle (I don't know if it is available in Groovy/Grails), but it would catch those things.
I also think that the imports should be grouped differently - the static imports should be at the beginning and be separated with one empty line, but since we don't have any strict rules regarding that, you can skip that grouping - just wanted to mention that.

Agreed, it would be nice.

kchelstowski · 2023-11-08T11:06:17Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+    String basePath = System.getProperty("server.path")?:"/openboxes"
+
+    @Shared
+    int port = System.getProperty("server.port")?Integer.valueOf(System.getProperty("server.port")):8080


remember about the other two below also

kchelstowski · 2023-11-08T11:06:43Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+        Response response = given().log().all().
+                contentType(ContentType.JSON).
+                body(jsonObject.toString()).
+                post("/api/login")


here dots also should be at the beginning of the line

Again, where have you seen this syntax? Is that a javascript thing?

kchelstowski · 2023-11-08T11:07:23Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+                post("/api/login")
+
+        // Make sure we were successfully authenticated
+        response.then().assertThat().statusCode(200)


it would be good to do it by one line -> one call:

response .then() .assertThat() .statusCode(200)

kchelstowski · 2023-11-08T11:07:34Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+                setBasePath(basePath).
+                setPort(port).
+                addCookie(cookie).
+                setAccept(ContentType.JSON).build()


kchelstowski · 2023-11-08T11:07:47Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+
+        when: "we get products from the API"
+        // FIXME figure out better way to set up baseURI using RestAssured API
+        Response response = request.when().get("/api/products?max=10")


kchelstowski · 2023-11-08T11:07:51Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+        Response response = request.when().get("/api/products?max=10")
+
+        // FIXME Should be replaced by Product domain class once we
+        List<ProductResponse> products = response.then().log().all().extract().body().jsonPath().


kchelstowski · 2023-11-08T11:08:13Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+        response.then().assertThat().statusCode(200)
+//        Assert.that(is(notNullValue(data)))
+//        and:
+//        Assert.that(is(data.size(), equalTo(0)))


should it removed/uncommented?

@chetanmaharishi can you turn these into valid rest-assured assert thingees like the first example I did.

kchelstowski · 2023-11-08T11:08:23Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+//        Assert.assertEquals(data.location.id, locationId, "Location id should be ${locationId}")
+//        and:
+//        Integer quantityOnHand = data.quantityOnHand ?: 0
+//        Assert.assertEquals(quantityOnHand, 0, "QuantityOnHand should be 0")


should it be removed/uncommented?

@chetanmaharishi Same.

kchelstowski · 2023-11-08T11:08:39Z

src/test/groovy/unit/org/pih/warehouse/api/ProductApiTest.groovy

+class ProductResponse {
+    String id


I think there is no need to add an empty line here.
Lately I've been trying to do a research whether the properties should be even separated by an empty line if they don't contain any annotations above, but can't find any good resource about that.
I meant:

class ProductResponse { String id String productCode String name }

vs

class ProductResponse { String id String productCode String name }

awalkowiak · 2024-02-26T16:19:53Z

We are temporarily archiving / ice-boxing this until we make a decision on where these tests go

First commit of Rest assured testing for ProductApi list

d1d42aa

chetanmaharishi requested a review from jmiranda October 27, 2023 15:40

awalkowiak reviewed Oct 27, 2023

View reviewed changes

jmiranda requested review from alannadolny, drodzewicz and kchelstowski October 30, 2023 16:35

kchelstowski requested changes Oct 30, 2023

View reviewed changes

jmiranda reviewed Oct 30, 2023

View reviewed changes

jmiranda changed the title ~~First commit of Rest assured testing for ProductApi list~~ OBPIH-5936 Add tests for REST APIs to avoid regression Oct 30, 2023

jmiranda marked this pull request as draft October 30, 2023 21:08

jmiranda and others added 3 commits October 30, 2023 23:16

OBPIH-5936 Fixed dependency resolution issue for testng framework

d215eb8

Running rest assured with spock framework

396797c

implemented setup chooselocation

3403222

3 more test case written 1. get demand of product 2. get demand summary of product 3. get summary of product

jmiranda reviewed Nov 2, 2023

View reviewed changes

jmiranda added 4 commits November 3, 2023 10:53

OBGM-714 Refactored rest-assured tests to make better use of the library

b3907eb

OBGM-714 Created config for executing API tests via Github actions

9d78fa8

OBGM-714 Added feature branches to API test triggers

0954861

OBGM-714 Configured github action for API tests to use Java 8

93abf95

alannadolny reviewed Nov 8, 2023

View reviewed changes

kchelstowski requested changes Nov 8, 2023

View reviewed changes

Implemented Product create and update test

0d58f21

jmiranda added this to the 0.9.1 milestone Dec 4, 2023

chetanmaharshi added 2 commits December 12, 2023 16:10

using system variables to run npm or not while doing gradle bootRun

86abc4f

removed println statements

b3cce03

awalkowiak added the status: wont do Issues that we will not be addressing but can be revisited in the future label Feb 26, 2024

awalkowiak closed this Feb 26, 2024

ewaterman mentioned this pull request Apr 24, 2024

OBPIH-5936 initial rest assured API tests #4600

Merged

	String baseURI = System.getProperty("server.host")?:"http://localhost"
	String baseURI = System.getProperty("server.host") ?: "http://localhost"

	int port = System.getProperty("server.port")?Integer.valueOf(System.getProperty("server.port")):8080
	int port = System.getProperty("server.port") ? Integer.valueOf(System.getProperty("server.port")) : 8080

Uh oh!

Conversation

chetanmaharishi commented Oct 27, 2023

Uh oh!

awalkowiak left a comment

Choose a reason for hiding this comment

Uh oh!

kchelstowski left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmiranda left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmiranda commented Nov 8, 2023

Uh oh!

alannadolny left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alannadolny Nov 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmiranda Nov 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

alannadolny Nov 19, 2023 •

edited

Loading

jmiranda Nov 19, 2023 •

edited

Loading

alannadolny Nov 8, 2023 •

edited

Loading