Bypassing backend validation in :test env to make integration tests pass - how to avoid this hack?

Questions / Help
, ,
1

I am writing a graphql API for a restaurant. It allows clients to place orders. There are lots of integration tests that post graphql queries the API.

Tonight, I added the concept of “opening hours” and a test that posts a graphql “mutation” (a HTTP POST) is now failing, because the backend is checking DateTime.utc_now against the “opening hours” for the actual test time and deciding (correctly) that the business is closed.

Everything I read (tonight) about this sort of problem, talks about the functional way - directly injecting my own module to get utc_now. However, this is impossible for a request-response test of the API (you cannot send DateTime.utc_now over the network).

So, I went with this approach:

  1. I tested the is_business_open logic on its own, in a functional way.
  2. I got the API integration tests to pass by actually putting this in my code:
def validate_request_time(changeset) do
  if Mix.env == :test do
    changeset
  else
    if is_business_open() do
      changeset
    else
      put_error(changeset, :closed, "go to bed stupid")
    end
  end
end

Is this a bad idea? Please give me your unfiltered opinions/thoughts about this. Maybe somebody here has had a similar problem with real time in integration tests.

2

This is a bad idea because if you do a release, the Mix module won’t be available.

You should do a dependency injection on DateTime with Mox if you can. If you can’t, if you can hoist the boolean check, that’s better. So make a compile-time attribute @assume_open Mix.env == :test

And make your if statement if @assume_open || business_open?() do...

As a side note, idiomatically is_ functions should be guards, and making your function business_open? is more idiomatic.

1 Like
3

Like others are posting: Mix.env won’t be available at runtime in production if you’re using the standard release mechanism.

You could get a similar result by setting an application config to turn off time checking.

OR

You could approach the problem from the other direction: the test is failing because you’re not being sufficiently specific about what it needs from its setup. It doesn’t need “a business”, it needs “a business open now”. Fix that and the test will pass without any special-casing.

2 Likes
4

Both answers so far merit being marked as “Solution”. I don’t know which to select.

EDIT: I selected the solution as being the one telling me to give my test what it wants. However the info about the “compile-time attribute” is very helpful too. I just think the “re-examine your test setup” is the more correct path.

CONCLUSION: It was so much clearer in the morning light. I changed my “opening hours seeds” to accept “default hours” arg with default value and just changed this to be now - 200 seconds and now + 200 seconds in the shared test setup for these api tests.

Thanks again for the info about Mix.env not being available at runtime in releases. I heard this before but had forgotten about it.

2 Likes