Philip Beadle

Check out my video on DGTV :)

philip.beadle@readify.net — Tue, 06 May 2008 14:00:00 GMT

Michael Kordahi aka the Delicate Genius is a Microsoft Developer Evangelist in Sydney, he inteviewed me about my ReMIX session last week check it out here http://delicategeniusblog.com/?p=682.

Open Force 08 Connect - Check out the free DNN training you can get

philip.beadle@readify.net — Tue, 06 May 2008 14:00:00 GMT

There is some free top quality training going on down Orlando way on the weekend between the two US Tech Ed sessions. Check out http://www.openforce08.com/Home/OpenForceConnect/Orlando/Overview/tabid/115/Default.aspx for more details. Looks like a great weekend of DNN, shame I cant make the trip for the 4th time this year :).

Let me know if youre going.

ReMIX bling for my Blog.

philip.beadle@readify.net — Thu, 01 May 2008 14:00:00 GMT

Just got this new bling for my Blog about ReMIX '08. Building Rich Internet Applications using Microsoft Silverlight 2

ReMIX Australia '08

philip.beadle@readify.net — Tue, 29 Apr 2008 14:00:00 GMT

I will be presenting at ReMIX Australia '08 in Sydney and Melbourne in May. Check out the details here

http://www.microsoft.com/australia/remix08/index.aspx

MVP Reawarded

philip.beadle@readify.net — Tue, 01 Apr 2008 14:00:00 GMT

Got my email this morning reawarding me MVP for another year. Now enough of that time to get back to finishing the TDD DNN Module template.

Test Driven Module Update

philip.beadle@readify.net — Tue, 01 Apr 2008 14:00:00 GMT

I have now nearly completed the module. Tests are now in place for all layers and cover

100% of the testable code in the Edit part of the module
100% of the Controller
100% of the testable parts of SqlDataProvider

You can check out the code solution at http://www.codeplex.com/TestDrivenDNNModule

I'll write the rest of the tests ASAP.

TDD DNN Modules - Some changes to the core

philip.beadle@readify.net — Sun, 24 Feb 2008 14:00:00 GMT

When you are developing a DNN module you have access to a bunch of properties in the core framework such as UserID, ModuleID and LocalResourceFile. When you start developing modules using Test Driven Development (TDD) you still need access to these properties which means we need to be able to access them from the presenter class.

The presenter class has a construct like this

Public Sub New(ByVal _View As IViewTestDrivenDNNModule)

View = _View

Controller = New TestDrivenDNNModuleController
End Sub

which means that the View we access in the presenter class only has the properties specified in the interface for the View. We can access the LocalResourceFile if the DotNetNuke.UI.Modules.IModuleControl is inherited but since the PortalModuleBase class does not have an interface we cannot access the other properties we need.

So I made a few changes to the core to experiment with an Interface for the PortalModuleBase. Firstly I created a new interface called IPortalModuleBase

Public Interface IPortalModuleBase

ReadOnly Property ModuleID() As Integer

ReadOnly Property UserID() As Integer
End Interface

Then the PortalModuleBase class implements the new interface

Public Class PortalModuleBase

Inherits UserControlBase

Implements IModuleControl

Implements IPortalModuleBase

Public ReadOnly Property ModuleId() As Integer Implements IPortalModuleBase.ModuleID

And lastly the interface for our module inherits both of the IPortalModuleBase and IModuleControl interfaces like this

Public Interface IViewTestDrivenDNNModule

Inherits DotNetNuke.UI.Modules.IPortalModuleBase

Inherits DotNetNuke.UI.Modules.IModuleControl

This allows easy access to the properties we need in the presenter class like this

colTestDrivenDNNModules = objTestDrivenDNNModules.GetTestDrivenDNNModules(View.ModuleID)

Previously I had just added new properties to the IViewTestDrivenDNNModule interface and pulled the values through from the ViewTestDrivenDNNModule partial class. This however was inelegant and led to having properties such as ModuleId1!! This new solution is far more useable and very easy to implement.

Doing this will allow much easier development of TDD DNN modules.

TDDDNN - Diagram of how it all fits together so far.

philip.beadle@readify.net — Sun, 17 Feb 2008 14:00:00 GMT

I drew this up to help give an understanding of how the testing of DNN Modules is going to work for my TDD DNN Module template at CodePlex.

This diagram shows how each level of a DNN module can be unit tested using RhinoMocks to generate the mock objects. It also shows where I will be driving the integration testing and also the automation testing using Watin.

Mock objects and mock controllers allow you to create known return values for the methods you are testing. Doing this allows you directly test a piece of code knowing that if the code is corect it will return the value you assigned to the mock object/controller. the unit test is then just that, a test of a unit of work. Once you have the unit tests written you can then do a code coverage analysis and make sure that you code is fully covered (where useful). This allows you to test for each of the code paths in your code. Good code coverage gives you confidence that the code you have written doesnt have black holes.

My favourite part of having a well covered code is that when a bug is reported you can write a test to prove that it is a bug and then modify your code, rerun your tests and know that you didnt intrduce another bug with the fix implemented.

Test Driven DNN Modules

philip.beadle@readify.net — Thu, 14 Feb 2008 14:00:00 GMT

In my day job I and my teams write unit tests for all of our code and we write our projects to be testable, this gives great benefits and actaully makes your projects go faster. My current porject has a code coverage of 80%+ and we have nearly 800 tests written already. The really cool thing about having Unit tests for all of your code is that when you or someone else needs to cahnge some part of the solution you simply run the tests afterwards to make sure you didnt break anything elsewhere.

The other thing we do is when a bug is reported by the Test Team, who write our automation tests with Watin, we firstly write a test to prove there is a bug and then mod the code to fix the bug. This gives us an extra set of tests that test the edge case we missed before and thus makes the code even stronger.

And yet another benefit of unti testing is that you can include the tests in your load tests to measure performance.

So with all these great reasons to write unit tests I have started building a template DNN module that can be fully unit tested. I have created a new Forge project here http://www.codeplex.com/TestDrivenDNNModule . You can download the template and see how Im doing it. One of the things you will find is that to write unit tests for ASP.Net apps you need to be able to separate out the functional code from the normal code behind file to conduct a proper uint test. To do this I have used the Passive View Pattern from Martin Fowler. I was put onto this by Dan Bartholomew who discovered it is very similar to the pattern in the WCSF.

If you look in the code behind file you'll see that the only code is to set properties and to call the methods in the Presenter class which ahs all the functioanl code. The code in teh code behind does not need to be unit tested as it only sets and gets properties or triggers an event. The code in the presenter class is what gets tested.

My next task is to add in the mocking of each layer using RhinoMocks so that i can unit test each part of the Presenter code without worrying about hitting code further down the stack such as the Controller class and data providers. Dan is helping me out on that so we should have some more of the template done next week.

End of my web farm experiment

philip.beadle@readify.net — Mon, 11 Feb 2008 14:00:00 GMT

Well sorry to say I ran out of time trying to get the servers setup and run a few tests on DNN before I had to give them back. Ill try again with a virtual setup soon.