Update on building .NET

Sometime back now I posted an article on building .NET and dependency management.

I have come to learn that there are several ways. Here are my favorites.

  1. Build your own maven plugin to build .NET projects. Package 3rd party products as zips and put them in maven. Write a plugin that reads solution and project files and calls MSBuild with the appropriate flags.  Advantage, maximum flexibility.  Disadvantage, lots of effort.
  2. Use the existing maven-dotnet-plugin.  Advantage, does a lot for you including various types of test and coverage systems, plus it can run sonar.  Disadvantage, Hard to get it to work on complex silverlight projects. In fact hard full stop.  The docs are not great.
  3. Use NuGet.  Advantages, it has .NET pedigree and Microsoft Backing.  Adoption amongst .net developers is probably an easier sell than a java utility.  Disadvantages, Very early days for the project, as yet unproven.
  4. Finally npanday.  Advantages, nice integration with Visual Studio.  Disadvantages, very hard to get it to work with silverlight.  Impossible in fact as MS have kindly removed the command line baml compile utility.
So in summary.  There are ways to do this now.  There is hope for .NET dependency management!
Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Test anti-patterns project, contributors wanted!

Take a look at the following test class.  I deliberately wrote this poor quality test, so that I could show how easy it is to re-factor it to a better one. I was driven by having seen lots of such poor tests and to be honest I don’t want to see another of its ilk again. I might write a test like this myself, but I would never leave it like this. Its part finished. Its littered with cut and paste, poorly named methods and hard coded values. It’s a bit like a surgeon performing an operation and not sewing up the hole! I would go as far as to say that leaving tests in this state is unprofessional. There is no excuse as most of the lessons of good naming and code re-use have been written down a long time back. More lately in Clean Code by Robert C. Martin. I just don’t understand why people still write rubbish like this! Possibly because they are allowed to get away with it! Note that the test provides 100% coverage of the implementation class, but its not enough to stop there.

Have a read over the class, and then move on to read the steps to re-factor to better patterns. I have several designs here that focus on the setup stage of a test. As your tests get more complex you will find the patterns here support ever increasing complexity. In an Agile project you might move from one system to the next as the requirements ramp up. Then once you see where I am heading, I lay down a challenge.

Test anti-patterns project, contributors wanted!

If you have a Test Anti-Pattern that you would like to showcase. Check out my code from gitHub, add the new example and examples of how to re-factor the code. Blog it to your own blog with a reference to this page, or drop a comment. If we get enough I will setup a page with an index to all the blogs.

The code can be forked out with git from gitHub http://github.com/mhgit/TerribleJavaTestingMadeGood. It should be an easy start. Its a full maven project with a small dependency set and maven site reports already built in for test coverage. Its fully open source with the Apache 2.0 license. Once you have your new example, tell me about it by adding a comment to this page, and following the git forking instructions for making a git pull available.

Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Refactoring to Google Collections – ImmutableList for simple code

I was reading this excellent post on google collections by Sune Simonsen and decided to re-factor some code of mine. I have an immutable results object used in a multi-threaded application. I wanted to feel the difference using the google ImmutableList. My existing class provides immutability in a very similar way to the google classes. Static methods are used to instantiate the object. An array is used to back a list collection. Defensive copies are made to protect the immutability of the object. Moving to google collections is easy and makes my implementation simple whilst reducing test overhead.

Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)