Mercurial HG

~ chriseyre2000 ~ Leave a comment

This is my new favorite version control system.

I personally like to develop under the cover of a version control system.  I don’t consider professional development to be occurring unless one is being used.

Hg is great for quick refactoring developments.  It’s a distributed vcs (like git) so that the application does not enforce a centralised server.

This means that you can commit multiple changes to your local repository before pushing these up to the shared server.

You can also push changesets from developer to developer without going via a central server!

This is wonderful for collaborative development or for those developers who code on the train or plane!

This neatly solves the problems that the PVCS promotion model handles (i.e. how to check in changes without breaking the tested build).

Since you can freely clone a repository refactoring becomes a breeze.

Clone then hack away (checking in whenever it actually compiles and runs the tests).  The cloned repository can be thrown away or merged back into the master (or just your current working copy).

Sample of NUnit.Mock

~ chriseyre2000 ~ Leave a comment

using NUnit.Framework;
using NUnit.Mocks;

namespace ConsoleApplication1
{
[TestFixture]
public class Class1
{
public interface IExecutable
{
void Execute();
}

[Test]
public void ThisIsATest()
{
// This is not a good test of a mock but it shows how it works.
// The mock should be a Dependend Upon Component not the Subject Of Test
DynamicMock mockExecute = new DynamicMock(typeof(IExecutable));
mockExecute.Expect(“Execute”);
((IExecutable)mockExecute.MockInstance).Execute();
mockExecute.Verify();
}
}
}

Javadoc comments considered evil : how to use xDoc without them

~ chriseyre2000 ~ Leave a comment

I have recently moved to a new project.
This means that there is a large code-base that I need to learn quickly.

One of my starting points was to try and point a NDoc type tool at the application.
It was at this point that I found that the application was missing at least 5000 XML comments – the NDoc tools typically use the .
When I started to add them to the units that I was working on I was pointed to an article that describes javadoc style comments as now being considered evil for an internal project.
Agile projects these days use self describing names so “empty” xDoc comments don’t help.

I have suddenly realized that I can use reflection to create the “empty” xml stub file from an assembly.  This would allow me to get the documentation (that will be at least partially useful) without polluting the code with javadoc comments.

One of the things that I like xDoc tools to generate is a class hierarchy diagram.  This is great for finding the descendent’s of a class that you are modifying (this documentation is especially useful if you have code that currently does not compile).