This morning a colleague of mine asked me for a list of questions to prepare for a .Net technical interview.

I thought it would be useful to share this list with everyone.

A) Developer

1) OO

• Explain principles of Object Orientation?
• Can you use abstract classes in place of Inheritance ? What are the differences between these two concepts?
• Explain polymorphism and write an example in code (C#).

2) Patterns

• What are Patterns?
• List some patterns you’ve already used.
• Explicit one pattern by writing a small example.
• Explain following patterns: Repository, Factory, Root Aggregate.

3) UML

• What are the most useful UML diagrams? (list & explain at least 5) .

4) Net & C#

• What is .Net? (Managed Code - CLR - Runtime) ?
• Explain concepts as JIT, CLR, GAC, GC?
• Explain series of processing steps an ASP.NET page goes through (= page lifecycle of ASP.NET) ?
• Explain following c# keywords: Static, ReadOnly, Const?
• What is: a Webservice,WCF, WPF, Silverlight and how do these technologies/concepts relate to each other?

5) DB

• Write simple query that joins 2 tables via a 1-to-N relation that contains a filter and a group by clause.
• Explain what is a Transaction.
• What are the properties of a transaction (-> ACID)
• Explain concepts as Primary Key & Clustered Index and how these concepts relates?
• Is a GUID a good Clustered index, explain why?

B) Architect

• List and explains the Enterprise Integration patterns, provide advantage/inconvenient for each of them? ->(Primary integration patterns: Database, WebServices, Messaging)
• What are non functional requirements, provide some examples (e.g. Accessibility, Availability, Security…)?
• Explain concept Authentication/Authorization how does these concept relates?
• What is Asynchronous Messaging - what type of infra do you need to set it up?
• Explain – what is an ESB?
• What is SOA & list and explain SOA Tenets?

C) Senior Developer / Team Lead

• What is IOC - What is the Goal - which frameworks do you know?
• Explain what are Unit tests and Integration tests, what differentiate these two types of tests?
• Provide a small list of programming practices that you would enforce/setup in your dev team?
• What is Waterfall/Prince2/RUP/Agile/XP/Scrum - how does these concepts relates ?
• What is DDD?

Some other useful/funny resources:

• C# design patterns:
  http://www.dofactory.com/Patterns/Patterns.aspx
• Techinterviews.com : http://www.techinterviews.com/interview-questions/net ***
• Megasolutions.net: http://www.megasolutions.net/
• Scott Hanslemann post on the same subject: http://www.hanselman.com/blog/CommentView.aspx?guid=d835178f-a649-45f5-907f-28ad1177d8d5
• Sample interviews: http://simasc.com/attachments/046_SampleInterviewQuestionBook(1).pdf
• The guerilla guide to interview: http://www.joelonsoftware.com/articles/fog0000000073.html 
• Some funny Interviews @ Microsoft (this was for an advertisement for Ms technical certifications):
• http://www.youtube.com/watch?v=0cvurGdIOjs 
• Video of interview process @Microsoft (real one this time): http://channel9.msdn.com/shows/WM_IN/Zoe-Goldring-and-Gretchen-Ledgard-What-is-it-like-to-interview-at-Microsoft/

The final source code can be downloaded here!

In this post we’ll bind a Command to our Menu so that it’s able to add views to the MainRegion.

Create a MenuViewModel:

Insert following code into the MenuViewModel:

   1:  public class MenuViewModel

   2:  {

   3:      private readonly IRegionManager _regionManager;

   4:      private readonly IUnityContainer _container;

   5:   

   6:      public MenuViewModel(IRegionManager regionManager, IUnityContainer container)

   7:      {

   8:          this._regionManager = regionManager;

   9:          this._container = container;

  10:      }

  11:  }

Here we created our first ViewModel that will be the target of our View binding.   Our View reference our ViewModel but the ViewModel does not need a reference to a view. The view binds to properties on a ViewModel, which, in turn, exposes data contained in model objects and other state specific to the view. The bindings between view and ViewModel are simple to construct because a ViewModel object is set as the DataContext of a view. If property values in the ViewModel change, those new values automatically propagate to the view via data binding. 

When implementing MVVM you need to bind the View and ViewModel, therefore you have the choice between several options.  You can declare the ViewModel as a resource in your view xaml, you can also use  a presenter class that is responsible to instantiate and bind the View to the ViewModel.  This strategy is useful when you need to bind different Views to the same ViewModel.  Because we don’t need this flexibility here we chooses for a simpler design; here it’s the view itself that instantiate and bind to his ViewModel.  Some could claim that I’m not implementing the pure MVVM pattern as in this application the View knows his ViewModel.  I nevertheless chooses for this approach because it’s the simplest way to implement MVVM and also because it enable me to handle UI events like KeyboardPress events gracefully  (see folowing post). 

