Blog

CI Factory 0.7 RC1 Believe it or not there has actually been a lot of work on CI Factory over the last 5 or 6 months. It may not have been public but the work was happening none the less. I posted sometime ago about how many project at my day job that we are using it on (close to 70). I have finally taken the time to merge it all back into the public codeline. I have started getting the documentation up to date as well. There is now a good introduction and a good install document. There are several new packages available, most important amongst them is Subversion. ...

nAnt Scratch I love nAnt. It can do so many things for me and I can get it to do those things for me so very quickly. I do not like to leave the IDE, I try to keep the list of reasons for my leaving it short. To help me keep that list short while still getting nAnt to pull it weight I have integrated nAnt into the IDE through the external tools feature of VS.NET. This not a brainy thing. I bet plenty of people have done it. But I don’t see many and more people should. Take a look at how I use it. First I keep a scratch file as a solution item: Scratch.build.xml. I edit this file to do repetitive tasks for me. ...

Judgement… hard to teach ctodx posted a blog entry of a discussion on teaching a team about design, specifically interface inheritance over implementation inheritance. I have to comments. I am sure that judgement can be easy to teach, maybe even in some cases objective not subjective. I think the key here is to bring unit testing into the discussion. If a criteria of good design is testability then things get a bit easier. Well almost, that statement assumes that you value unit testing and are practicing it. Well designed test subjects are much easier to test than poorly designed test subjects. To take the example of Single Responsibility Principle (SRP), a test subject with many responsibilities is much harder to test than one with fewer. This is something that the developers with out much design experience or good design judgement can feel. If they are responsible for the testing then they are likely to be more interested in learning how to make things easier to test. Ahh motivation. Now you have instilled motivation and can use that as a fulcrum marinate your team in the design principles. ...

Mocking Static Classes and Members There have been some recent posts on mocking statics. Static members that is and I remember an older post on mocking a static class. This is all do able if you use indirection. For a static member you can use a delegate to provide the indirection. I will try to keep with Steve Eichert’s example. public abstract class BaseEntity<T> { protected delegate List<T> FindAllWork(); protected static FindAllWork FindAllWorker; protected static IDatabase<T> db = new Database<T>(); public SaveObjectResponse Save() { return db.Save(this); } public bool Delete() { return db.Delete(this); } public static List<T> FindAll() { if (FindAllWorker == null) FindAllWorker = new FindAllWork(DefaultFindAllWorker); return FindAllWorker(); } protected static List<T> DefaultFindAllWorker() { return db.FindAll(); } } public abstract class MockableEntity<T> : BaseEntity<T> { public MockableEntity() { BaseEntity<T>.FindAllWorker = new BaseEntity<T>.FindAllWork(this.FindAllPassThrough); } public List<T> FindAllPassThrough() { return BaseEntity<T>.db.FindAll(); } } I don’t use dynamic mocking myself but I think that should work. If you want to state an expectation that FindAll is being called you would expect FindAllPassThrough to be called. The principle to take note of is that we are wrapping a static call in an instance call. In fact we are not changing the static interface that the client knows we are just wrapping the the work done by that static call in an instance. You can apply this principle to an entire class as well. ...

Shell Magic and Shell Extensions I had been looking for Windows Explorer like controls for some time when I came across Sky Software’s Shell MegaPack.Net. I particularly need the FileView control. They offer several other products as well: Shell MegaPack ActiveX/Shell MegaPack.Net/ EZShellExtensions.Net. They integrate well into the VS.NET IDE (all editions). I will try to get the FileView into my Doubler product shortly. I am keen to see what could be done with the EZShellExtensions.Net as well. ...

Testability: Internal State Collapse So I have started research for a book that I would like to write. I am currently looking for a metric or metric that will indicate when a design is not very testable. I came across an interesting concept, internal state collapse. This is where the input parameters are not released from the member. For example: public interface IWarehouse { bool HasInventory(InventoryItem inventoryItem, int amount); void Remove(InventoryItem inventoryItem, int amount); void Add(InventoryItem inventoryItem, int amount); } The members Add and Remove do not release amount or inventoryItem. This is known as internal state collapse. The interest here is that it is very difficult to test. Lets examine this a little closer. ...

State Based UnitTesting, or Not? I have been doing a lot of research lately on how to teach unit testing. There seem to be to basic forms: State and Interaction. In my last post I define what a unit test is in a very strict way. By that definition I can not see how state based testing is unit testing. I wanted to refer to my own examples here but gotdotnet user samples take 72 hours or so to be published so I will refer to Martin Fowler’s Mocks Aren’t Stubs. At the beginning of this article he illustrates the two approaches. For state based testing to be performed a portion of the system, more than the test subject, was needed. It was needed for the test subject simply to be used. Sniff Sniff Sniff. Do you smell that. Smells like tight coupling to me. Bugs in the warehouse class can easily cause the order unit test to fail. This fail to express much of the potential value of a unit test. Indicating were the problem is. Now we can only know that when a unit test fails that it’s a problem in either the order or warehouse classes. So why would I write a separate unit test for the warehouse class, I don’t really even feel like adding asserts to the order test to verify that the warehouse object is in the expected state. All this leads me to believe that state based testing is not a unit testing style at all. It promotes bad practices. This is not to say that it isn’t a great style for other forms of testing, just unit testing. Interaction testing on the other hand is dependent on loose coupling; same as the definition in the previous post depends on it.

The New Software Architect Have you ever heard of genetic algorithms? Codefarm is using genetic algorithms in their product Galapagos. They are marketing the software for engineering, finance, entertainment, biotechnology, and security. I have only ever seen this technology used to create circuits. It seems only a matter of time till this technology and software design patterns meet. The question is how fill they fit, how best will they work together. ...