Phoenix JSON API acceptance testing

jamesmintram

What I was looking for was a way to run a bunch of tests against a staging environment using “real” HTTP requests.

How would someone go about organising code in a Phoenix project for something like that? I am assuming it wouldn’t go under the standard test folder, as these tests are ran very seldom (and require a “real” webserver to test against) but I would like to use ExUnit to manage them.

An ideal solution for me would be something like:

mix test.acceptance http://staging-url

Is there something already like that?

Any suggestions or comments would be greatly appreciated.

5 comments

/phoenix #deployment #testing

1 1424 5

2018-09-04 12:49:37 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

stefanchrobot

This totally sounds like something doable. Wouldn’t just using ExUnit with any HTTP client do the job for you?

On a side note, I would wonder what do you want to achieve, really. I would assume that you’re writing controller tests, so aren’t you duplicating the work? In a previous project we had controller tests and some “integration” tests written using Postman. The idea was that Postman could generate API docs out of the tests suites. The downside was that Postman’s project sync was a real pain and there was a lot of duplication between tests.

Post #1

jamesmintram

Thanks stefan.

Wouldn’t just using ExUnit with any HTTP client do the job for you?

That’s what I was thinking (and wondered if other people did the same) but I am not sure how best to integrate that into a phoenix project. My thoughts were to create a special mix command for running them.

On a side note, I would wonder what do you want to achieve, really.

I did think about this. The idea of these tests would be a sort of smoke test. They would test client journeys that contain a sequence of actions a client may carry out against the service, for example:

sign up
authenticate
create a resource
trigger a workflow
trigger another workflow

These steps would test high level functionality across many facets of the service in 1 test, only communicating via the REST interface. They test the happy path. I believe I first saw this idea in “Growing Object Orientated Software”.

Post #2

stefanchrobot

So it looks like you want to bundle a suite of smoke tests with your app so that when you deploy it you can run it on the server. Did it get that right? If that’s the case, then using HTTP client with ExUnit’s assertions wrapped in a mix task makes sense.

Otherwise I’m not sure why you’d like to integrate those tests with your Phoenix project. The tests can be a totally separate Elixir project. I’d also consider using a different technology for that.

Post #3

jamesmintram

So it looks like you want to bundle a suite of smoke tests with your app so that when you deploy it you can run it on the server. Did it get that right?

Yes. Although the tests don’t need to ship with the app. (They can be left out when doing a prod build)

Otherwise I’m not sure why you’d like to integrate those tests with your Phoenix project.

My reasoning is to keep the tests and project together. I’d rather manage 1 repository than 2. Also, the changeset history will all remain in 1 timeline.

I’d also consider using a different technology for that.

I have done that in the past, using Python + HTTPie. It was OK, but you end up needing two environments on your machine, and you are dealing with switching between two languages. I would much prefer everything in 1 language.

using HTTP client with ExUnit’s assertions wrapped in a mix task makes sense.

OK, that’s great. I will probably create a separate Elixir project next to the existing one. That way they share nothing and I can keep them versioned together.

Thanks.

Post #4

devonestes

I’ve used Wallaby for that in the past, since it spins up an actual server. That, plus tagging those tests as acceptance tests or something, can totally do what you’re looking for.

Post #5

— All posts loaded —