Lazy testing huge Vue Container
Another attempt to help devs embrace writing tests.
Did you ever felt a huge discomfort every time you have to write a test (case) for a quite big (with complex logic) vue component? I have everytime I come across one specific container. Having huge containers is quite bad. And it doesn’t matter how we end up like this. To say it is quite challenging it’s like to say nothing. My case (excuse) was that it was not just ready to be refactored. I didn’t have the whole picture yet. Morevore, the situation was caused by decision to store all main features under one roof (url) e.g.: /featureA, /featureB, /featureC ended up living under same root url with 3 “mega” containers.
Containers — aka smart components — the one that knows where the data come from and/or have a decision to make, or contains “complicate logic”.
Everytime I looked at my spec file it scares me. To scaffold all the (store) modules it uses (different features use various combination of modules, so I had to provide them all) it’s one hell of the job.
Latest task for me was to show some errors (from store). It looks like an opportunity to face my fear of testing huge containers.
Imho, better to separate by behavior. I called it ErrorHandlerMixin (after half a year I renounced Mixin sufix in favor of Feature):
(that has a getter and an action to dismiss…