In this design, the ViewModel, never the View, performs all modifications made to the model data. The ViewModel and model are unaware of the View but the View reference his ViewModel.  This design still provide loose coupling in the sence that the ViewModel does not know about the View but it makes some concessions to the purity of MVVM.  Nevertheless these concessions pays dividends in many ways, as you will see in the next series.

To setup this binding update the MenuView class:

   1:  public partial class MenuView : UserControl

   2:  {

   3:      public MenuView(IRegionManager regionManager,IUnityContainer container)

   4:      {

   5:          InitializeComponent();

   6:          this.DataContext = new MenuViewModel(regionManager, container);

   7:      }

   8:   

   9:      public MenuViewModel ViewModel

  10:      {

  11:          get

  12:          {

  13:              return this.DataContext as MenuViewModel;

  14:          }

  15:      }

  16:  }

When the user clicks a MenuItem in the MenuView, a command on the MenuViewModel should execute to display a view in the MainRegion (see line 36 - MenuViewModel).   Here we use the Prism DelegateCommand to implement the Command pattern. 

To retrieve the right View we choose for convention over configuration.  The  LoadViewCommand takes a parameter that is the the name of the View without the suffix View. 

The ViewModel has exactly the same name as the View but ends with ViewModel ->see MenuViewModel line 39.

To implement this convention we need to register the Views with a name parameter via the Unity container in the Module Initialization –> see Coremodule line 8 & 9.

Add the following code to the CoreModule.cs:

   1:  public void Initialize()

   2:  {

   3:      this.RegisterViewsWithRegions();

   4:  }

   5:   

   6:  protected virtual void RegisterViewsWithRegions()

   7:  {

   8:      this.regionManager.RegisterViewWithRegion(RegionNames.MenuRegion, typeof(MenuView));

   9:      this.regionManager.RegisterViewWithRegion(RegionNames.StatusbarRegion, typeof(StatusbarView));

  10:  }

Update the MenuViewModel:

   1:  public class MenuViewModel : INotifyPropertyChanged

   2:  {

   3:      private readonly IRegionManager _regionManager;

   4:      private readonly IUnityContainer _container;

   5:          

   6:      public MenuViewModel(IRegionManager regionManager,IUnityContainer container)

   7:      {

   8:          this._regionManager = regionManager;

   9:          this._container = container;

  10:          this.LoadViewCommand = new DelegateCommand<object>(this.LoadView, this.CanLoad);

  11:              

  12:      }

  13:   

  14:      #region PropertyChanged

  15:      public event PropertyChangedEventHandler PropertyChanged;

  16:          

  17:      private void OnPropertyChanged(string propertyName)

  18:      {

  19:          PropertyChangedEventHandler handler = this.PropertyChanged;

  20:          if (handler != null)

  21:          {

  22:              handler(this, new PropertyChangedEventArgs(propertyName));

  23:          }

  24:      }

  25:      #endregion

  26:   

  27:      #region LoadViewCommand

  28:      public DelegateCommand<object> LoadViewCommand { get; private set; }

  29:      public event EventHandler<DataEventArgs<string>> LoadedView;

  30:   

  31:      private bool CanLoad(object arg)

  32:      {

  33:          return true;

  34:      }

  35:          

  36:      private void LoadView(object obj)

  37:      {

  38:          IRegion mainRegion = this._regionManager.Regions[RegionNames.MainRegion];

  39:          string viewName = obj.ToString() + "View";

  40:          var view = this._container.Resolve<IView>(viewName);

  41:          mainRegion.Add(view,viewName);

  42:          mainRegion.Activate(view);

  43:          this.OnLoadView(new DataEventArgs<string>(obj.ToString()));

  44:      }

  45:   

  46:      private void OnLoadView(DataEventArgs<string> e)

  47:      {

  48:          EventHandler<DataEventArgs<string>> loadHandler = this.LoadedView;

  49:          if (loadHandler != null)

  50:          {

  51:              loadHandler(this, e);

  52:          }

  53:      }

  54:      #endregion

  55:  }

Bind the LoadViewCommand in our MenuItem.xaml:

   1:  <Menu Name="menu1">

   2:      <MenuItem Header="File">

   3:          <MenuItem Header="New"  CommandParameter="CreateFile" Command="{Binding Path=LoadViewCommand}"/>

   4:          <MenuItem Header="Folder"  CommandParameter="CreateFolder" Command="{Binding Path=LoadViewCommand}" />

   5:      </MenuItem>

   6:  </Menu>

