require "rails_helper"

RSpec.describe "/healthcheck", type: :request do
  def data(body = response.body)
    JSON.parse(body).deep_symbolize_keys
  end

  it "should respond with ok" do
    get "/healthcheck"

    expect(response.status).to eq(200)
    expect(data.fetch(:status)).to eq("ok")
  end

  it "includes useful information about each check" do
    get "/healthcheck"

    expect(data.fetch(:checks)).to include(
      database_connectivity: { status: "ok" },
      redis_connectivity:    { status: "ok" },
      sidekiq_queue_latency: hash_including(status: "ok"),
    )
  end
end

require "rails_helper"

RSpec.describe "/healthcheck", type: :request do
  def data(body = response.body)
    JSON.parse(body).deep_symbolize_keys
  end

  it "should respond with ok" do
    get "/healthcheck"

    expect(response.status).to eq(200)
    expect(data.keys).to include(:checks, :status)
  end

  it "includes each check" do
    get "/healthcheck"

    expect(data.fetch(:checks).keys).to include(
      :database_connectivity,
      :redis_connectivity,
      :sidekiq_queue_latency
    )
  end
end

Make healthcheck tests less brittle
Make healthcheck tests less brittle

I've encountered these tests [failing a][1] [few times][2] because the test environment
had a long sidekiq latency.

I've amended the tests so we can assert that the right tests are present, and
the right structure of data is returned.

The internals of the healthcheck is tested in the govuk_app_config gem's tests
so I'm not too worried about asserting the responses here.

[1]: https://ci.integration.publishing.service.gov.uk/job/publishing-api/job/deployed-to-production/842/console
[2]: https://ci.integration.publishing.service.gov.uk/job/publishing-api/job/deployed-to-production/836/console
