Phoenix - test whether particular template was rendered / passed to render

Why testing such implementation? I always test only results, as it doesn’t matter how that result was achieved internally.

Because I want to test the logic, which renders different templates, according to internal rules/conditions. I don’t want to test the [current] content of template files. Templates’ content may evolve, be changed, renamed, reworded, adapted, … and I still want the logic tests to work rather than return bogus errors.

If the views can change, then what gonna happen if you change the source view and it will conditionally render different views? Show us a little more context and code (especially context) and maybe there is better solution. For example force to render parts with known content.

For an example imagine users with different access levels/roles. If the differences are subtle like “show this div instead of that one” then I have nothing against putting this kind of logic into the template. If OTOH those users are expected to have very different pages rendered for the same action then, especially with large templates with lots of elements, I would hate myself for shovelling everything into one template. In such cases I rather render() a template appropriate for given user, based on his access/role attributes. And for such cases I always test that my logic works, regardless of what the template contains. In the non-Phoenix world my main tool for this is:

https://relishapp.com/rspec/rspec-rails/docs/matchers/render-template-matcher

First two examples there. Another potential case: user with not activated account should get a different home-page than a holder of a fully active account. Sure I could e. g. redirect him to another action but it’s much more effective to simply render a different template. The rest the same as above.

Then you can abstract out the internal rules/conditions into a separate module and write unit test on it, right? If you don’t care about the template content why do you want to get the rendering involved in the unit test in the first place?

Because the result (regardless of the implementation) is that one or another template gets rendered. And with what I linked above this is very easy to test. And I don’t need to render the actual content. OTOH what the guides say is that the rendering should be involved (render_to_string() and match the output). For me it is enough to test what template was passed to be rendered, without caring what’s inside said template. Again - the examples in linked rspec doc show how to do exactly that.

So you don’t care about the rendering result, just there are some results? I think you can achieve this with 2 unit tests:

• the one I mentioned above, ie, the picking of the the template is according to a spec
• make a list of all legal templates, and render them one by one, This is to make sure that there is no missing template

I see. I was hoping for something similar to the rspec’s render matcher. Possibly as an additional dependency for test environment.

I see where you are coming from but I’d be very averse to approach the testing like you – that already sounds too much like browser automation testing to me, which is hard enough to do already.

One potential hack might be to have very specific data-* attributes of your elements in the different templates so you can just parse your rendered results with Floki or Meeseeks and assert that the appropriate data-* HTML attribute is present in the resulting markup.

I believe you misunderstood the intent. I also see close to no resemblance to automated browser testing. Another non-Elixir approach to this problem would be to mock the rendering entity and expect it to receive a message (get called) with appropriate parameters:

https://relishapp.com/rspec/rspec-mocks/docs

in “Message Expectations” paragraph. Maybe that’s something that can be done easier in Elixir/Phoenix?

So far the only somewhat viable approach seems to be the one suggested by @derek-zhou , but.. extracting the basically non-reusable logic into a separate module rather than testing it in its environment in-place seems more like a costly workaround than an elegant solution.

Right - it’s a hack And if I have to go the hacky way then there’s plenty of options. I could put even specific markup comments with “don’t remove” messages But this feels all wrong. The templates should IMHO not be concerned about the selection logic at all. The less should they be coupled to the way the selection logic is tested. Which is why I started this thread in the first place…