You should be able to run the application and when you click the menu File, you should see :

This end the Walkthrough series.  In these 4 parts we setup the foundation of our client application implementing the MVVM pattern and learned how to use Prism to create a modular architecture.  

In the following posts I’ll provide a complete application build on the architecture described in part 0 -> (WPF/WCF/EntityFramework).   The application extends this basic design and provide an example on how to use the asynchronous behavior of web services to create responsive applications.

Source code of this part can be downloaded here.

In this part we’ll create our first views and display them inside their regions.  The views are the controls that display our content.  Because our application is build with modularity in mind it’s the Module and not the Shell that should define which views need to be added to the regions. 

1) We add a folder “Views” to our Module project and 4 views inside this new folder: 

• CreateFileView:  One of the views that can be displayed in the MainRegion
• CreatFolderView: Another view for the MainRegion
• MenuView: Control that will be responsible to Add views to the MainRegion
• StatusBar: Control that will be added to the StatusBarRegion

To add views to our regions we use the prism region manager service.  The region manager service is responsible for maintaining a collection of regions and creating new regions for controls.  Typically, we interact directly with region manager service to locate regions in a decoupled way through their name and add views to those regions. By default, the UnityBootstrapper base class registers an instance of this service in the application container. This means that we can obtain a reference to the region manager service in our application by using dependency injection.

We use constructor dependency injection to gather an instance of the RegionManager and store it in a local field and it’s  in the Initialize method of our CoreModule class that we implement logic to add the initial views to our Regions. 

2) Modify the CoreModule class like:

   1:  public class CoreModule : IModule

   2:  {

   3:      private readonly IRegionManager regionManager;

   4:   

   5:      public CoreModule(IRegionManager regionManager)

   6:      {

   7:          this.regionManager = regionManager;

   8:      }

   9:   

  10:      public void Initialize()

  11:      {

  12:          this.RegisterViewsWithRegions();

  13:      }

  14:   

  15:      protected virtual void RegisterViewsWithRegions()

  16:      {

  17:          this.regionManager.RegisterViewWithRegion(RegionNames.MenuRegion, typeof(MenuView));

  18:          this.regionManager.RegisterViewWithRegion(RegionNames.StatusbarRegion, typeof(StatusbarView));

  19:      }

  20:  }

To overcome magic constants in our code  we used a class containing all our region names.

3) Add this RegionNames class to your Infrastructure Library:

   1:  namespace PrismWalkthrough.Infrastructure

   2:  {

   3:      public class RegionNames

   4:      {

   5:          public const string MainRegion = "MainRegion";

   6:          public const string MenuRegion = "MenuRegion";

   7:          public const string StatusbarRegion = "StatusbarRegion";

   8:      }

   9:  }

Finally to see something displayed in our Menu and StatusBar we need to add some content inside these controls:

4) Modify the MenuView.xaml:

<StackPanel>
    <Menu Name="menu1" Background="Transparent" >
        <MenuItem Header="File" >
            <MenuItem Header="New"  CommandParameter="CreateFile" />
            <MenuItem Header="Folder" CommandParameter="CreateFolder"  />
        </MenuItem>
    </Menu>
</StackPanel>

5) Modify the StatusBarView.xaml:

<Grid>
    <TextBlock Text="This is the StatusBar" />
</Grid>

When pressing F5 you should see:

Define the Regions

Our shell will contain 3 regions:

• Menu Region: contain a Menu that is responsible to load views in the Main Region
• Main Region: region that will load the workspace controls – these are the views that will handle the application features. In our application only one view at a time can be loaded in the Main Region.
• Status Bar Region: provide info about current application state 

These regions are the placeholders for the controls defined in our Modules.  Our application will contain only one Module: the CoreModule but this application can easily be extended by adding new modules.   In our application the regions are defined as ItemsControls  in the Shell.xaml file and can be accessed in a decoupled way by their names; they support dynamically adding or removing views at run time.

