Structure

The solution itself contains of two main parts: App and Tests. This is quite common to have tests in the application but in this case these are first and foremost specifications which guide the App's functionality. It is important to realize that not every test can and should be expressed as a specification yet the most prominent scenarios should be clear to the business stakeholders.

The App part usually contains of Client and Server but in this particular sample the Server part is omitted to put focus to the demonstrated feature which is specifications and BDD.

The Client part consists of three layers: Model which is the app's domain as seen by the Client, Presentation which is the model's presentation according to the visual requirements and Data which is the interface to the external source of data - usually supplied by "Server from some kind of Storage.

The Model layer consists of two parts: Contracts which provide definitions of the Client Domain Models - This project should contain only interfaces or enumeration types (preferably value objects) and **Model" itself which contains a private implementation of the contracts. The consumers should not be exposed to the implementation details and work only with the contracts. This greatly improves the decoupling of the App.

The Presentation layer in this case consists only of the Shell which contains both Views and View Models. There is no code-behind and all presentation-related logic is put in the View Models and Views communicate either via bindings or mediators - behaviors, trigger actions, dependency properties etc. This allows integration testing of the Presentation features on the View Models if required to.

The Data layer consists of three parts:

Contracts which defines the lingua franca for data and access to it from the *Client" point of view. This part contains of two components: DTO which contains the definitions for the data objects used for communication with Server and Providers which contains the interfaces for requesting these objects or issuing related commands to the Server. It is important to understand that the definitions for DTO are directed by the Server and Client should have very little influence, if any, over the objects schema. The DTO themselves are simple POCOs deprived of any business logic, neither from Client nor from Server. The only concern that may be added to the schema is the decoration with serialization protocol attributes: [Serializable] for built-in .NET, or [Proto] for Protobuf.

Fake which contains fake implementation of the Providers including the initialization. This approach is useful for the cases where the Client is to be filled with some test data independently from the Server for QA or fast feedback. This part consists of 3 components: Containers which represent containers of the initial fake data, ProviderBuilders which contain builders for the providers with fluent API and various setup capabilities, and **Providers" which contain implementation of Providers contracts using the ProviderBuilders. The ProviderBuildrers prove to be extremely useful not only for the Fake Providers but also in Tests.

Real which contains real implementation of the Providers contracts. It is omitted from the sample but usually this implementation should contain a reference to the service, identified by its address and API. WebAPI is one of the options.