Manipulating the DOM with Firebug

Currently I"m working more and more with jQuery and JavaScript to get behavior into my pages. This was quite painful in the beginning as I was depended a bit too much on alert"('this happens!').

But I guess this is where you get started and then find out about the excellent firebug. With the console you can then fire your JavaScript and jQuery commands to the page like so:

I'm querying on of Holland's main news sites for their logo. Firebug conveniently comes up with the link to the element and when clicked it will show where it's located on the page.

This is all nice but let's change the boring logo of nu.nl to that of our own!

Easy enough, just use the following to change the picture in the page:

But changing the elements in a page is just the beginning. You can just as easily add new functionality by binding a click event handler to one or more elements in the page.

Viewing registered events

You can also use the console to inspect what events are registered to an element on the page. All you need to do is use this syntax:

When we try that on the last input (randomly chosen) you get an overview of all the events bound (in this case only one).

If you the click on the object and hover over "function" you'll end up with the code itself:

This is a very neat trick that I wish I had stumbled upon earlier. Hope it helps.

I was pointed to the Passionate programmer by one of the blog posts at Los Techies. I'm about a third through the book and so far it has been a real joy to read!

It's full of good tips on how to alter your behavior to become something better as a programmer. I'm probably going to write some posts on what I've done with the various "act on it!", but in the meantime, go get it and start reading!

Just a quick update on my previous posting following one of the comments made by den Ben

just out of curiosity... why wouldn't you
dispatcher.Add<SaveDocumentRequest>(s =>
{
s.Document = document;
s.UserID = userID;
});

He's absolutely right. Using a Func forced me to (mis)use the params keyword as you are not allowed  to use the above syntax with the old code:

          public virtual 
          IDispatcher Add<TRequestType>(params Func<TRequestType, object>[]
funcs) where TRequestType : Request, new()
{ TRequestType request = new TRequestType(); foreach (var func in funcs)
{ func.Invoke(request); } AddRequest(request, false); return
this; }

I actually had noticed the code not using the return value by the func but disregarded it as I was a bit too happy with the "elegance" of my inital solution.