1. To add the regions in the Shell window add the following namespace definition to the root Window element. You need this namespace to use an attached property for regions that is defined in the Composite Application Library:  xmlns:cal=http://www.codeplex.com/CompositeWPF.
2. Replace the Grid in the Shell by the following xaml:
   

   <Grid>
       <Grid.RowDefinitions>
           <RowDefinition Height="35" />
           <RowDefinition Height="*" />
           <RowDefinition Height="35" />
       </Grid.RowDefinitions>
       <ItemsControl Name="MenuRegion" cal:RegionManager.RegionName="MenuRegion" 
          VerticalAlignment="Top"  Grid.RowSpan="2"  Height="26" HorizontalAlignment="Left" 
           Background="Transparent" Margin="0,12,0,0"/>
       <Grid Margin="4,4,4,4" Grid.Row="1">
           <Border Background="GhostWhite" BorderBrush="LightGray" 
                BorderThickness="1" CornerRadius="5" Margin="0,0,0,0">
               <ItemsControl Name="MainRegion" 
                     cal:RegionManager.RegionName="MainRegion" Margin="4" Height="291" />
           </Border>
       </Grid>
       <Border  Grid.Row="2" >
           <ItemsControl Name="StatusbarRegion" 
                cal:RegionManager.RegionName="StatusbarRegion" Background="Transparent" />
       </Border>
   </Grid>

Now you should be able to run the application and see this screen:

Next --->

The client side application is made out of three assemblies:

• The Shell (PrismWalkthrough.Shell)
• The Modules ( PrismWalkthrough.Modules)
• The Infrastructure (PrismWalkthrough.Infrastructure)

The foundation of the application is “The Shell”.  The Shell is the top-level window of an application based on the Prism Composite Application Library. This window is a place to host different user interface (UI) components that exposes a way for itself to be dynamically populated by others, and it may also contain common UI elements, such as menus and toolbars. The Shell window sets the overall appearance of the application.

In our application it’s the shell that is responsible to load the Modules. A module represents a set of related concerns. It can include components such as views, business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.  In this walkthrough our application will contain only one module: the CoreModule nevertheless the modular architecture enable us to easily extend the application adding new modules later on.

The Infrastructure Assembly is a shared library referenced by both the shell project and the module projects, and holds shared types such as constants, event types, entity definitions and interfaces.

Create the Solution

1. Create the Shell project (PrismWalkthrough.Shell) application with Visual Studio-> File, Project, WPF Application.
2. Add the Modules project and Infrastructure project –> File, Add New Project, Classlibrary
3. The three projects should reference the Composite Application Library assemblies, add the following reference:
   (These assemblies can be found in the october 2009 Guidance of Prism -  you will need to compile the sample application)
   1.  
      • Microsoft.Practices.Composite.dll
      • Microsoft.Practices.Composite.Presentation.dll
      • Microsoft.Practices.Composite.UnityExtensions.dll
      • Microsoft.Practices.Unity.dll
      • Microsoft.Practices.ServiceLocation.dll
4. Add a reference to the Modules and Shell projects referencing the Infrastructure assembly.
5. Add a refrence to the Shell project referencing the Modules assembly.
6. Add a refrence to the Modules and infrastructure that reference to the WindowsBase & PresentationCore and PresentationFramework –> Reference, Add, .Net tab.

Your solution should look like this:

Initialize the application

To enable modularity and dependency injection in our application we need to make some changes to the standard WPF application we just created.  First we setup a bootstrapper.  The bootstrapper is responsible for the initialization of the application, this is realized by overriding the CreateShell method.

1. Add a new class on the root of the application containing the shell (PrismWalkthrough.Shell), name it Bootstrapper
2. The Bootstrapper should inherit from Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper class and override the CreateShell method. You need to instantiate the Shell through the Unity conatiner and call his Show method

   1:  public class Bootstrapper : UnityBootstrapper

   2:  {

   3:      protected override System.Windows.DependencyObject CreateShell()

   4:      {

   5:          Shell shell = this.Container.Resolve<Shell>();

   6:          shell.Show();

   7:          return shell;

   8:      }

   9:  }

To be able to run the bootstrapper at least one module should be registered in our application. 

1. Add a class to the PrismWalkthrough.Module and name it CoreModule.cs
2. This class should implement the IModule interface:

   1:  namespace PrismWalkthrough.Modules

   2:  {

   3:      public class CoreModule : IModule

   4:      {

   5:          public void Initialize()

   6:          {

   7:              

   8:          }

   9:      }

  10:  }

Through the bootstrapper you must configure which Modules are available in our Shell. You need to register at least one module in your bootstrapper.

1. Override the InitializeModules in the bootstrapper:

   1:  protected override void  InitializeModules()

   2:  {

   3:      IModule coreModule = this.Container.Resolve<CoreModule>();

   4:      coreModule.Initialize();

   5:  }

The WPF Application class needs to execute the bootstrapper by calling his Run method. 

