The MVPVM pattern lends itself to effective integration/unit testing. Since their is no code in the code-behind and the Presenter processes all business logic against the ViewModel and View it is the best component to perform integration test against.
In the following application (download from this link DirectoryLookupModularity.zip (5.82 mb)) there are three view models:
- CriteriaViewModel - utilized by views E, B and C
- DoctorViewModel - utilized by view A
- PatientViewModel - utilized by view D
The MVPVM framework used for the attached application consistently uses the following for bootstrapping modules:
The ModuleBase<TPresenter> (see below image) instantiates the specified Presenter, e.g., on line 14 below we identify the "DoctorPresenter" as the presenter.
The PresenterBase<TView, TViewModel> (see below image) specifies the View and it's ViewModel which in this case is DefaultViewA and DoctorViewModel respectively. On line 23 we register the view (DefaultViewA) with the TopLeft region which was declared in the Shell's XAML. The remaining logic is the code required to wire-up a CRUD control and to get the current module load counter value so that we can see that the module dependency attributes are working correctly.
These baseclasses do all of the wiring up so that we can focus on business rules; we don't spend a lot of time getting our module up and ready for the requirements at hand.
The integration test for Module A's presenter is shown below (lines 46-52); it verifies that the infrastructure properly wired up the View and ViewModel.
Did you notice that on line 24 above we set the container to null and on the following line use the container.RegisterServices() method? On the surface this may look odd but it lends itself to testing the Prism environment.
We use the same RegisterServices in our bootstrapper as we do in our integration/unit test - we do this to ensure our environments match for testing purposes. To accomplish this we use a IUnityContainer Extension class (IUnityContainerExtension), the only time container will be null is during testing so we instantiate a MockBootstrapper (lines 25-27 below). From that point on we have the same registrations to ensure our test will run without complaint.
Tags:
prism,
unit test,
mvpvm,
prototype
Categories:
MVPVM |
Prototype