Responses with 5xx errors are breaking tests

[Kuzzy]

When I'm throwing exception with status 5xx response never comes into test. 4xx errors are working as expected.

Steps:

1. Create custom exception: node ace make:exception Test

export default class TestException extends Exception {
  public handle(error: this, ctx: HttpContextContract) {
    ctx.response.status(error.status).send(error.message)
  }
}

3. Make a route

// start/routes.ts

import Route from '@ioc:Adonis/Core/Route'
import Test from 'App/Exceptions/TestException'

Route.get('/', async () => {
  throw new Test('Test', 500, 'E_TEST')
})

4. Make a test:

// tests/functional/hello_world.spec.ts
import { test } from '@japa/runner'

test('display welcome page', async ({ client }) => {
  const response = await client.get('/')
  response.assertStatus(500)
})

Result:

Error pops in the test and break it.

Expected:
Error returned with response, assertion returns true and test not fails.

Is this behaviour by design? If so, how to make tests for such errors? Wrap every request in tests in try/catch looks too cumbersome.

[filev-svt]

I have the same issue even with 4xx Exceptions and Exceptions in general. It really is somewhat beating the purpose of throwing Exceptions as the documentation suggests. I have to ignore multiple test scenarios, where an Exception is thrown and handled, yet I can't test them, because the Exception breaks the tests, even though the route handles the Exception and returns a corresponding response.

When testing manually in the browser, everything seems to be working fine. Surely there must be a way to test the routes handling Exceptions without wrapping each test inside a try-catch?

[epileftro85]

Has anyone get it to work_

[thetutlage]

500 is not a normal exception of some flow, it is a server error caused when server is down or a fatal error was thrown.

Therefore, these errors must be handled explicitly within the tests. Wrapping code in a try/catch is not as bad as it sounds.

[filev-svt]

In my case I switched the thrown external dependency API error codes from 503 to 424 and it seemed to have mostly done the trick. It might also be the more accurate way to indicate those situations. The other issues are caused by axios' error handling, which of cause is not our concern. Thanks for the answer anyway @thetutlage , appreciate the effort.