1. First you should delete the StartupUri in the App.Xaml file.

   <Application x:Class="PrismWalkthrough.Shell.App"
                xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
   </Application>

2. Override the OnStartup method in the App.cs file:

   1:  protected override void OnStartup(StartupEventArgs e)

   2:  {

   3:      base.OnStartup(e);

   4:      Bootstrapper bootstrapper = new Bootstrapper();

   5:      bootstrapper.Run();

   6:  }

Now you should be able to run you application, you should see a white screen.

Next --->

In this series of posts I’ll build a reference WPF application(template) that can be used as a template for line of business applications (LOB). . This series will take the form of a walkthrough providing an introduction to the development of a Windows Presentation Foundation (WPF) application with Prism using the MVVM (Model View ViewModel) that includes the elements that are common to most WPF applications.

This walkthrough guides you through the development of a WPF/Prism desktop application using the following steps:

• Defining the application architecture. 
• Creating the Shell with his Regions Loading our Core Module.
• Use styles to create a consistent appearance.
• Use the Command pattern.
• Using Unity as IOC.
• Setting up the infrastructure for MVVM.
• Use WCF to setup our Service Layer.
• Use the Entity Framework as DAL.

Prerequisites

• Visual Studio 2010
• You need to download the Prism guidance

Part 0: Defining the application architecture

This application will be build using a Rich Internet Application Architecture (RIA). This architecture type uses a Web infrastructure that combined with a client-side application that handles the presentation. The Web infrastructure will be build using WCF and the client-side application will be build with WPF.

The client side application will use Prism for extensibility and to get the basic infrastructure for applying MVVM pattern.   This application will be composed of the following components:

• The shell: the main window that is responsible to load all other modules.
• The core module: contains the basic components to enable the basic functionalities of the application.

By dividing our client application in these two components we make our application ready to be extended; we will be able to add new features without touching to the code of the core module.

The WCF application is composed of several layers:

• The service layer containing the message types.
• The business layer contains business logic.
• The data layer contains data access components.

The data layer will use the Entity Framework 2.0 to interact with the DB.

To be continued --->

One of the major flaws in an un-testable design is the very tight coupling between the UI and the actual domain and/or presentation logic. Our typical ASP.NET applications are difficult to test, because much of the logic is contained within the codebehind files, which derive from Web.UI.Page, which needs an HttpContext, which is difficult to mock. Furthermore, the output of the methods in the codebehind is often not easily-testable, because it's a side-effect (such as calling DataBind() on a GridView).

This same problem exists in windows forms: How do you test the logic inside the form when you are unable to control the input & output of the UI? Let’s examine the following code sample.

   1:  public partial class LoginForm : Form

   2:  {

   3:      const string AUTHNETICATION_FAILED = "Authentication failed!";

   4:      public LoginForm()

   5:      {

   6:          InitializeComponent();

   7:      }

   8:   

   9:      private void LoginButton_Click(object sender, EventArgs e)

  10:      {

  11:          var membershipService = new MembershipService();

  12:          

  13:          if (membershipService.Authenticate(

  14:                                   UserNameText.Text,   

  15:                                   PasswordText.Text

  16:                                   )

  17:                )

  18:          {

  19:              MainForm form = new MainForm();

  20:              this.Hide();

  21:              form.Show();        

  22:          }

  23:          else

  24:          {

  25:              MessageLabel.Text = AUTHNETICATION_FAILED; 

  26:          }

  27:      }

  28:  }

Apart from being a pretty naïve implementation of a login form, this code is also hard to test. It’s design contains several smells of un-testable design. First of all it instantiates his Services directly, making it impossible to inject his dependencies through test doubles. Another problem is how can we test that; when the authentication was successful, the MainForm is shown?

