Jonathan Parker

To install a dll in the GAC on the post-build event use this:

 "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /f /i $(TargetPath)

 This requires the Windows SDK obviously. 

On a recent project I was working on and we had a requirement for reports to be displayed online.  We had a discussion about the format of the report and we agreed with the customer that we would need to provide sorting on the columns.  This was fine but when it came to implementing this we did not think it through properly.  So what we ended up with was sorting on all columns alphabetically when what was required was sorting by date and by amount on some of the columns.

This was reviewed by the customer but never picked up a them.  What I haven't mentioned is that we never had any UAT testers other than the customer contact who was developing the specification for us. So although we got feedback early we didn't get all the feedback we needed.  However I'm sure that if users had started using the application they would have picked up on this error.

So it seems that feedback is best when it comes from production usage of the software as this is when testers (or users) care most about what works and what doesn't.

Hopefully in future projects we will have a more iterative development cycle and get earlier feedback from production or UAT users.

Thoughts on Martin Fowler's article on Passive View

(http://martinfowler.com/eaaDev/PassiveScreen.html)

The problem with MVP and MVC

The MVP and MVC design patterns are great but they are avoiding the real issue which is UI abstraction. UI code should be abstracted into libraries which are tested once and once only. I know that using the fundamental units of UI that are available today (e.g. HTML) give great flexibility in the design of the UI, however this should be present in abstracted libraries also.

So why is testing UI so difficult? There are two main reasons:

• The UI is expensive to create. This is because it is rendering (and in the case of HTML being transmitted over a network as well) and creating complex and detailed visual elements. However these visual element don't have to be created in order to be tested.

• Even if the UI is cheap and quick to create still is difficult to interact with in an automated way. This means that often manual testing is necessary. Note that this too is due to an actual property of the UI. It is through the choice of the UI designer that this is the case.

The primary function of the abstracted libraries I am advocating would be to enable fast automated UI testing.

For example, libraries would contain discrete UI components that have two functions. The first function is to display a UI to the user. The second function (which is not present in any of the currently available libraries) is to mock the UI via a purely code level interface. This means that each component in the library is able to guarantee (via one-time extensive testing) that all operations performed via the mock interface correctly mimic the corresponding operations performed by the UI interface.

A concrete example of this is a simple text box. Here is a prototype of this new type of library component:

public class Textbox : UIComponent, Mock

{

private string isMock;

public string CurrentText;

public string TextBeforeLastFocus;

public TextBox(isMock)

{

// Set flag to determine behaviour.

this.isMock = isMock;

}

public void KeyPress(KeyCode key)

{

// Implement mock

}

}

In the above example the constructor takes a boolean which specifies if the object will be used as a mock or as an actual UI component. This means that you can simply toggle this flag when moving from testing to production.

It also means that you can call methods (such as KeyPress) on the object when it is in “mock mode” so that the object mocks its own behaviour exactly as it would if being controlled by a user via its UI.

In general I believe that frameworks should support testing from the beginning. This means integrating testing interfaces into all parts of a library or framework. To be clear I am specifically talking about testing interfaces for client use of these libraries. Undoubtedly they should also have a means of testing the internal functions of their libraries.

Take the .NET Framework for example. This is rigorously tested by Microsoft internally to ensure that the function of each class and interface is correct. However there is no interface for consumers of this framework to use. I'm suggesting that the .NET framework would benefit from integrated testing frameworks such that (as shown above) a consumer of a class can mock the class. This is more needed in the areas of UI and database access but would be useful for all parts of the framework.

The real question about the Passive View pattern is "I know it decreases decoupling but does it increase cohesion?"

I've signed up fro the SQL Server Data Services (MSSDS) and have started to play around with the API.

It's quite nice and simple. Here's an example of how to get your data in the cloud with MSSDS.

1. Add a Web Reference to any .NET 2.0+ project. I'll be calling it SitkaClient (Sitka is the code name for MSSDS).
   
   
   1. WSDL url is http://data.beta.mssds.com/soap/v1?wsdl but you'll need to sign up to get a username and password.
      
      
2. Optionally change your Web.config/App.config to support SSL by doing the following
   
    
   
    
   
3. Call the web service.

It's that easy.

Here's a few examples of what you can do.

1. Define a few constants
   
   
   
2. Create an Authority
   
   
   
3. Create a Container
   
    
   
4. Create an Entity
   
   

These example use a few extension methods I created for the SitkaSoapServiceClient class.

Here's the code from the Extension class which is specific to a console application because it writes to the console output:

DOWNLOAD (ZIP): SQLServerDataServices.zip