Why VIPER is a bad choice for your next application
Sergey Petrov
88522

Nice article. There are several macro design patters which make it possible to avoid dark sides of MVC pattern. VIPER is one of them.

The major feature of VIPER which differs it from others is a high rate of test coverage in the presentation layer of the app. But the price for that is a lot of boilerplate code. At the same time I’m agree with an David Heinmeier Hansson’s thoughts in his post “Test-induced design damage” that “…mocking all that away to test just whether it [Controller/Presenter] will send this redirect or that notice doesn’t make the least bit of sense to me. Controllers are meant to be integration tested, not unit tested.” Other parts of VIPER (services, interactors, vertical UI modules) have counterparts in other patterns (first of all they are MVVM and Component-based implemented in ComponentsKit).

The choice of VIPER is the choice of how much of your app you are going to unit test for the price of increasing cognitive load by introducing additionals levels of abstraction. As for me the VIPER cost is too high for small teams but may be a viable choice when the team is large or there are special consideration about bugs.

Like what you read? Give Pavel Osipov a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.