By applying what we learned earlier we could already make our SUT more testable:

   1:  public partial class LoginForm : Form

   2:  {

   3:      const string AUTHENTICATION_FAILED = "Authentication failed!";

   4:      private IMembershipService _membershipService;

   5:      private INavigationService _navigationService;

   6:   

   7:      public LoginForm()

   8:      {

   9:          InitializeComponent();

  10:          _membershipService = new MembershipService();

  11:          _navigationService = new NavigationService(this);

  12:      }

  13:   

  14:      public LoginForm(

  15:          IMembershipService membershipService, 

  16:          INavigationService navigationService

  17:          )  //This constructor is only for testing purposes

  18:      {

  19:          _membershipService = membershipService;

  20:          _navigationService = navigationService;

  21:      }

  22:   

  23:      public void LoginButton_Click(object sender, EventArgs e)

  24:      {

  25:          if (_membershipService.Authenticate(

  26:              UserNameText.Text, 

  27:              PasswordText.Text)

  28:             )

  29:          {

  30:              _navigationService.NavigateTo(new MainForm());

  31:          }

  32:          else

  33:          {

  34:              MessageLabel.Text = AUTHENTICATION_FAILED; 

  35:          }

  36:      }

  37:  }

  38:   

  39:  public interface INavigationService

  40:  {

  41:      void NavigateTo(Form focusForm);

  42:  }

  43:   

  44:  public class NavigationService : INavigationService

  45:  {

  46:      private Form _form;

  47:      public NavigationService(Form form)

  48:      {

  49:          _form = form;

  50:      }

  51:   

  52:      public void NavigateTo(Form focusForm)

  53:      {

  54:          _form.Hide();

  55:          focusForm.Show();

  56:      }

  57:  }

Here we encapsulated the Navigation logic into a Service and we’ve created a specific constructor that can be used by our tests to inject a test double making possible to write the following test:

   1:  [Test]

   2:  public void LoginButton_Click_OnSuccessfullLogin_ShouldNavigateToMainForm()

   3:  {

   4:      //Arrange

   5:      var mocks = new MockRepository();

   6:      var membershipServiceMock = mocks.StrictMock<IMembershipService>();

   7:      var navigationServiceMock = mocks.StrictMock<INavigationService>();

   8:      var form = new LoginForm(membershipServiceMock,navigationServiceMock);

   9:   

  10:      Expect.Call(membershipServiceMock.Authenticate(null, null)).Return(true);

  11:      navigationServiceMock.NavigateTo(null);

  12:      LastCall.IgnoreArguments();

  13:      mocks.ReplayAll();

  14:   

  15:      //Act

  16:      form.LoginButton_Click(null,null);

  17:   

  18:      //Assert

  19:      mocks.VerifyAll();

  20:  }

By applying one of the variants of the MVC pattern namely the PresentationModel we can completely decouple the presentation logic from infrastructure and test it in isolation:

   1:  public interface ILoginFormView

   2:  {

   3:      string UserName { get; set; }

   4:      string Password { get; set; }

   5:      string Message { get; set; }

   6:   

   7:      void NavigateTo(Form focusForm);

   8:  }

   9:   

  10:  public interface IMembershipService

  11:  {

  12:      bool Authenticate(string userName, string password);

  13:  }

  14:   

  15:  public class LoginFormPresenter

  16:  {

  17:      const string AuthneticationFailedMessage = "Authentication failed!";

  18:      private readonly ILoginFormView _view;

  19:      private readonly IMembershipService _membershipService;

  20:   

  21:      public LoginFormPresenter(ILoginFormView view, IMembershipService membershipService)

  22:      {

  23:          _view = view;

  24:          _membershipService = membershipService;

  25:      }

  26:   

  27:      public void LoginButtonClick()

  28:      {

  29:   

  30:          if (_membershipService.Authenticate(

  31:                      _view.UserName,

  32:                      _view.Password

  33:                      )

  34:              )

  35:          {

  36:              _view.NavigateTo(new MainForm());

  37:          }

  38:          else

  39:          {

  40:              _view.Message = AuthneticationFailedMessage;

  41:          }

  42:      }

  43:   

  44:  }

  45:   

  46:  public partial class LoginForm : Form, ILoginFormView 

  47:  {

  48:      private LoginFormPresenter _presenter;

  49:   

  50:      public string UserName

  51:      {

  52:          get

  53:          {

  54:              return UserNameTextBox.Text;

  55:          }

  56:          set

  57:          {

  58:              UserNameTextBox.Text = value;

  59:          }

  60:      }

  61:   

  62:      public string Password

  63:      {

  64:          get

  65:          {

  66:              return PasswordTextBox.Text;

  67:          }

  68:          set

  69:          {

  70:              PasswordTextBox.Text = value;

  71:          }

  72:      }

  73:   

  74:      public string Message

  75:      {

  76:          get

  77:          {

  78:              return MessageLabel.Text;

  79:          }

  80:          set

  81:          {

  82:              MessageLabel.Text = value;

  83:          }

  84:      }

  85:   

  86:      public LoginForm()

  87:      {

  88:          InitializeComponent();

  89:          _presenter = new LoginFormPresenter(this, new MembershipService());

  90:      }

  91:   

  92:      public void LoginButton_Click(object sender, EventArgs e)

  93:      {

  94:         _presenter.LoginButtonClick();

  95:      }

  96:   

  97:      public void NavigateTo(Form focussedForm)

  98:      {

  99:          Hide();

 100:          focussedForm.Show();

 101:      }

 102:  }