But I think (and I think you'll agree) that using an Action is much cleaner here:

          public virtual 
          IDispatcher Add<TRequestType>(Action<TRequestType>
action) where TRequestType : Request, new()
{ TRequestType request = new TRequestType(); action(request);
AddRequest(request, false); return
this; }

Thanks den Ben!

One of my colleagues asked me today if I could write a utility function that would make his life more easy.

The objective was to call a stored procedure n-times for every item in a list. Of course some of the properties on every item had to be mapped to parameters in the stored procedure.

The desired syntax would be something like:

builder.SetStoredProcedureNameTo( " some sproc name ")
        .Execute ( customerList ,
            (s,t) => s.AddParameterWIthValue( parameterName, t.PROPERTY_NAME_1) ,
            (s,t) => s.AddParameterWIthValue( parameterName, t.PROPERTY_NAME_2) ,
             (s,t) => s.AddParameterWIthValue( parameterName, t.PROPERTY_NAME_3)
      );

I already have a fluent wrapper class to make our ADO.Net a bit more friendly, the interface looks like:

          public interface 
          ICustomSqlCommandBuilder { ICustomSqlCommandBuilder SetStoredProcedureNameTo(string storedProcedureName); ICustomSqlCommandBuilder AddParameterWithValue(string parameterNameInDatabase, object value); ICustomSqlCommandBuilder AddExlicitOutputIntParameterToTheCommandFor(string parameterName); ICustomSqlCommandBuilder AddExlicitOutputDateTimeParameterToTheCommandFor(string parameterName); IList<TReturnType>
ExecuteReaderFor<TReturnType>() where TReturnType
: new(); }

Nothing special except for the ExecuteReaderFor<TReturnType>() but that's for another post.

Having the fluent interface on ICustomSqlCommandBuilder combined with the lambda magic explained in this post I came up with the following signature:

          ICustomSqlCommandBuilder ExecuteScalarForThisList<T>( IList<T>
list, params Action<ICustomSqlCommandBuilder,
T>[] actionList);

(s, t) => s.AddParameterWithValue("parameterName",
t.PROPERTY_NAME)

to every property in the object<T> that needs to be mapped against a parameter in the stored procedure. Having the params allows us to map as many properties to parameters in the stored procedure as we like. If we then loop through all the items in the list first and apply all actions in the actionList per item, we can then call ExecuteScalar on the stored procedure.

foreach (var item in list)
{ foreach (var action in actionList)
{ action.Invoke(this, item); } var result
= sqlCommand.ExecuteScalar(); sqlCommand.Parameters.Clear(); }

Now, another requirement was to wrap it in a transaction and also to have the verification of the result a bit more flexible. All in all not too complicated, just a matter of introducing another Action:

public ICustomSqlCommandBuilder ExecuteScalarForThisList<T>( IList<T>
list, Action<object>
verify, params Action<ICustomSqlCommandBuilder,
T>[] actionList) { sqlCommand.Connection.Open(); SqlTransaction transaction
= sqlCommand.Connection.BeginTransaction(); sqlCommand.Transaction = transaction; try { foreach (var item in list)
{ foreach (var action in actionList)
{ action.Invoke(this, item); } var result
= sqlCommand.ExecuteScalar(); verify(result); sqlCommand.Parameters.Clear(); } transaction.Commit();
} catch (SqlException)
{ transaction.Rollback(); throw; } catch (Exception)
{ transaction.Rollback(); throw; } return
this; }

Including a bit of exceptionally brittle exception handling and calling the stored procedure on a list of Customers now resolves to:

Action<object>
resultConstraint = result => { if (result != null)
{ if ((int)result
> 1000) { throw new Exception("result
should be less than 1000!"); } } }; builder .SetStoredProcedureNameTo("sens_sp_modifyCustomerIncome")
.ExecuteScalarForThisList( customerList, resultConstraint, (s, t) => s.AddParameterWithValue("id",
t.ID), (s, t) => s.AddParameterWithValue("income",
t.Income) //etc for the rest of the properties );

At my current project we are using a dispatcher class to batch requests to our WCF layer based on the Request/Response Service Layer created by Davy Brion. Once you call the Get<TResponseType>() on the dispatcher the WCF layer starts working on the requests one by one and return them in one roundtrip.

Adding requests to the dispatcher is easy:

          var saveDocumentRequest = new SaveDocumentRequest(); var getRemainingDocuments
= new GetRemainingDocumentsRequest();
dispatcher.Add(saveDocumentRequest, getRemainingDocuments);

Where the signature of the Add method in Dispatcher is like;

          public void Add(params Request[]
requests)

Although this syntax is not bad, it feels like so much like code from last month: not very sexy. Wouldn't be more fun if we could spice it up a bit using generics and a bit of Func?

I'd love to get rid of instantiating a variable just for the sake of adding it to my dispatcher. After a bit of fiddling around with my unit tests I came up with the following solution.

What I want is to call the Add method in a generic way and set the parameters on my request object inline, using a Func. This is best illustrated with a test:

[Test] public
void can_assign_value_using_a_func_in_a_generic_method_call() { Guid id
= Guid.NewGuid(); var dispatcher
= new Dispatcher();
dispatcher.Add<GetPersonsRequest>(s =>
s.ID = id); //disregard ugly cast; this is only for test
purposes var request = (GetPersonsRequest)dispatcher.Requests.First();
request.ID.ShouldEqual(id); }

public class GetPersonsRequest:Request { public Guid ID
{ get; set; } } public
class Dispatcher { public Dispatcher()
{ Requests = new List<Request>();
} public void Add<TRequestType>(params Func<TRequestType, object>[]
funcs)
where TRequestType : Request, new()
{ var request = new TRequestType(); foreach (var func in funcs)
{ func(request); } Requests.Add(request); } public IList<Request>
Requests { get; set;
} }

I can now set only property in my Request type, what if it has more properties that need to be set? Just introduce the infamous params to the method signature like so:

public void Add<TRequestType>(params Func<TRequestType, object>[]
funcs) 

where TRequestType:Request, new()
{ var request = new TRequestType(); foreach (var func in funcs)
{ func(request); } Requests.Add(request); }

And again the test:

[Test] public
void can_assign_two_values_using_a_func_in_a_generic_method_call() { var dispatcher
= new Dispatcher(); Guid id
= Guid.NewGuid(); dispatcher.Add<GetPersonsRequest>(s
=> s.ID = id, t=> t.GetAllDetails = true); //disregard
ugly cast; this is only for test purposes var request
= (GetPersonsRequest)dispatcher.Requests.First();
request.ID.ShouldEqual(id); request.GetAllDetails.ShouldBeTrue(); }

When we change the return type of the Add method to the dispatcher itself, we can then use a fluent interface to get a very friendly syntax  for making calls:

//input parameters for first request var document
= new object(); var userID
= Guid.NewGuid(); //input
parameters for second request var dossierID
= Guid.NewGuid(); dispatcher .Add<SaveDocumentRequest>(s
=> s.Document = document, t => t.UserID = userID) .Add<GetZaakRequest>(s
=> s.DossierId = dossierID);

I really like the fact that I don't have to initialize a variable and still have access to all the properties in the request object..

I'm always trying to improve on my speed in development. Yesterday I noticed Udi Dahan using the In-proc test feature of TestDriven.Net in one of his presentations at the SDC - Netherlands, like so:

I had seen this option before but as it was hidden in some submenu and the regular test method worked just fine, there seemed no benefit in using it.

However.

Running your tests using In-proc makes for about 25% speed difference on average! To me, this is very noticeable but the function is hidden in some context submenu, hence still slow to use. After a bit of emailing with TestDriven.Net, it appears that you can run In-proc using the DTE runner.

To map it to a shortcut key, use the following screenshot:

I have converted quite a few to Resharper recently. I'm quite the addict myself and I can't see myself using Visual Studio productively without it anymore.

Resharper does have a learning curve however since there are just because of the sheer amount of enhancements it brings to working with VS.

To get you up to speed using Resharper, perform these settings in Visual studio after installing:
Within Visual studio: ALT - R - O => intellisense, completion behavior =>
Automatically show completion list in 0 milliseconds
"Check" all options except Case-sensitive prefix matching
Finally, "Only those that are at least": set this to 1

You can watch the following screencasts:
- James Kovacs screencasts on Resharper
- My own MVP coding demo using Resharper and Rhino mocks
- Ayende demoing Rhino mocks

(pls note that you'll need the Camtasia TSCC codec to view the last two)

You can use keyjedi to display the shortcuts used when someone else is looking over your shoulder. This will greatly enhance the introduction within your team. This only works on x86 systems, I have compiled the code into an x64 assembly that works on my win7 machine, let me know if you need it.

Lastly, have the developers print out the Resharper keymapping (in plastic cover preferably, in case of any coffee, tea and all that :-) )

If you have any further questions, please let me know.

One of my machines refused to install updates to the .NET Framework 3.5 sp1, both through auto-update and when installing manually. I finally fixed it by using Aaron Stebner's .NET framework cleanup tool and re-installing .NET. This tool radically removes all versions of the .NET framework, including IIS artefacts, registry entries, the works. I found this tool through a post on raymond.cc.

Note that this tool should probably not be the first thing to try; uninstalling and re-installing the .NET framework versions would probably a safer bet to try first.

Nothing much to, just that it took me some time to figure it out today. The code below tests whether DivisionID is actually set in the presenter.

          public class 
          Presenter { readonly IRepository repository; public Presenter(IRepository repository)
{ this.repository = repository; } public IView View
{ get; set; } public
void GetDivision() { View.DivisionID = repository.GetDivisionID(); } } public
interface IView { int DivisionID
{ get; set; }
} [TestFixture] public
class PresenterTests { Presenter sut; IView view; IRepository repository;
[SetUp] public
void SetUp() { view = MockRepository.GenerateMock<IView>();
repository = MockRepository.GenerateMock<IRepository>();
sut = new Presenter(repository){View
= view}; } [Test] public
void when_on_the_sut_GetDivisionID_is_called_it_should_set_the_divisionID_on_the_view()
{ //AAA mocking style //Arrange const
int divisionID = 1; repository.Stub(s => s.GetDivisionID()).Return(divisionID); //note:
the expectation is set when DivisionID is set to divisionID view.Expect(s =>
s.DivisionID = divisionID); //Act sut.GetDivision(); //Assert view.VerifyAllExpectations();
} }

This is the third posting in the WEWLC-series.

Other posts are:

I Can't Get This Class into a Test Harness

I don't have much time and I have to change it

Assumptions on the reader

"Getting tests in place to make changes can be a bit of a problem. If you can instantiate your class separately in a test harness, consider yourself lucky."

Instantiating a class should not be hard, if you do have issues have a look at I Can't Get This Class into a Test Harness. That should take care of most of your problems.

But instantiating is often just the first part of all the hurdles to take. The second part is writing a test for the methods inside.

Fortunately, in most cases, the amount of work that we have to do to write tests for methods isn't as drastic. Here are some of the problems that we can run into.

• The method may be private

• The method may be hard to call because it has parameters that are hard to construct

• The method might have bad side effects (modifying a database, writing to the file system etc)

The Case of the Hidden Method

If we need to write a test for a private method we need to make it public. There are some tricks in getting visibility on the method in your tests but I don't recommend it. First of all, if there is a need for private method odds are that what you need is a another collaborator.

This is of course a rather fundamental discussion. If you do care about keeping the method invisible to callers you can make it protected. Once it is protected you can derive a test class and add a public method that will simply call the protected method in the base class.

In most cases I would recommend moving the method to a separate class and inject it into the constructor of the class that interacts with it. Once there is a need to alter the behavior of a private method it is obviously doing something important, hence, it should be under test.

The Case of the "Helpful" Language Feature

Michael Feather is referring to sealed classes that don't have constructor. How do you test interaction code that takes such a class as a parameter in a method? Let's have a look at an example:

          public class 
          StreamHelper { const
int MIN_LEN = 4; public IList GetStreams(HttpFileCollection files)
{ var list = new List<Stream>(); foreach (string name in files)
{ HttpPostedFile file = files[name]; if ((file.FileName.EndsWith(".txt")
&& file.ContentLength > MIN_LEN)) { list.Add(file.InputStream); } } return list;
} }

According to MSDN, the HttpFileCollection provides access to and organizes files uploaded by a client. Since this class is sealed and only has an internal constructor, how can you test this method?

Turns out that HttpFileCollection derives from NameObjectCollectionBase which has a parameterless constructor which is protected. If we thus derive from NameObjectCollectionBase, implement the indexer required and change the signature of the GetStreams method a bit to take our custom class instead of the HttpFileCollection we should be able to get going.

Please note, this is going to be a hefty refactoring. Right, lets get down to it. First let's create a fixture for our tests:

[TestFixture] public
class HttpCollectionTests { [Test] public
void can_instantiate_a_derived_class_from_NameObjectCollectionBase() { var customHttpFileCollection
= new CustomHttpFileCollection(); var collectionBase
= customHttpFileCollection as NameObjectCollectionBase;
collectionBase.ShouldNotBeNull(); } }

This means deriving from NameObjectCollectionBase

          public class 
          CustomHttpFileCollection : NameObjectCollectionBase {
}

The next test is to be able to call GetStreams() in StreamHelper. Rather than changing the existing method we are going to create a new method with the same name, but different signature so that we can call it with our new CustomerHttpFileCollection:

[Test] public
void can_use_the_custom_class() { var collection
= new CustomHttpFileCollection(); new StreamHelper().GetStreams(collection);
}

          public 
          IList<Stream>
GetStreams(CustomHttpFileCollection files) { var list
= new List<Stream>(); foreach (string name in files)
{ HttpPostedFile file = files[name]; if ((file.FileName.EndsWith(".txt")
&& file.ContentLength > MIN_LEN)) { list.Add(file.InputStream); } } return list;
}

This means implementing the indexer used in GetStreams() in our custom class. Luckily Resharper knows what to do and we can use ALT-ENTER to generate the code. Next to the indexer we will also need an IList to store the files and a method to add them to the internal collection:

          public class 
          CustomHttpFileCollection : NameObjectCollectionBase { public HttpPostedFile this[string name]
{ get { return httpPostedFiles.Where(s
=> s.FileName == name).FirstOrDefault(); } } }

This poses a bit of an issue; we can instantiate a HttpPostedFile so how are we going to populate an internal collection? Since this one is sealed, does not have a suitable base class and has no constructors we need to be creative. We need a custom implementation of the HttpPostedFile. First we create an interface, then define the same members on the interface as are in the HttpPostedFile class. Once that is done we can change the signature of the indexer to IHttpPostedFile and add some logic to store and add the files to the collection class, like so:

          public class 
          CustomHttpFileCollection : NameObjectCollectionBase { readonly IList<IHttpPostedFile>
httpPostedFiles = new List<IHttpPostedFile>(); public IHttpPostedFile this[string name]
{ get { return httpPostedFiles.Where(s
=> s.FileName == name).FirstOrDefault(); } } public void AddHttpPostedFile(IHttpPostedFile file)
{ httpPostedFiles.Add(file); } }

          public interface 
          IHttpPostedFile { int ContentLength
{ get; } string ContentType
{ get; } string FileName
{ get; } Stream InputStream
{ get; } }

Change the HttpPostedFile to the new IHttpPostedFile in GetStreams():

          public 
          IList<Stream>
GetStreams(CustomHttpFileCollection files) { var list
= new List<Stream>(); foreach (string name in files)
{ IHttpPostedFile file = files[name]; if ((file.FileName.EndsWith(".txt")
&& file.ContentLength > MIN_LEN)) { list.Add(file.InputStream); } } return list;
}

Now that we have set up the collection, let's write a test to see if it all works

          Stream GetStream() { const
string s = "hello world"; var memoryStream
= new MemoryStream(System.Text.Encoding.Default.GetBytes(s)); return memoryStream;
}

[Test] public
void can_use_the_customcollection_to_test_the_StreamHelper_class() { var collection
= new CustomHttpFileCollection(); var httpPostedFile
= MockRepository.GenerateMock<IHttpPostedFile>();
httpPostedFile.Stub(s => s.InputStream).Return(GetStream()); httpPostedFile.Stub(s
=> s.FileName).Return("somefilename.txt");
httpPostedFile.Stub(s => s.ContentLength).Return(5); collection.AddHttpPostedFile(httpPostedFile); IList<Stream>
streams = new StreamHelper().GetStreams(collection);
streams.Count.ShouldEqual(1); }

When we execute this test a lot is happening. First I create a mock of the IHttpPostedFile interface so that I can stub the properties. This allows me to test the method without having an actual implementation of the interface. Not that it would have complicated things tremendously, but it's a nice technique.

I also use a convenient helper method to get me a stream. This will come in handy later when I want to verify the outcome of the GetStreams() method.

Let's execute and:

------ Test started: Assembly: Koning.WEWLC.Tests.dll ------

TestCase 'Koning.WEWLC.Tests.HttpCollectionTests.can_use_the_customcollection_to_test_the_StreamHelper_class'
failed:
  Expected: 1
  But was:  0
    at Machine.Specifications.NUnitShouldExtensionMethods.ShouldEqual(Object actual, Object expected)
    C:\Dev\Personal\WEWLC\Koning.WEWLC\Koning.WEWLC.Tests\Tests\HttpCollectionTests.cs(59,0): at Koning.WEWLC.Tests.HttpCollectionTests.can_use_the_customcollection_to_test_the_StreamHelper_class()

0 passed, 1 failed, 0 skipped, took 1.37 seconds.

Why is this happening? My bad, I didn't implement GetEnumerator() on the custom collection class. This is easily fixed however:

          public class 
          CustomHttpFileCollection : NameObjectCollectionBase, IEnumerable { readonly IList<IHttpPostedFile>
httpPostedFiles = new List<IHttpPostedFile>(); public IHttpPostedFile this[string name]
{ get { return httpPostedFiles.Where(s
=> s.FileName == name).FirstOrDefault(); } } public new IEnumerator<string>
GetEnumerator() { return httpPostedFiles.Select(s
=> s.FileName).GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator()
{ return GetEnumerator(); } public
void AddHttpPostedFile(IHttpPostedFile file)
{ httpPostedFiles.Add(file); } }

I'm using some Linq goodness to get to the filenames and iterate over that. Next up is refining our test and run it again:

[Test] public
void can_use_the_customcollection_to_test_the_StreamHelper_class() { var collection
= new CustomHttpFileCollection(); var httpPostedFile
= MockRepository.GenerateMock<IHttpPostedFile>();
httpPostedFile.Stub(s => s.InputStream).Return(GetStream()); httpPostedFile.Stub(s
=> s.FileName).Return("somefilename.txt");
httpPostedFile.Stub(s => s.ContentLength).Return(5); collection.AddHttpPostedFile(httpPostedFile); IList<Stream>
streams = new StreamHelper().GetStreams(collection);
streams.Count.ShouldEqual(1); streams.First().Length.ShouldBeGreaterThan(0); new StreamReader(streams.First()).ReadLine().ShouldContain("hello
world"); }

------ Test started: Assembly: Koning.WEWLC.Tests.dll ------

1 passed, 0 failed, 0 skipped, took 1.48 seconds.

Now note that when using the GetStreams() method one would have to transform the items in HttpPostedFileCollection to the IHttpPostedFile interface before using it.

The Case of the Undetectable Side Effect

Every so often you encounter code that just makes you mumble WTF way more than is healthy for any sane developer. In most cases things just happen everywhere. When the code is performing a query, it's also updating some other pieces, altering the file system a bit and lastly setting a whole bunch of other objects in an invalid state.

I wouldn't recommend getting the debugger up and running to see what's going on. Most of the time it consumes a lot of time and keeps the frustration really high.

What this kind of code is lacking is proper Command Query Separation (CQS). From the WEWLC book "It's a is a design principle first described by Bertrand Meyer. Simply put, it is this: A method should be a command or a query, but not both. A command is a method that can modify the state of the object but that doesn't return a value. A query is a method that returns a value but that does not modify the object."

You should always strive to adhere to this principle. It will make your code easier to read and more importantly, easier to skip when reading. When I encounter code that does not adhere to CQS I always split it up in several smaller methods, break out objects etc etc. Once that is done, testing immediately becomes easier on the class.

It's a matter of subclassing and overriding any behavior that is unwanted so that the method you like to test can be tested in isolation.

And with the Undetectable side effect covered we end the I can't get this class into a test harness chapter of WEWLC. Hope you enjoyed reading. Drop a line in the comments for feedback, or ideas.