5 ms·

So how do you test that the method, the path and the body parser are correct? I have had bugs in all of these three.

migf 3y ago
Honestly I think your best bet for this is to have a predictable failure or degenerate input (empty body for post etc) and then write a test that hits all your endpoints in a docker container.
- javcasas 3y ago
  So the plan is code a global try/catch, maybe write an e2e test and hope for the best? Sounds foolproof. I'll continue not doing decorators.
stickfigure 3y ago
These are not really server-side test concerns. I know your first reaction is "WHAT?!" but hear me out. Let's say we add some server-side tests that verify that the method is POST and the path is /make-greeting. Have we now verified that the endpoint is correct? No - because the client was in fact posting to /create-greeting. We know the @POST and @Path annotations work; they are covered by the JAX-RS implementation tests. We can look at those annotations and know that the endpoint is a POST to /make-greeting. Testing that brings minimal value. The test we need is something that ensures the client and server both agree on the contract. By definition that can't be a server-side test, it's an e2e test. The good news is that it doesn't have to be a complicated e2e test; it just needs to ensure the method is called once. Maybe you're publishing a pure API? Add swagger, auto-generate the openapi spec, and diff against that. This works especially well if openapi is how you're publishing your documentation. > and the body parser If you're really concerned, it's pretty easy to write explicit tests for JSON serialization/deserialization. The good news is that you only need one test (or two for bidirectional) for each class. In both large and small companies I've never found this necessary.
- javcasas 3y ago
  I agree to some degree on a basic e2e plus swagger diffs, but > The good news is that you only need one test (or two for bidirectional) for each class. In both large and small companies I've never found this necessary. this tells me you deal with very simplistic data. You are not testing advanced alternatives (algebraic data types), required/non required fields or default values. If you did, you would need at least 2 tests per case.
  - stickfigure 3y ago
    No. Field optionality and the content of values are server-side concerns that can be tested by making plain-old-Java method calls to the endpoint. The shape of serialized JSON doesn't need more than simple verification. And if you just live with default serialization (ie java format is the same as json format), it probably doesn't need to be tested at all.
    - javcasas 3y ago
      Imagine an authentication endpoint that accepts either a username/password or a SSH key. If you go the optional fields route, your parser will accept invalid combinations, for example password+ssh key. If you go the proper alternatives way, then you need a parser with two branches that parses user/password in one way, or ssh key the other way. You tell me simple verification is enough, hence you either have a parser that accepts bad data, or deal only with simplistic data so that the parser can't have branches.

migf 3y ago

Honestly I think your best bet for this is to have a predictable failure or degenerate input (empty body for post etc) and then write a test that hits all your endpoints in a docker container.

javcasas 3y ago
So the plan is code a global try/catch, maybe write an e2e test and hope for the best? Sounds foolproof. I'll continue not doing decorators.

stickfigure 3y ago

These are not really server-side test concerns. I know your first reaction is "WHAT?!" but hear me out. Let's say we add some server-side tests that verify that the method is POST and the path is /make-greeting. Have we now verified that the endpoint is correct? No - because the client was in fact posting to /create-greeting. We know the @POST and @Path annotations work; they are covered by the JAX-RS implementation tests. We can look at those annotations and know that the endpoint is a POST to /make-greeting. Testing that brings minimal value. The test we need is something that ensures the client and server both agree on the contract. By definition that can't be a server-side test, it's an e2e test. The good news is that it doesn't have to be a complicated e2e test; it just needs to ensure the method is called once. Maybe you're publishing a pure API? Add swagger, auto-generate the openapi spec, and diff against that. This works especially well if openapi is how you're publishing your documentation. > and the body parser If you're really concerned, it's pretty easy to write explicit tests for JSON serialization/deserialization. The good news is that you only need one test (or two for bidirectional) for each class. In both large and small companies I've never found this necessary.

javcasas 3y ago
I agree to some degree on a basic e2e plus swagger diffs, but > The good news is that you only need one test (or two for bidirectional) for each class. In both large and small companies I've never found this necessary. this tells me you deal with very simplistic data. You are not testing advanced alternatives (algebraic data types), required/non required fields or default values. If you did, you would need at least 2 tests per case.
- stickfigure 3y ago
  No. Field optionality and the content of values are server-side concerns that can be tested by making plain-old-Java method calls to the endpoint. The shape of serialized JSON doesn't need more than simple verification. And if you just live with default serialization (ie java format is the same as json format), it probably doesn't need to be tested at all.
  - javcasas 3y ago
    Imagine an authentication endpoint that accepts either a username/password or a SSH key. If you go the optional fields route, your parser will accept invalid combinations, for example password+ssh key. If you go the proper alternatives way, then you need a parser with two branches that parses user/password in one way, or ssh key the other way. You tell me simple verification is enough, hence you either have a parser that accepts bad data, or deal only with simplistic data so that the parser can't have branches.