We are now able to test the presentation logic:

   1:  [TestFixture]

   2:  public class LoginFormPresenterTest

   3:  {

   4:      const string UserName = "myUserName";

   5:      const string Password = "myPassword";

   6:   

   7:      [Test]

   8:      public void LoginButtonClick_AuthenticationSuccess_ViewShouldNavigateToMainForm()

   9:      {

  10:          //Arrange

  11:          var viewMock = CreateLoginFormViewStub();

  12:          var membershipServiceMock = CreateMembershipServiceMock(true);

  13:          var subject = new LoginFormPresenter(viewMock, membershipServiceMock);

  14:   

  15:          //Act

  16:          subject.LoginButtonClick();

  17:   

  18:          //Assert

  19:          viewMock.AssertWasCalled(

  20:              s => s.NavigateTo(null),

  21:              options => options.IgnoreArguments()

  22:              );

  23:      }

  24:   

  25:      [Test]

  26:      public void LoginButtonClick_AuthenticationFailed_ViewMessageIsAuthenticationfailed()

  27:      {

  28:          //Arrange

  29:          var viewMock = CreateLoginFormViewStub();

  30:          var membershipServiceMock = CreateMembershipServiceMock(false);

  31:          var subject = new LoginFormPresenter(

  32:                            viewMock,

  33:                            membershipServiceMock

  34:                            );

  35:   

  36:          //Act

  37:          subject.LoginButtonClick();

  38:   

  39:          //Assert

  40:          Assert.AreEqual("Authentication failed!", viewMock.Message);

  41:      }

  42:   

  43:      private IMembershipService CreateMembershipServiceMock(bool expectedResult)

  44:      {

  45:          var membershipServiceMock = MockRepository.GenerateStub<IMembershipService>();

  46:          membershipServiceMock.Stub(m => m.Authenticate(UserName, Password)).Return(expectedResult);

  47:          return membershipServiceMock;

  48:      }

  49:   

  50:      private ILoginFormView CreateLoginFormViewStub()

  51:      {

  52:          var viewMock = MockRepository.GenerateStub<ILoginFormView>();

  53:          viewMock.UserName = UserName;

  54:          viewMock.Password = Password;

  55:          return viewMock;

  56:      }

  57:  }

When designing UI’s you should make your choice between patterns like MVC/MVP/MVVM and use the most appropriate pattern and/or framework for your project.  With the appropriate design a lot of the presentation logic encapsulated into the UI can be extracted and tested. In this example we extracted all the presentation logic encapsulated in our form and transferred it into a presenter. This presenter is completely decoupled from any infrastructure and we are able to easily obtain 100% test coverage with it. The LoginForm itself remains un-testable but it does not contain any logic anymore. His only purpose is to act as a sort of proxy between the windows forms infrastructure and our presentation logic.

Let’s imagine we want to add caching capabilities for our InvoiceRepository class.

public class InvoiceRepository

{

    private IDataLayer _db;

    public InvoiceRepository(IDataLayer db)

    {

        _db = db;

    }

    public Invoice GetInvoice(int clientID)

    {

        Cache cache = Cache.GetInstance();

        string key = "Invoice" + clientID.ToString();

        if (cache[key]==null)

        {

            MeteringValues[] dailyValues = _db.GetMeteringValues(clientID);

            int offPeakPrice = _db.GetOffPeakPrice();

            int peakPrice = _db.GetPeakPrice();

            int advances = _db.GetAdvances(clientID);

            cache.Add(key, new Invoice(dailyValues, offPeakPrice, peakPrice, advances));

        }

        return (Invoice)cache[key];

    }

}

In this example we reach into the global state of our InvoiceRepository class and get a hold of the Cache singleton (Cache.GetInstance()). Global variables often show up as instances of the singleton pattern or just as static data in classes.

Not all singletons are bad design but all of them are suspect, presumed guilty until proven innocent! Nevertheless singletons which do not affect the functional behaviour of an application, can behave well as internal dependencies. A good example is the use of the singleton pattern for caching. Using the singleton pattern to implement caching is a valid strategy. The example here above illustrate this strategy nevertheless this example has a big flaw! The flaw is that we can’t intercept the call Cache.GetInstance. We can’t use a mocking framework to replace the Cache.GetInstance as this is a static method and static methods can’t be mocked (with Rhino Mock).

To solve this issue we need to extract the global state out of our Domain Object. We could for example pass a “Cache” object into the constructor:

