The DMVC model explained

DMVC stands for Data Model View Controller, and is simply an extension of the MVC model. The introduction of the 'D' is to emphasize the separation between the model and the data. The intended use case for this model is in automated UI testing, as a replacement for the "Page Object Model".

The Data is a container of properties and values. It doesn't have any methods.

The Model is the class that knows how to manipulate the data. Too often our data classes are extended to encapsulate functionality that isn't actually part of the data, for example formatting or converting the data from one form to another. In this model, the formatting is done by the model object, and the data object is just data.

The 'rules' of the the model:
  • Interfaces may
    • declare either properties or methods
  • Interfaces may not
    • declare both properties and methods
  • Classes must
    • Implement a single interface that exposes all of their public methods and properties
    • Have 90% code coverage (actual test methods are excluded)
  • Classes must not
    • Contain a reference to another class that is not defined as a "basic" type. All coding is done against interfaces, not concrete types
  • Tests may
    • Reference controllers and data
  • Tests must not
    • Reference views
  • Controllers may
    • Reference views, data, and other controllers
  • Controllers must not
    • Reference tests
  • Views must not
    • Reference controllers, tests, data, or other views

Implications for coding

The upshot of the rules for the model is that everything needs to be an interface, unless it is a system type like a DateTime object or primitive. Obviously using some sort of unity/ dependency injection container is necessary in order to implement this model. This is the motivation for the DynamicTypeBuilder and the DynamicUnityContainer projects.

So in a UI testing framework, your test ends up being structured something like this:

Data - the data that the test is using. Ideally this is defined as an interface, and the implementation is created automatically from the interface definition.
Model - an object that contains the test data and provides a means of manipulating and formatting it.
View - a class that represents the a particular view in the UI being tested. Typically just has a list of properties representing the UI elements.
Controller - a class that knows how to use the data and views to accomplish a particular unit of work.
Test - usually a single method that uses various controllers to accomplish an overall workflow.


Last edited Feb 6 at 1:27 AM by nhuntera, version 9