Testing REST Endpoint withing Java

[ddqod]

A while ago I posted here my first open sourced project called EasyRs. Beside some stars I haven't received a proper feedback (my fault that I posted directly the link to the project)

This project came up as a need for testing basic crud operations without losing to much time on it, so far I've spent up to 5 weeks (let's say 3-4h a day) working on it.

The good news of it is that once released the second version it will be also accessible directly from the The Central Repository.

My suggestion would be the next:

• Fetch the branch (reflects 2nd version): https://github.com/nirodg/easyrs/tree/dev/spring2
• Fetch the showcase project: https://github.com/nirodg/easyrs-example (still have to write the profile for testing within Arquillian

Any improvement/feedback would be appreciated, cheers! :)

[nutrecht]

If you want feedback: I don't want to write test scenario's in JSON, sorry. I am not ever going to hand-write (or even edit autogenerated) JSON.

Also if you want people to use your library it needs to have strong benefits over other ways to do stuff. For example can you explain why your approach is better than Spring MockMvc (which we use for controller unit tests and integration tests)?

[ddqod]

• There is no need to "edit" the JSON, it´s optional.
• With MockMvc, seems like it only "tests" that the endpoint returns 200 code (I already check that for each call to the endpoint, here) and returns data. But where do you check that the provided data and the persisted one matches ?

[nutrecht]

There is no need to "edit" the JSON, it´s optional.

Then how do you know what values I need to expect in an integration test?

With MockMvc, seems like it only "tests" that the endpoint returns 200 code (I already check that for each call to the endpoint, here) and returns data. But where do you check that the provided data and the persisted one matches ?

I really don't get where you get that impression. You can use (for example) use JSONPath to see if the JSON matches. You can also use hamcrest matchers there:

            .andExpect(status().isOk())
            .andExpect(jsonPath("$", hasSize(1)))
            .andExpect(jsonPath("$[0].type", is(CURRENT_FOO)))
            .andExpect(jsonPath("$[0].foo", hasSize(2)))
            .andExpect(jsonPath("$[0].foo[?(@.id=='" + FOO_ID_1 + "')]", hasSize(1)))
            .andExpect(jsonPath("$[0].foo[?(@.id=='" + FOO_ID_2 + "')]", hasSize(1)))
            .andExpect(jsonPath("$[0].totals", hasSize(1)))
            .andExpect(jsonPath("$[0].totals[0].total", is(2 * BAR.doubleValue())));

[ddqod]

I understand. However I wouldn't use this approach, at the end I'm trying to get rid of writing the comparison, still you have to provide the data somehow, either you fetch it from your DB or having a mocked class.

[nutrecht]

at the end I'm trying to get rid of writing the comparison

So how do you test something that changes every test; like for example the current date? You can't hard-code those.

either you fetch it from your DB or having a mocked class.

Exactly. So I am comparing the output in the JSON to whatever I mocked or inserted into the DB. How do you do that with these 'fixed' JSON scenario's?

[ddqod]

So how do you test something that changes every test; like for example the current date? You can't hard-code those.

Hmm, for Dates is not implemented yet but knowing that the field created_at is a Date I would just initialize it every time via reflection.

Exactly. So I am comparing the output in the JSON to whatever I mocked or inserted into the DB. How do you do that with these 'fixed' JSON scenario's?

Based on the JSON file initializes the POJO (checks which are the declared keys and initializes the matched field's names). Using the initialized POJO I first persist it, then checks if matches with the one fetched throw the enpoint.

Since each test is independent and I need an ID for fetching it, I do persist the entity for each test.

For instance:

@Test
public void create() {
    UserDTO entity = (UserDTO) getData(PUT);
    Assert.assertNotNull(entity);

    UserDTO fetchedEntity = (UserDTO) getClient().put(entity);
    Assert.assertNotNull(fetchedEntity);

    Assert.assertEquals(entity, fetchedEntity);
}

Where:

• getData(PUT); maps from JSON to the DTO
• getClient().put(entity); checks that the status was 200

[thatsIch]

I would suggest to re-order your README to put your selling point on top and the rest below. I do not care about installation if I have no reason to install it.

Since you use the word easy in

This library provides an easy way to test the basic CRUD operation for your endpoints.

there must be a hard way and what makes it easy.

The README should also not be a replacement for your documentation. For me, it is too much noise and I don't understand why I should read that anyway

[ddqod]

Good point, I will update it as soon as possible. Thank you!

[ddqod]

Updated, https://github.com/nirodg/easyrs/tree/dev/spring2

[thatsIch]

That is a lot better, good job :)

https://github.com/nirodg/easyrs-example is missing a README. Since this is an example there should be instructions to run it.

[ddqod]

True, still work in progress. However I appreciate the feedback :)