I have read in VIPER blogs that moving view controller's code to Presenter codes makes it easy to unit test. The reason given in the blogs was that the Presenter doesn't have any UIKit related code in it.
How does this make it easier to unit test. Can any one please explain this in detail? Or is there any other advantage of this apart from avoiding Massive View Controller problem?
The biggest problem in unit testing is how to mock something. You want to test a method but that method is calling 3 other methods and you don't want to test these 3 methods, therefore you want to mock them to return some fixed value.
This is pretty easy in languages like Javascript, where you can substitute a method on any object or in Objective-C where you can do the same (although with a bit more difficulty).
This is not easy in a language like Swift. Therefore Viper came with the idea to split view controller into units (e.g. Presenter, Interactor, View, Router) and every unit has its own protocol. Now to mock one the units you can just implement the protocol and use it instead of the real Presenter or View.
(you can actually use some tools to generate the mocks for you dynamically in tests)
That makes unit testing much much easier.
However note that unit testing UI is never easy. UI usually operates in terms that are difficult to unit test and unit testing UI almost always means that you will be duplicating a lot of your app code in unit tests. UI is more commonly tested via integration tests (e.g. automatic clicking and validating what is visible on the screen).
Viper is not a bad architecture. Separation of concerns is something that many programmers struggle with and it's not a bad idea to have strict architectural rules. With complex screens you still won't be able to avoid big controllers but at least you will be forced to move some code out of the controller.
Massive View Controllers are not a problem of the MVC pattern. They are a problem of bad separation of concerns and strict rules in Viper help to avoid that.