1 Within unit tests we operate only with methods of a class. Within components tests we can operate with several classes.
But we don't know anything about controllers, endpoints, threads, timers, file system in unit (and component) tests.
We know about them in integration tests.
Remember last year where we had to fight with crazy "unit tests" that run for ages :-) Lack of separation between tests was the major issue I saw in all products.
Pure unit and component tests run super fast since they operate only with RAM.
2 Let's identify what we want to test ignoring how we name this test (i.e. integration or unit test).
If we test an endpoint (web service according to target post), probably we want to verify how this endpoint reacts to incoming requests by checking what is returned as a response.
Since response body is plain text in our case this is what we want to check.
But we convert this body to some format by adding some workarounds to achieve that and just to finally verify the body itself. Why not to verify the body as is without redundant conversion to some format? :-)
So we could replace .andExpect(jsonPath("$.value", is(ExampleController.VALUE_DOUBLE_FAIL)));
with .andExpect(jsonPath("$.value",
is(ExampleController.VALUE_BIG_DECIMAL_FAIL.toString())));
and remove a workaround with JSON parser. Please note that this is a pseudo code (i.e. comparing string values) but the idea should be clear.
In this case we don't loose anything since we verify the only thing we care - response body.
Software engineer with over 10 years experience in different technology stacks, architecting, developing, CI/CD and leading teams. Currently working with Java, Node.JS and Serverless
I'm talking about unit tests as such that do not require whole spring context to start.
That won't work because of the library limitation. I see your point but that's how the asserts works. If you try to compare "to-string" expected value with the decimal value from controller they will fail. The library would need to convert the decimals somewhow to string before the assert and this would also be a smelly hack :) In current state you'll get:
java.lang.AssertionError: JSON path "$.value"
Expected: is "0.071854545056424"
but: was <0.071854545056424>
Expected :is "0.071854545056424"
Actual :<0.071854545056424>
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
1 Within unit tests we operate only with methods of a class. Within components tests we can operate with several classes.
But we don't know anything about controllers, endpoints, threads, timers, file system in unit (and component) tests.
We know about them in integration tests.
Remember last year where we had to fight with crazy "unit tests" that run for ages :-) Lack of separation between tests was the major issue I saw in all products.
Pure unit and component tests run super fast since they operate only with RAM.
2 Let's identify what we want to test ignoring how we name this test (i.e. integration or unit test).
If we test an endpoint (web service according to target post), probably we want to verify how this endpoint reacts to incoming requests by checking what is returned as a response.
Since response body is plain text in our case this is what we want to check.
But we convert this body to some format by adding some workarounds to achieve that and just to finally verify the body itself. Why not to verify the body as is without redundant conversion to some format? :-)
So we could replace
.andExpect(jsonPath("$.value", is(ExampleController.VALUE_DOUBLE_FAIL)));with
.andExpect(jsonPath("$.value",
is(ExampleController.VALUE_BIG_DECIMAL_FAIL.toString())));
and remove a workaround with JSON parser. Please note that this is a pseudo code (i.e. comparing string values) but the idea should be clear.
In this case we don't loose anything since we verify the only thing we care - response body.
I'm talking about unit tests as such that do not require whole spring context to start.
That won't work because of the library limitation. I see your point but that's how the asserts works. If you try to compare "to-string" expected value with the decimal value from controller they will fail. The library would need to convert the decimals somewhow to string before the assert and this would also be a smelly hack :) In current state you'll get: