My post today comes after watching the code coverage hover just over 70%, constantly asking myself is it possible to get

100% coverage and a discuss with a few internal colleagues on the subject. Interesting to know is if I exclude the views from code coverage,  I hit a high of just over 90%.  So, is not testing your UI the end of the world? Not at all, as long as you use good development practices and aim to make your UI as slim as possible, without any business processing, branching or conditional type logic.

I’ve been very pleased with using the PureMVC framework on my current project, and haven’t running into any Ah! Ha! I gotcha scenarios yet and frankly can’t envision any as we continue to add new features to this application.  In fact using PureMVC has helped me think more about testability of our code and its single messaging bus has been just what the doctor ordered in terms of eliminating Publishing/Subscribing to events between the various components of the system, namely Mediators, Proxies and Commands.  But with great power comes great responsibility.

One could easily access the Singleton Facade of the PureMVC framework directly from your view and send a system wide message to any component interested in that message. The problem here is testability of the UI event required to trigger that system notification.

For instance in the code snippet below you would have to create an instance of the UpgradeView and simulate a click of the download button in order to test sending this notification.

public parital class UpgradView :Form, IUpgradeView
{
…

private void DownloadButton_Click(object sender, EventArgs e)
{
Facade.SendNotificaiton(“DownloadUpgrade”);
}
}

A better approach here is to allow your view to publish events that its mediator can subscribe to. This way you could add more logic before/after sending the notification and makes your code more testable.

public parital class UpgradView :Form, IUpgradeView
{
…

public event EventHandler OnDownLoad;

private void DownloadButton_Click(object sender, EventArgs e)
{
if(OnDownload != null)
OnDownload(this, e);
}
}

public class UpgradMediator : Mediator
{

public UpgradeMediator(IUpgradeView view)
{
view.OnDownload += Download;
}

private void Download(object sender, EventArgs e)
{
// Add more logic here,
Facade.SendNotificaiton(“DownloadUpgrade”);
}
}

[TestFixture]
public class UpgradMediatorTest()
{
…

public void HandleNotification(INotification notification)
{
switch (notification.Name)
{
case Notification.DownloadNewVersion:
Assert.IsNull(notification.Body);
break;
default:
Assert.Fail();
break;
}
}

[Test]
public void DownloadUpgradeTest()
{
upgradeView.BackToRecord();
upgradeView.Expect(x => x.CloseView()).Repeat.Once();
upgradeView.OnDownloadUpgrade += null;

IEventRaiser eventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
upgradeView.Replay();

UpgradeMediator mediator = new UpgradeMediator(upgradeView);
eventRaiser.Raise(this, EventArgs.Empty);

upgradeView.VerifyAllExpectations();
}

}

So its it possible to get 100% coverage or is 100% just some pie in the sky that we aim for. Frankly, 90%+ code coverage aint bad, especially when my views are lean mean fighting machines.  Ok one last thing I’m sure your wondering  is why not 100%  coverage now that the views are excluded. Well, smarty pants, I can’t test external third party APIs code that we include, nor do I want to.

Related Services: .Net Application Development,
Custom Software Development

Share/Bookmark

PureMVC is open source framework that allows creation of application using Model, View and Controller pattern, and was original designed for Flex, Air and Flash application. It has since been port to various languages include the .NET C# language. So when I first heard about it, several months ago, I was working on a pretty large WinForm application design around the MVP – Model, View and Presenter pattern.

Our presenters were responsible for handling the user interaction coming from the views by subscribing to events published by the views, and coordinating these actions with changes needs from the models such that these changes are then reflected back in the views themselves.

Although this approached work, it requires a lot of wiring and unwiring of events from the various presenters to views, presenters to model, and presenters to presenters. So the code quickly begins to look like the following:

public class presenter1

{

public event EventHandler<EventArgs> SomethingHappened;

public presenter1()

{

_model = new Model();

_model.StateChanged += OnModelChange;

_model.DocumentSaved += OnModelSaved;

_view = new View();

_view.OnMouseDown += OnMouseDown;

_view.OnMouseUp += OnMouseUp;

_view.OnMouseMove += OnMouseMove;

_view.OnMouseEnter += OnMouseEnter;

}

…

…

As you can see, for every user interaction on the view or model change a particular presenter is interested in, you must subscribe to an event, and if other presenters are interested in particular actions from views they are not responsible for, well, I’m sure you can get the picture. So act II, introduction of PureMVC framework for WinForms.

So exploring the capabilities of PureMVC framework, uncovered a simplification of our code. At its core, it consists of four singleton objects Model, View, Controller and Façade. The Model, View and Controller contain literal string references to Proxies which are data model, Mediators which provide and manage the user interface, and Commands which interact with the Proxies and Mediators or other commands.

But the simplification revolves around the Façade which is responsible to provide messaging throughout the core framework using an Observer notification scheme. So now our code quickly begins to look like the following:

public class presenter1 : Mediator

{

public presenter1()

{

}

public override void ListNotificationOfInterest()

{

return new List<string> { Nofication.ViewMouseClick, Notification.ModelChange,};

}

public override void HandleNofication(INofication notification)

{

switch(nofication.Name)

{

case Notification.ViewMouseClick:

Dosomething();

break;

}

}

…

…

public class presenter2 : Mediator

{

public presenter2()

{

}

public override void ListNotificationOfInterest()

{

return new List<string> { Nofication.ViewMouseClick,};

}

public override void HandleNofication(INofication notification)

{

switch(nofication.Name)

{

case Notification.ViewMouseClick:

DoSomethingFun();

break;

}

}

…

…

public partial class view1 : Page

{

…

…

protected void view_mouseclicked(object sender, MouseEventArgs e)

{

Façade.NotifyObserver(new PureMVC.Pattern.Notification(Notification.Name));

}

…

…

Both presenter1 and presenter2 state they are interested in Notication.MouseClick event, and view1 uses the Façade to notify both presenters that the user has clicked the mouse button. No need to publish and subscribe to any events outside what’s naturally needed in the view.

The only thing I dislike is the name references, but as long as we are using constants you should be fine.

Related Services: .Net Application Development, Custom Software Development

Share/Bookmark

For the past several months, I was working on a Windows desktop application that didn’t require any connection to a database, and now that this project is coming to an end and my next assignment is Web application with database connection. I wanted to see what my options are for database migration tools. In the past I’ve used dbsetup.vbs script, created by Alek Davis, and although it worked it did require some modification to the underline script. So I’m currently looking at several alternatives that could serve as a suitable replacement.

RikMigrations
Migrator.NET
Subsonic Migrations
dbDeploy.NET

Here are some useful links I’ve found to help determine which toy, I mean, tool, I plan to use next.

http://www.infoq.com/news/2009/01/migrations_dotnet

http://flux88.com/blog/net-database-migration-tool-roundup/

http://alekdavis.blogspot.com/2008/07/database-installer-revised.html

Share/Bookmark

photo credit: erix!

In my last post, See the Code, Be the Code, I compared agile development to the game of golf. But how does one truly “see the code” as the software grows in size and complexity? On one hand, you could ignore the fact that software is developed over many iterations and try to build a very complex system all at once that does everything under the sun, or you can keep the design simple and focus on the iteration at hand knowing that as our understanding increases we will refactor the code.

Refactoring is the process by which you modify the behavior and appearance of the code to ensure that code is up-to-date with current system requirements or changes in the system environment. It gives the development team an opportunity to continuously improve code quality for long term readability and maintainability. The easier the code is to follow, the less time it will take for current and future development teams to make changes as the system matures. It can also help the development team take advantages of improvements to existing frameworks and other software used to develop the application. These improvements can be realized through better performance and reusability of existing and future code. In short, it helps keep your code from become stale and mildewy.

So we are developing a custom desktop application that utilities a third party PDF library. Our team has developed the core tools for marking up documents using simple shapes – lines, rectangles, circles and polygons, calibration of a document to a specific scale – 1/4 in = 1 ft, and more complex shapes that using the scale to compute the shapes length, area, perimeter, etc. Now we are working on hole 10 of the software development golf course and one of the user stories requires multiple scales per document.

Upon inspection of our code base, we decided that we could meet the user requirement by restructuring the code contained within the ViewPort class. This class was originally designed to allow a single scale for the entire document, and contains methods for setting and updating the scale and basic properties for accessing the scale information for use by markup that requires calibration.  The ViewPort still needs a single, default scale that’s used for entire document but should support scales for specific areas/zones of the document.  Below shows the current and proposed refactored ViewPort class and new ScaleZone class.

Now that we have an idea of how we want to refactor the code, we need some unit tests.

Unit Testing is just as important as refactoring because it helps to ensure unchanged code isn’t affect by improvements to other parts of the applications,  it helps document how to use new or updated functionality, and confirms the accuracy of our changes. So before we start changing the coding, we create a few  Unit Test. For example AddScaleZone method: we want to test calibrating a blank document and adding a new scale zone. We should save the document and reopen and assert that new scale zone exist with the correct data.

[Test]
public void AddScaleZoneTest()
{
  string fileLocation = FileUtil.GetFileLocation(FileUtil.BlankDocument);
  docModel = new DocumentModel(fileLocation);

  CreateDefaultCalibrationViewPort(docModel.Document);

  docModel.SaveAs(savedFileLocation);
  docModel.Close();

  MeasurementProperty scaleZoneMeasurementProperty = GetScaleZoneMeasurementProperty();

  savedDocModel = new DocumentModel(savedFileLocation);

  // Create the scale zone and add to viewport
  ScaleZone scaleZone = new ScaleZone(new RectangleInfo(25, 25, 425, 425), 1);
  scaleZone.SetScaleZone(scaleZoneMeasurementProperty, "ScaleZoneUnitTest");
  savedDocModel.AddScaleZone(scaleZone);

  int scaleZoneCount = savedDocModel.GetScaleZoneCount();
  savedDocModel.SaveAs(savedFileLocation);
  savedDocModel.Close();

  ValidateCalibrationViewPortSaved(savedFileLocation);
  ValidateScaleZoneSaved(savedFileLocation, scaleZoneMeasurementProperty, new RectangleInfo(30, 30, 90, 90), 1, scaleZoneCount, scaleZone);
}

We know the project won’t compile until we add the new ScaleZone class and refactor the ViewPort class. Let’s also not forget that our existing unit tests can become stale and out-of-date; it’s just as important to update the existing ViewPort Unit Tests base on the new requirement.

The point here is that code regardless of purpose needs refreshing. Don’t let it mildew! Refactor your code!

Share/Bookmark

photo credit: foxypar4

If you’ve every seen professional golfers drive the ball up the fairways, or putt the ball on the greens, they make it seem so easy. But for the vast army of us duffers out there, we know it is anything but.

There are many variables to consider to ensure success on every hole you play. There’s the distance from the tee to the greens, the natural elements  — wind, rain and sun –, the number of allotted strokes per hole, the vexing choice among various woods and irons, the hazards dotting the course, and the mental and physical aspect of dealing with this humbling game. But there is one answer to these challenges: practice, practice and more practice to fine tune your craft. Well, developing software is similar in many respects.

Software development has it’s own thicket of variables to consider. There are the many functional and non-functional requirements that you must contend with, the different users involved (stakeholders, development team, system users, and the army of user persona’s) for the project, the changing requirements, resources and time that can impact the project, and various tools, technologies and platforms thrown into the mix as well.

Applying agile to the mix helps brings order and focus to our round of software development. Just as in golf we don’t play the whole course at once, but one hole at a time in 18 iterations. Success can be determined quickly through client feedback in those short iterations, just like each shot in golf tells you right away whether you’ve succeeded or failed.

Agile embraces changing requirement, fosters open communication between the customer and project team, minimizes the impact of resource juggling on the project by utilizing pair programming, and highlights the team accomplishments and removes obstacles using daily scrums. And last but not least, it takes practice, practice, practice and process refinement over the life of the project using retrospective session.

With practice and the right approach, we agile software developers can make developing software seem as easy as a Tiger Woods drive.

Share/Bookmark

ADO.NET Entity Framework is an object relationship mapping (ORM) tool. It was designed to provide a layer of abstraction between the logical schema and concept schema of an application, and to decrease the amount code need for a data centric application.

Some benefits of the Entity framework:

• Data storage engine and schema independence: Due to the layer of abstraction between the logical and conceptual schema of your application, you no-longer need to know and hard cord the application to a specific data storage engine or schema.
• More expressive conceptual model: Entity types can inherit from other entity types and allows the creation of more complex types in addition to the standard scalar types support by the database.
• Access to multiple database system: Because the application is free from hard code data storage dependencies, the developer has the ability to access data from multiple storages using a consistent application object model
• LINQ: Language Integrated query support that offers compile time syntax checking for queries against the conceptual model.

The Entity Framework works by allow the developers to hand code or use code generation tools to create the XML metadata for the conceptual entity data model, a storage entity model, and a mapping specification between the two. The XML file created for the conceptual entity data model is then stored in the conceptual schema definition file (.csdl), the storage entity model is stored in the storage schema definition file (.ssdl), and mapping between the two in the mapping specification language file (.msl). These XML file are then loaded into the metadata workspace of the entity framework, and a set of classes are generated to allow the developer to work directly with the conceptual model and indirectly with the logical model.

Figure: ADO.NET Entity Framework Architecture

So with these benefits design and built directly into the the framework and the logical approach used by framework to interact with various data providers, some experts in entity-based applications and software architectures on the .NET platform still feel that the framework has some pretty large deficiencies.

They are concerned that the framework is…

• Inordinate focus on the data aspect of entities leads to degraded entity architectures
• Excess code needed to deal with lack of lazy loading
• Share, canonical model contradicts software best practices
• Lack of persistence ignorance causes business logic to be harder to read, write, and modify, causing development and maintenance costs to increase at an exaggerated rate.
• Excessive merge conflicts with source control in team environments.

Are these claim valid concerns to consider?

Sure, only if the framework is mature with several versions under its belt and its prohibits the productivity, maintainability and scalability of the application.

Isn’t the right approach to software development to deliver a subset of the full feature set right the first time than try to deliver everything at once with massive issues that prevent the usability of the tool?

You decide…

Below are some useful references to get you going with Entity Framework.

Achieve Flexible Data Modeling With the Entity Framework
ADO.NET Entity Framework Pre-release documents
Microsoft ADO.NET Entity Framework Overview
ADO.NET Entity Framework Taking Some Heat
Programming Against the ADO.NET Entity Framework
ADO .NET Entity Framework Vote of No Confidence

Share/Bookmark

I’ve been looking at some of the new features in the .NET 3.5 framework and have found Object Relation Mapping (ORM) very similar to IBatis.NET and NHibernate. In .NET 3.5, they use attribute based mapping between the underlying data table and entity class (Domain Object). For instance

using System.Data.Linq;
using System.Data.Linq.Mapping;
[Table="Books"]
public class Book {
    [Column="Name"]
    public string _Name;
    [Column="ISBNNo"]
    public string _isbn;
    ...
}

What you notice is the the class Book is mapped to a table called Books using the Table attribute and particular table columns are mapped using the column attribute on the Book class instance fields. Compared with IBatis.NET XML files; you would have to:

1. Reference the Book class using the <typedalias type=”Namespace.Book, Namespace”/>
2. Create a ResultMap that exposes the Book class internal fields using <property name=”ISBN” Column=”ISBN”>
3. Create the sql statement that references the resultmap for the Book class so IBatis.NET and hydrate the results. Below is sample sqlmap.xml file for Ibastis.net

<sqlMap namespace="Surveys" xmlns="http://ibatis.apache.org/mapping">
    <alias>
        <typeAlias alias="Book" type="Namespace.Books, AssemblyName"/>
    </alias>
    <resultMaps>
        <resultMap id="BookMap" class="Book">
           <result property="Name" column="Name"/>
            <result property="ISBN" column="ISBN"/>
        </resultMap>
    </resultMaps>
    <statements>
        <select id="GetBooks" parameterClass="map" resultMap="BookMap">
            select name, isbn from books
        </select>
    </statements>
</sqlMap>

Furthermore, much of the guesswork required to create the parameterizes queries used to pull information from the database and load a collection of Book objects has been added. Simply creating a new Linq DataContext object, passing the connection string to the database and calling the generic GetTable<T> (where T is class name. in this case Book) is all you need to get the results, versus creating the individual sql in the xml file and calling one of the QueryForObject or QueryForList methods found for IBatis.NET.

Last but not least, Linq provides the programmer with built-in sql like keywords used to build expressions that sort, aggregate and limit the original result set to some more specific or limited result result set without going back to the underlying database.

Although, this is a very simplicity view of mapping a database table to .NET class. This does give you a good picture to the additional overhead required to using IBatis.NET xml file mapping versus Microsoft’s Linq to Sql attribute base mapping, and demonstrates how ORM is now built right into the .NET Framework. And, you be happy to know that your .NET 3.5 Linq to Sql applications will still run on .NET 2.0 because the new features are specific to the specific 3.5 .NET compiler.