Documentation on upgrading to 0.5?

[fredwu]

Hi @antonmi ,

First of all, thank you so much for bringing espec and espec_phoenix to the ecosystem!

I have upgraded to v0.5 and as expected most of my test cases no longer work. Some are easier to transition to the "new approach", for instance I figured that instead of doing be_redirection, we should now use html_response/2, etc, however, not all the API changes are obvious, especially when the previous versions provided us with a lot of helper functions (for better or for worse).

What I am curious about is a smoother upgrade path for everyone. For example, if I have this before:

it do: should have_in_flash(success: "Signed up successfully.")

Do I now do this instead?

it do: assert get_flash(:success) == "Signed up successfully."

And if I had this before:

it do: should render_template("edit.html")

What is the equivalent new approach?

Thanks once again for the great library! :)

[antonmi]

Hi @fredwu ! I've added a few sentences to README. https://github.com/antonmi/espec_phoenix/blob/master/README.md#migration-from-previous-versions Please, look at the implementation of the helpers you need. For example, In case of render_template you just need to test if conn.private[:phoenix_template] == "edit.html".

it do: expect(conn.private[:phoenix_template]).to eq("edit.html")

Thank you for using espec! Hope, migration will be easy.

[fredwu]

Thanks @antonmi !

Given how useful those helpers are, any chance of having them packaged in an official espec_phoenix_helpers package? ;)

[joshrieken]

I like the idea of being explicit, but reaching into conn.private all the time or requiring multiple lines to set up a common assertion seems a little weird to me.

I think there's a case for better helpers, but I understand and agree with why they're not part of the core of this project.

Looking around at other options, I found plug_test_helpers, which has some interesting design choices that I'm not comfortable with.

Also, there's straight, Phoenix.ConnTest, which is nice, but seems like it should be a separate project of its own without having to bring in Phoenix as a dependency.

With that in mind, I'm considering creating a package with some common plug helpers that strongly favors being as explicit as possible while not requiring reaching into struct innards or depending on Phoenix.

I could then write another package containing espec matchers and add to the Extensions section, like i did with test_that_json_espec.

Is there anything out there like this already?

[antonmi]

Thanks, @facto ! I would be most obliged if you do this!