So hanami views is pretty new, but it is based on dry-views and that is less new and I am wondering if people who have more experience with it, have any special approaches to testing views and their rendered templates using them?
I mostly work with github components, and spent a lot of time using trailblazer cells too. Both of those tools I liked (VC far more than Trailblazer cells though) and they are easy to write specs for. I have a rather easy time building rspec matchers and custom helpers suited for a particular project and in general I favor testing every component as a unit test, even very small. However I do realize a lot of people do not like to test views and skip component specs entirely, in favor of feature specs (or in favor of nothing).
Right now documentation is missing an entry about testing the views. Configuration is not complete yet but has a link, but there is no empty page for Testing section in the views.
This brings two questions:
- Is testing views a planned section to be described in the documentation? Is there a preferred approach to building tests for views?
- What are the approaches to testing hanami-views? I know it is still new, but I do not work with hanami in day job, so I am wondering what are the approaches in production applications using it.
Great questions, thanks @krzykamil!
Yes, we plan to add a view testing page largely following the one we already have for dry-view. Those same testing techniques should work equally well for Hanami views.
The part testing behaviour has evolved slightly, and itself is tested here in this file.
If you’d like to introduce a PR to our guides to add a views testing section, I’d be very happy to work with you on getting it merged!
As for the approaches to testing views, we do allow every aspect of views to be independently testable (such as the views themselves as well as each part), but my personal approach is to only lean into that unit-level testing when there is detailed view logic that would be too slow or cumbersome to test via end-to-end “feature”-style specs that drive a real browser.
Let me know if this helps!
Thanks for answering Tim, I’ll gladly prepare a PR based on dry-view page and the blob you’ve send, after spending some time testing views on my own. I’ll link a PR here in a couple of days hopefully, for your input and review.
As for the approaches - good to know your approach, it is very sound and probably most commonly seen by me (at least among good developers 
).
I prefer to always generate a spec file for view component and do even a simple render check. I treat them as sort of sanity checks, to not break anything along the way, regression defense etc. But I do setup rails generators for that so it usually adds none or almost no writing. But it might be an overkill, unnecessary approach with Hanami views, where the units are even more minimalistic than view components (at least that’s how they seem to me right now, due to breaking down to parts)
I’ll include using unit-tests for crucial parts and preferring “feature” specs for general views testing as a part of the guides page.
2 Likes
Add page about testing hanami-views by krzykamil · Pull Request #239 · hanami/guides · GitHub @timriley I described testing entire views, exposures and parts, basing the last one on the internal integration tests you linked. Please let me know if you want something changes/added etc.
Thanks @krzykamil! I’ll check this either tomorrow or the weekend.
2 Likes
Just wrapping up this topic: this PR is now merged and now we have a testing guide for views!
Thanks @krzykamil!