I would like to play with a specific Viper Module in my project. Technically now when I need to open a specific UIViewController I need to go through some screens enter some data and etc and then in a 20 seconds I am there in that specific screen.
So it takes a lot of time to navigate somewhere when I just need for example to test some small things (like UI adjustment, changing some strings how they fit screen and etc).
Instead I would like to run the specific screen when I run my project.
For sure mocking and injection will help a lot in this case as I need to insatiate my Viper Module with some initial data. This is just a technical detail here.
I would like to know how can organise my project to run specific modules instead of running entire project.
Hardcoded solution like using app delegate by adding extra code which overwriting initial point it's just a temp solution and you need to clean app delegate when you finish.
I may be wrong but I think there is should be a specific target solution which can run different modules whether it will initial point like HomeViewController or a specific module with mock injection.
To set the ground-rules of this answer, https://TheSwiftDev.com/the-ultimate-viper-architecture-tutorial describes the most-normative original-school-of-thought variant of what VIPER is and what it is intended to accomplish as self-discipline. (Other derivative viewpoints have arisen in the past several years, but I'll use this original school of thought in this answer for all-the-wood-behind-1-arrow clarity & pedagogical reasons.)
I am going to politely reject OP's usage of “module” with respect to VIPER. Instead, VIPER is 5 zones {view for UI, interactor for datastore/networking/sensors, presenter for app-domain ‘business’ rules, entities for app-domain-centric [not datastore-centric, not network-centric, not sensor-centric] data structures, router for navigation} of quarantine & some degree of divorce. Someone might just say that zone & module are 100% synonyms/congruent, but I am going to tease them apart as separate interpretations. The 5 V I P E R zones are all about the divorce/quarantine from each other to stamp out Massive View Controller antipattern/code-smell software-architecture https://khanlou.com/2015/12/massive-view-controller and https://www.hackingwithswift.com/articles/159/how-to-refactor-massive-view-controllers, which is a mobile-app variant of the older-era Big Ball of Mud antipattern/code-smell software-architecture http://www.laputan.org/mud/mud.html#BigBallOfMud
Modules on the other hand can be interpreted as finer-grained than the 5 V I P E R zones. Let's do that here. Each zone of VIPER can be further subdivided into modules of like-topic portions of that zone, such as all the (sub)views comprising a scene/screen/containing-view or any other subcategorization of the app that one's heart desires. Module demarcation can be orthogonal (or oblivious) to the 5 V I P E R zones. Indeed, a designer might choose to have the same module demarcation within each of 2 or more V I P E R zones. Or just as validly, a designer might choose to have a quite-different module demarcation within view zone than within interactor zone than within presenter zone, because they each by happenstance focus on a different way of decomposing that isolated/divorced/quarantined zone in a way that is sensible only within that zone (and would make little sense over in some other 4 zones). Hence, from this answer's vantage, we won't mention modules anymore because it is a local taste within each zone, unrelated to the OP's intended goal.
Each zone in properly-accomplished VIPER architecture has been quarantined so that UI-specific topics never escaped outside of view zone (e.g., into most-temptingly presenter zone or router zone or [usually a lesser temptation unless heavily mimicking nonVIPER examples for sensor or networking data acquisition] interactor zone). Because of this quarantine, the OP's goal is effectively to have a quite-different router/navigation zone that drives the app in testing mode through its various scenes/screens/modal-dialogs in a way that might even be unnatural for the human-being-user variant of the app & its router navigation. But the entire purpose long-term for VIPER software architecture is to swap out a whole zone because it has such impeccable quarantine/divorce—literally like swapping out one spouse for another via marriage divorce. That is what OP is effectively seeking: the wholesale swapping out (primarily) the human-being-user variant of the router zone with a test-mock router zone that drives the app via script-like marching orders to march the UI in ways that take annoyingly too much effort to accomplish via human-being-user UI actions. The mocked/scripted substitute router zone is free to ‘short-circuit’ as it pleases to skip portions of the UI as long as any accumulated state that would have been naturally built up is backfilled as part of the mocking scriptedness. If router would not have had access to whichever methods/API are necessary to accomplish that backfilling of accumulated state when short-circuited navigating to a portion/screen/scene of the UI, then either a) that separation of concerns is eroded so that the mocked/scripted substitute router zone is less quarantined than its regular human-user variant or b) some other zone needs some degree of mocking to backfill that canned accumulated state to cooperate with the mocked/scripted substitute router zone.
But to accomplish this swap-out of the usual router zone with a mechanistic/test/mocked router zone for script-like navigation of the UI, the interactor zone especially must be mocked out too to drive canned datastore content, canned network content, and canned sensor content/acquisition in a script-like manner as well in ways that cooperate with the testing/mocked router variant. Indeed, the quarantine/divorce so sought after in the usual app-domain human-being-user variant of the app is the prize, but far less quarantine perhaps no divorce at all might be the laudable goal between the mocked/testing router zone and the mocked/testing interactor zone, which might conspire together quite intimately to accomplish their scripted/canned mocking functionality together as one mindset. So what is good divorce/quarantine separation of concerns for the human-being-user primary variant of the app would likely be disastrous separation in the OP's mocking/testing variant of the app, because in effect there is no such separation of concerns between the scripted/mocked router zone substituted in and the scripted/mocked interactor zone substituted in.
One would hope that the presenter's business-rules quasi-backend-esque processing doesn't need to be mocked out, as hopefully the enforcement of those app-domain business rules are not going to get in the way of mechanistic driving of the UI 1) with mocked/scripted navigation via the substituted router zone and 2) with mocked/scripted data from mocked/scripted sensors, mocked/scripted datastore, and/or mocked/scripted networking. If some app-domain needs to separate out pure UI testing in view zone from pure business-rules/quasi-backend testing in presenter zone, then a mocked-UI view zone would test/drive the real presenter zone and a mocked-business-rule presenter zone (with perhaps alternate-reality/fuzzed business rules) would test/enforce-more-strictly the real view zone.
Conversely, if the developers of an app failed to 100% quarantine, say, UI topics within view zone, then the ability to swap out the UI-contaminated nonview zones is eroded perhaps fatally to the point that nonview zone cannot be swapped out with a testing/mock substitute of that nonview zone. To accomplish this 100% strict quarantine interzone among the V I P E R zones requires overt self-discipline of assuring that 100% of the interzone messaging/method-invocation is expressed in purely app-domain concepts without contamination from Apple-think or its constructs, Android-think or its concepts, and so forth. Each V I P R zone (other than rather simple entities in E) usually needs a façade layer at the perimeter of each zone to interwork intrazone concepts with app-domain interzone concepts, such as quarantining all of Apple-think UI constructs or Android-think UI concepts within view zone so that only higher-order-thought app-domain concepts are exchanged interzone—likewise with a façade at the perimeter of interactor zone for interworking the quarantine of datastore-centric or sensor-centric or networking-centric constructs intrazone away from higher-order-thought app-domain concepts interzone.
Likewise, instead of fully automatic scripted navigation, another testing/mock substitute of the router navigation zone could fast-forward the human-being user to a particular portion/screen/scene of the UI for manual interaction for semiautomated testing. The fast forwarding could be to a relatively unfilled-out screen/scene. Or the fast forwarding could be to, say, an editing-something screen with canned elaborate entity to edit already loaded, which is especially useful if the canned elaborate entity is especially pernicious in exercising some use-case or just the right combination of situations for reproduction of a bug.