public InvoiceRepository(IDataLayer db, ICache cache)

But imagine what would happen if we also want to log our exceptions and operations this would result in the following signature:

public InvoiceRepository(IDataLayer db, ICache cache, ILogger log)

When using the dependancy injection pattern (through constructor injection) every dependency to a service will result in a parameter we need to pass in our constructor.  That's why when we have a lot of dependencies (and usually we do)  using denpendancy injection result in classes that are difficult to instantiate because we need to inject all  cross cutting concerns (the cache, the logger, …) via the constructor. To solve this issue we can use the factory pattern. Nevertheless the Factory itself is still in his own way making our code more complex. This is why most of Unit test addicts advocates the use of IOC containers like Structuremap or Unity. 

Using an IOC container our code would look like this:

public class InvoiceRepository

{

    private IDataLayer _db;

    private ICache _cache;

    public InvoiceRepository()

    {

        _db = ObjectFactory.GetInstance<IDataLayer>();;

        _cache = ObjectFactory.GetInstance<ICache>();

    }

…

}

To test our SUT we can easily configure our container during the Arrange part of our unit test and don’t need to pass these dependencies through the constructor:

//Arrange

myIOCContainer.ForRequestedType<ICache>.TheDefaultIs<StubedCache>();

In the previous example the “Invoice” object is responsible to retrieve all the values needed to calculate the balance and it also contains the business logic that performs the calculation. This violates the SRP (Single Responsibility Principle). Because of this flaw when we test the calculation of the Balance we need to inject a test double so that the invoice can retrieve values. Why should we need to pass a Service when the only thing our Invoice should be responsible for is the calculation of the Balance?

In the code example here below we specialized the Invoice class. Only what is directly needed is passed in: the input data to calculate the balance. To adhere to the SRP we extract the logic that retrieves the data from our DataLayer out of the Invoice class and create a Repository class (see Repository pattern). We don’t need any mock object anymore what enhance the readability and robustness of our test. By adhering to the SRP we improve our design and enable for better testability.

SUT

public class Invoice

{

    private int _balance;

    public Invoice(MeteringValues[] dailyValues, int offPeakPrice, int peakPrice, int advances)

    {

        int peakConsumption = CalculatePeakConsumtion(dailyValues);

        int offPeakConsumtion = CalculateOffPeakConsumtion(dailyValues);

        _balance = CalculateBalance(

                            peakConsumption, 

                            peakPrice, 

                            offPeakConsumtion, 

                            offPeakPrice, 

                            advances

                            );

    }

...

}

public class InvoiceRepository

{

    private IDataLayer _db;

    public InvoiceRepository(IDataLayer db)

    {

        _db = db;

    }

    public Invoice GetInvoice(int clientID)

    {

        MeteringValues[] dailyValues = _db.GetMeteringValues(clientID);

        int offPeakPrice = _db.GetOffPeakPrice();

        int peakPrice = _db.GetPeakPrice();

        int advances = _db.GetAdvances(clientID);

        return new Invoice(dailyValues, offPeakPrice, peakPrice, advances);

    }

}

In the previous example we’ve extracted all the infrastructure code from the Invoice class and created a new class: the DataLayer. Nevertheless the Invoice class is now strongly coupled to the DataLayer class. To decouple these two classes we can make use of interfaces:

  2: {

  3:         private int _balance;

  4: 

  5:         public Invoice(int clientID, IDataLayer db){

  6:           … 

  7:         }

  8:         …

  9: }

 10: 

The interface IDataLayer is a sort of wrapper around the infrastructure code – this interface defines a contract for our infrastructure code, this type of interface is sometimes called a service interface. By creating this service interface we decouple the infrastructure from the domain logic as it does not depend on any concrete implementation anymore. The same strategy can be applied when working with hard to test third party code like the VSTO object model. By creating an interface that defines a façade around the third party component we make sure our SUT is testable and decouple our domain logic from the infrastructure code.

We can use unit tests and the test doubles for designing the service interface that your code depends on. To design this service interface we could take some inspiration from the TDD process. For each new feature we write a unit test that uses a test double to simulate the behavior that your target object needs from its environment; each test double is a hypothesis of what the real code will eventually do. This interface can then be used via Mocking frameworks to generate test doubles. As the cluster of a service interfaces and its test doubles stabilises, we can then begin to wire up your own Service classes with the underlying 3rd party API. The untested code would then be contained into these service classes and will not propagate into your domain code (Entities & Value objects). You would then obtain a clean and homogenous API that was dictated by what your own domain classes needs.