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.
1 Like
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.
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”.
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.
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.
2 Likes
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.
2 Likes
