Beige Sunshine

At one of the recent WAN Parties, there was some discussion on testing. Some items came up that really got me thinking about why the last 2 years has sold me on testing. From memory, I’m going to go over my thoughts on some of the comments.

It’s hard to write tests first. How did you learn?

Well, I didn’t have a choice. I learned TDD by taking a job as a junior looking for some mentorship. My first two projects were:

1. Get every old app we supported (~ 24) into a build script and onto our CI server
2. Write a small make work app, but do it completely via TDD.

Me and my coworkers had done some pairing and I had written some tests with people, but I always had someone to lean on so it was kind of easy.

However, once I started out on my own, building a system from the ground up and having no idea where I wanted the design to go? That’s when things got difficult. I remember spending literally an entire afternoon writing a single test. One. I don’t even know if I finished. I just remember knowing Point A and Point B and having no idea which path to take between the two.

Of course, as my boss would come and check in on me he would say "That’s good… but why can’t it look like this"? He’d sit down and write a few lines and suddenly I’d feel like a total moron.

The point of the story is: It takes work. It takes writing tests and realizing their crap and continuing on writing more. Don’t expect your first foray into true TDD to be easy, and don’t expect to do it well. However, I can guarantee you that if you stick with it, it _will_ become second nature.

Also, if you can get one, find yourself a mentor to help you. It will help immensely.

How do I know what I should be testing?

I’m inclined to say "Pretty much everything". I’m not a coverage nazi, though we do have some guidelines and goals around it in our shop. However, there’s just code that it doesn’t make sense to test. Like a value object made up entirely of autoprops. I’m pretty sure I know how that thing’s going to work.

Don’t tests force your design?

It seems like many people feel that because everyone has their brilliant idea of what the design of the system is going to be, that they will write tests that will suit their perceived design. For me this is true, but the true power of it is that it shows you ahead of time where your design has flaws.

Yes, I usually have a path that I think I’m going to take when I start writing a test. However, often times before I’m done a set of tests for a feature, I end up changing my mind. The thing about writing the tests first is that it shows you where your design has flaws and where it’s going to cause you pain. If it’s painful for me to write a test then it’s probably going to be a pain in the ass to write and maintain. Pain in writing tests usually signals that you’re trying to do too much at once, often you’re trying to break SRP.

In the end, you’re not only testing your code. You’re also testing your design.

I hear all this propaganda over and over, but how do you know?

For me, I have two projects that I currently work on. One with tests and one without. The one without tests was started before I learned about TDD (though I’m currently trying to begin adding tests, it’s very difficult to retrofit). As well, the one without TDD uses ruby. I heard someone say at the WAN Party the other night that Static Languages and their compilers are just a set of implicit tests. After using a dynamic language I can totally agree.

Anyway, I always find myself trying to find excuses to do something else than my non-TDD project. Why? Because I’m scared to do anything with it. Since I have no tests, I have spent (literally) countless hours fixing bugs only to have them come back into play the next time I fix another bug. I have no way of telling whether what I’m fixing is breaking something else that depends on it. Personally, I think that had I just bitten the bullet a year ago and started putting the tests ever just around the bugs I was currently fixing that I would be well ahead of where I am today on that project.

I’m starting to notice a trend here….

I agree. The funny part I’ve always thought about testing is that as someone learning it, you don’t really see the benefits. In fact, in most cases, the benefits don’t ever fully show themselves until you’ve been working on a project for a long time, or even better, need to come back to it.

Maybe you’re at the opposite end of the spectrum. You’re not skeptical of the claims, you’re curious. Maybe you’re curious like I was 2 years ago because making any changes to an old project is like pulling teeth. Or maybe your current project has hit a standstill because bugs keep creeping in and every change introduces two new ones.

My Story (in a nutshell)

I graduated from University in 2004. I had been working for an Oil and Gas company doing some development part time during the 3 years prior. After graduating I took my first job as a software developer in a small (2 developers, about 6 hardware/network/whatever guys, plus admin staff) company. I was taught to develop in ways I always somewhat questioned. After a while I started to read up on things. The only article that still stands out in my mind that I read was Martin Fowler’s article on Dependency Injection. I know I read some on the Open Closed Principle. And none of it made sense to me. I had too many stumbling blocks in my way:

• I didn’t learn anything in my Computer Science Degree except algorithms and some cool hardware stuff
• My current ‘mentor’ didn’t understand these things either
• I knew I had problems, but I couldn’t even define them even though I was reading about the solutions to my problems

Then I got lucky. I went looking for jobs because I knew there was a better way and I told everyone I interviewed with that. Then I was finally told at one interview that they knew exactly what I was feeling because they had just gone through that pain. They also told me that they had the answers I was looking for.

I took that job and it was the best thing I ever did.

It gave me the things I needed:

• People who understood where I was coming from
• A requirement to learn every day
• Mentorship

I truly believe that the easiest and best way to learn is to have someone with you guiding you in the right direction while also forcing you to go out on your own. I can understand people skepticism, I once had it. But then I got sick of fixing the same thing over and over. I realize that this is getting long so I’ll just end with another personal note: If I hadn’t taken that job and learned what I have over the last two years, I would no longer be in software.

The short story is, Testing saved my career.

So I’ve been using rubicant for a while personally, but never on anything beyond my own projects and not for anything big. After reading Ayende’s post about building Rhino Mocks with PSake, I wondered if rubicant could so something similar, so I decided to port his build script.

Of course, I didn’t have a generate assembly info method, so I basically took Oren’s and ported it as well (sorry Oren, I’ll take it out if you want). At the same time, I took the opportunity to remove the dependency on configatron from rubicant as well. It just seemed like overkill to require configatron when it really wasn’t buying me much.

In the end, I came up with this, which on the whole I don’t think looks too bad. I personally like it better, but I’ve been on a bit of a vendetta against PowerShell scripts since I wrote my first one some time ago. I don’t know why, but the friction it gave me over writing ruby scripts just always rubbed me the wrong way.

require 'fileutils'
require 'rake'
require 'rubicant'
include Rubicant

base_dir  = File.expand_path(".")
lib_dir = "#{base_dir}\\SharedLibs"
build_dir = "#{base_dir}\\build"
buildartifacts_dir = "#{build_dir}\\"
sln_file = "#{base_dir}\\Rhino.Mocks-vs2008.sln"
version = "3.6.0.0"
human_readable_version = "3.6"
tools_dir = "#{base_dir}\\Tools"
release_dir = "#{base_dir}\\Release"
upload_category = "Rhino-Mocks"
upload_script = "C:\\Builds\\Upload\\PublishBuild.build"
mbunit_dir = "#{tools_dir}\\MbUnit"

task :default => :release do
end

task :clean do
  rm_rf buildartifacts_dir
  rm_rf release_dir
end

task :init => :clean do

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks\\Properties",
		:title => "Rhino Mocks #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks.Tests\\Properties",
		:title => "Rhino Mocks Tests #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks Test #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks.Tests.Model\\Properties",
		:title => "Rhino Mocks Tests #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks Test Model #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	mkdir release_dir
	mkdir buildartifacts_dir

	cp_r "#{mbunit_dir}\\.", build_dir
end

task :compile => :init do
	MsBuildRunner.new(:properties => { :OutDir => buildartifacts_dir },
					  :project_file => sln_file).run
end

task :test => :compile do
	begin
		MbUnitRunner.new(:mbunit_dir => build_dir,
					 :test_files => ["Rhino.Mocks.Tests.dll"],
					 :report_type => 'Html').run
	rescue
		fail 'Error: Failed to execute tests'
	end
end

task :merge do
	begin
		rm_f "#{build_dir}\\Rhino.Mocks.Partial.dll"
		mv "#{build_dir}\\Rhino.Mocks.dll", "#{build_dir}\\Rhino.Mocks.Partial.dll"

		sh "#{tools_dir}\\IlMerge.exe " +
			"#{build_dir}\\Rhino.Mocks.Partial.dll " +
			"#{build_dir}\\Castle.DynamicProxy2.dll " +
			"#{build_dir}\\Castle.Core.dll " +
			"/out:#{build_dir}\\Rhino.Mocks.dll "+
			"/t:library "+
			"/keyfile:#{base_dir}\\ayende-open-source.snk " +
			"/internalize:#{base_dir}\\ilmerge.exclude"

	rescue
        fail 'Error: Failed to merge assemblies!'
	end

	puts "done merge"
end

task :release => [:test, :merge] do
	begin
		puts "Zipping files"
		sh "#{tools_dir}\\zip.exe -9 -A -j " +
			"#{release_dir}\\Rhino.Mocks-#{human_readable_version}-Build-#{ENV['ccnetnumericlabel']}.zip " +
			"#{build_dir}\\Rhino.Mocks.dll " +
			"#{build_dir}\\Rhino.Mocks.xml " +
			"license.txt " +
			"acknowledgements.txt"

	rescue
        fail 'Error: Failed to execute ZIP command'
	end
end

task :upload => :release do
	if (File.exists?(upload_script) )
		begin
			log = sh 'git log -n 1 --oneline'
			MsBuildRunner.new({:properties => { :Category => upload_category,
											   :Comment => log,
											   :File => "#{release_dir}\\Rhino.Mocks-#{human_readable_version}-Build-#{ENV['ccnetnumericlabel']}.zip" },
							   :project_file => upload_script }).run

		rescue
			fail "Error: Failed to publish build"
		end
	else
		puts "could not find upload script #{upload_script}, skipping upload"
	end
end

If you want to give this script a try (I’ve tried everything but the upload piece, which for obvious reasons I couldn’t test) just follow these steps:

1. Get a copy of the rhino mocks source.
2. Make sure you’ve got ruby installed.
3. Make sure gem is up to date: “gem update –system”
4. Add github to your gem sources: “gem sources -a http://gems.github.com”
5. Install rubicant: “gem install mendicantx-rubicant”
6. Copy the above script into a file named rakefile.rb in the rhino mocks directory.
7. Run it: “rake release”

God willing, this will work. I’ve tried it on a couple of fresh systems, but have no good way of knowing if it works beyond my machines. If you do on the offhand decide to try it, please let me know below!

You know, sometimes, you really shouldn’t test your code.

What?

Yes. You heard me. You shouldn’t test your code.

Well, let me explain that better. I recently took a course where I was paired with someone where neither one of us knew what it was that we _really_ wanted to do. We started to flush out an API for wiring up a hand rolled IOC automatically, and every time we did so, we hit a brick wall. The reason is that we kept trying to ‘test first’.

Don’t get me wrong, I am a complete advocate of test first development. HOWEVER, if you don’t know what the hell you’re doing, you can’t really test first. Being able to test first implies that you can think ahead of yourself and write something that does exactly what you know you need.

In our case, we kept wasting time trying to write tests that just didn’t work with how we NEEDED to do things. How did we solve this dilemma? We sat down and spiked out some code. Just hammered it out and got something working. Now, let me tell you, we wrote some pretty damn horrible and untestable (except via black box testing) code. However, what we did gain was an insight into the process and steps we needed to take to accomplish our task.

However! We didn’t keep that working code we spiked out. Once we had a spiked set of code and a solid idea of what it was we needed, we were able to test and rewrite the code we’d spiked in a much better, tested and well designed manner that would have taken forever if we’d just kept banging our heads against the wall.

To reiterate:

1) TDD with no idea what we were trying to accomplish = 3 hours wasted.

2) Spiking out some code, getting our heads around the steps needed, wiping it clean and restarting the TDD approach with an idea of what we needed to do = less than 1 hour to completion.

Remember, testing first doesn’t mean you should beat your head against a wall just to write a test before writing some code. Sometimes, in order to write a test, you need to write some code first. I guess some people will write tests afterwards, I personally prefer to rewrite, as I find I spend just as much time fixing the code when retrofitting tests as I do just rewriting it out.

In the end, you just need to remember that even if you’re doing TDD, you shouldn’t be afraid to spike out code. It’s the best way to learn and give yourself some direction.

I just added an MsBuild task for rubicant tonight. I’m not very familiar with the command line options for MsBuild so some of these could probably be improved a bit, but until I know more I will leave them as they are.

The MsBuild Task is used to create tasks which will use MsBuild. This should help with people who need to build WPF applications (since MsBuild is the only way right now), or (fingers crossed) migrate from MsBuild.

The MsBuild Task is used as follows:

   1: MsBuildTask.new(:task_name => :dependencies) do |msb|

   2:   msb.no_autoresponse

   3:   msb.target

   4:   msb.logger

   5:   msb.distributed_logger

   6:   msb.console_logger_parameters

   7:   msb.validate

   8:   msb.verbosity

   9:   msb.no_console_logger

  10:   msb.max_cpu_count

  11:   msb.ignore_project_extensions

  12:   msb.file_logger

  13:   msb.distributed_file_logger

  14:   msb.node_reuse

  15:   msb.properties

  16:   msb.file_logger_parameters

  17:   msb.project_file

  18: end

Each of setters matches a command line option for MsBuild. For more information on what each one does, please view the documentation at http://msdn.microsoft.com/en-us/library/ms164311.aspx.

Values that can only be set (for example, /noautoresponse) can be set to true (set) or nil (unset).

Values, such as /property that take a list of option settings, must be passed a hash where the keys are the options and the values are the option values. For example, to set the output directory and Warning Level for a csproj compile, you could use:

   1: MsBuildTask.new(:compile) do |msb|

   2:   msb.properties = { :OutputDir => ".\\Output", :WarningLevel => 2 }

   3:   msb.project_file = ".\\Project1\\project.csproj"

   4: end

As of yet, I haven’t added an MsBuild helper to help create this function. I will probably get this done fairly shortly.

The mbunit function in rubicant has been changed from just a function to a complete task.

MbUnitTask

Behind the scenes, what MBUnitTask does is copies over the minimal necessary support files from an MBUnit directory and then runs the tests. It uses the MBUnit Console Runner and is only tested with MBUnit 2.4. It is used as follows:

   1: MbUnitTask.new(:task_name => :dependencies) do |mbunit|

   2:   mbunit.mbunit_dir = "/path/to/mbunit" 

   3:   mbunit.test_dir = "/path/to/testing/dir" 

   4:   mbunit.test_files = ["tests.dll"]

   5:   mbunit.assembly_path => FileList["/assemblies/to/include/*.dll"],

   6:   mbunit.report_folder => "sets /rf:",

   7:   mbunit.report_name_format => "sets /rnf:",

   8:   mbunit.report_type => "sets /rt:",

   9:   mbunit.show_reports => "sets /sr:",

  10:   mbunit.transform => "sets /tr:",

  11:   mbunit.filter_category => "sets /fc:",

  12:   mbunit.exclude_category => "sets /ec:",

  13:   mbunit.filter_author => "sets /fa:",

  14:   mbunit.filter_type => "sets /ft:",

  15:   mbunit.filter_namespace => "sets /fn:",

  16:   mbunit.verbose => "sets /v{optionvalue}",

  17:   mbunit.shadow_copy => "sets /sc:" }

  18: end

Mbunit helper

   1: mbunit(name, dependencies, mbunit_dir, test_dir, test_files, opts={}) 

Usage is:

   1: mbunit(:run_tests, [:compile_tests], "/path/to/mbunit/dlls",

   2:         FileList["/test/dlls/test.dll"],

   3:         {:working_dir => "/dir/to/run/tests/in",

   4:          :assembly_path => FileList["/assemblies/to/include/*.dll"],

   5:          :report_folder => "sets /rf:",

   6:          :report_name_format => "sets /rnf:",

   7:          :report_type => "sets /rt:",

   8:          :show_reports => "sets /sr:",

   9:          :transform => "sets /tr:",

  10:          :filter_category => "sets /fc:",

  11:          :exclude_category => "sets /ec:",

  12:          :filter_author => "sets /fa:",

  13:          :filter_type => "sets /ft:",

  14:          :filter_namespace => "sets /fn:",

  15:          :verbose => "sets /v{optionvalue}",

  16:          :shadow_copy => "sets /sc:" } 

Runs the tests in test_files in the test_dir with the dlls from mbunit_dir using the options in opts.

For more information on the command line arguments for the mbunit console runner, please visit: http://docs.mbunit.com/help/html/gettingstarted/MbUnitConsoleRunner.htm

Since I already had rubicant building as a gem, it made sense to make it available as a gem. I have moved the project to github and it is now located at: http://github.com/mendicantx/rubicant/

In addition, you can also install rubicant via gem:

   1: gem sources -a http://gems.github.com

   2: sudo gem install mendicantx-rubicant

You should only ever have to run the gem sources command once. This adds github to your sources of remote gems. From what I understand, there’s a ton of great projects there.

Now you don’t have an excuse to try it out!

Don’t forget to check out Part 1 and Part 2.

Rubicant basically has 4 main parts, as mentioned in the first part of this series. They are as follows:

The CscTask

The CscTask is used for compiling C# files. It’s usage is like:

   1: CscTask.new(:task_name => :dependencies) do |csc|

   2:   csc.target = 'library'

   3:   csc.references = FileList["libs\*.dll"]

   4:   csc.out = "hello_world.exe"

   5:   csc.debug = "full"

   6:   csc.files = FileList["src/**/*.cs"]

   7: end

target: Any target that the csc compiler takes (exe, winexe, library, etc)

references: The list of assemblies that are referenced during compilation

out: The output filename

debug: if this is set(to anything), the compiler will be passed /debug:full to create debugging information

files: The list of files to be compiled

CscTask also has a shortcut that can be accessed as follows:

   1: csc(name, dependencies, opts)

   2:  

   3: ex:

   4: csc :name, [:dependencies], { :target => 'library',

   5:                               :references = FileList["libs\*.dll"],

   6:                               :out = "hello_world.exe",

   7:                               :debug = "full",

   8:                               :files = FileList["src/**/*.cs"] }

The MBUnit Helper

The MBUnit helper is used to run tests using mbunit v2. It is used as follows:

   1: mbunit(mbunit_dir, test_dir, test_files, opts={})

   2:  

   3: ex:

   4: mbunit("/path/to/mbunit/dlls",

   5:         FileList["/test/dlls/test.dll"],

   6:         {:working_dir => "/dir/to/run/tests/in",

   7:          :assembly_path => FileList["/assemblies/to/include/*.dll"],

   8:          :report_folder => "sets /rf:",

   9:          :report_name_format => "sets /rnf:",

  10:          :report_type => "sets /rt:",

  11:          :show_reports => "sets /sr:",

  12:          :transform => "sets /tr:",

  13:          :filter_category => "sets /fc:",

  14:          :exclude_category => "sets /ec:",

  15:          :filter_author => "sets /fa:",

  16:          :filter_type => "sets /ft:",

  17:          :filter_namespace => "sets /fn:",

  18:          :verbose => "sets /v{optionvalue}",

  19:          :shadow_copy => "sets /sc:" }

For a complete listing of the mbunit command line options, please visit http://docs.mbunit.com/help/html/gettingstarted/MbUnitConsoleRunner.htm.

This runs the tests in test_files in the test_dir with the dlls from mbunit_dir using the options in opts. Currently, this will physically copy the minimum required mbunit dlls and mbunit.cons.exe to the test dir, run the tests and then remove the files.

The CopyFiles Task

The copy files task will copy files from one directory to another, while maintaining the folder structure.

   1: CopyFiles.new(:name) do |cf|

   2:   cf.base_dir = "/some/dir"

   3:   cf.file_globs = ["**/somefiles/*.cs", **/otherfiles/*.cs"]

   4:   cf.target_dir = "/another/dir"

   5:   cf.excludes = ["AssemblyInfo.cs"]

   6: end

base_dir: The base directory to start copying files from

file_globs: The globs of files to be copied from base_dir

target_dir: The target directory to place the files in

excludes: (Optional) list of files to be excluded from the copy.

The Expand Template File Task

Usage is:

   1: expand_template(template, output_file)

This will read in the file specified by template and expand it out and write it to the location of output_file.

WARNING: I am fairly certain that the only reason this is working right now for me is because I use configatron, which is accessed as a singleton. It is entirely possible that variables declared in your build script will not be accessible during template expansion. I will be testing this in the near future, however.

Framework Selection

Currently, only the .Net 2.0 and .Net 3.5 frameworks are configured. .Net 3.5 is the selection by default. However, you can choose which framework you want to use by adding framework={framework} in the build line. For example:

   1: rake deploy_local framework=net20

This will run the deploy_local task in the default rakefile using the .Net 2.0 framework.

Valid framework values are:

net20 – .Net 2.0

net35 - .Net 3.5

These frameworks are discovered using the registry, so you shouldn’t have to put in the location of your csc.exe file.

What else?

Well, that’s about all it really does right now. The rest is just built in rake and ruby goodness. I would like to add msbuild support for those that are building WPF apps. I would also like to add some nunit support, as well as some support for other things like easy creation of assemblyinfo.cs files and possibly some deployment tasks for iis7. Who knows. We’ll see how I like things and if I really take to using this (I think I will).

Update: There is also a Part 1 and a Part 3.

Alright, so here is a sample build script for rubicant. First you will have to get rubicant installed. To do that, you need to get the source from https://rubicant.googlecode.com/svn/trunk/. I believe the username is rubicant-read-only.

In the root directory type:

   1: E:\projects\rubicant>rake gem

   2: (in E:/projects/rubicant)

   3: c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake/gempackagetask.rb:13:Warning:

   4:  Gem::manage_gems is deprecated and will be removed on or after March 2009.

   5: mkdir -p pkg

   6: WARNING:  no rubyforge_project specified

   7: WARNING:  RDoc will not be generated (has_rdoc == false)

   8: WARNING:  deprecated autorequire specified

   9:   Successfully built RubyGem

  10:   Name: Rubicant

  11:   Version: 0.0.1

  12:   File: Rubicant-0.0.1.gem

  13: mv Rubicant-0.0.1.gem pkg/Rubicant-0.0.1.gem

  14:  

  15: E:\projects\rubicant>

Now you’ve got the gem built, you just need to install it:

   1: E:\projects\rubicant>gem install pkg\Rubicant-0.0.1.gem

   2: Successfully installed Rubicant-0.0.1

   3: 1 gem installed

   4:  

   5: E:\projects\rubicant>

There. Now for a test application. Suppose we’ve got 3 projects that make up a console app. The UI, the Engine (I KNOW) and the Tests. They look like:

For now, let’s ignore the internal workings and focus on building it.

The build script looks like this:

   1: require 'rubicant'

   2: require 'configatron'

   3: include Rubicant

   4:  

   5: BASE_DIR = File.expand_path(".")

   6: SRC_DIR = "#{BASE_DIR}/src"

   7: SRC_APP_DIR = "#{SRC_DIR}/app"

   8: SRC_TEST_DIR = "#{SRC_DIR}/test"

   9: CONFIG_DIR = "#{BASE_DIR}/config"

  10: BUILD_DIR = "#{BASE_DIR}/build"

  11: DEPLOY_DIR = "#{BASE_DIR}/deploy"

  12: TOOLS_DIR = "#{BASE_DIR}/tools"

  13: MBUNIT_DIR = "#{TOOLS_DIR}/mbunit"

  14: RHINO_DIR = "#{TOOLS_DIR}/rhino"

  15:  

  16: UI_SOURCES = FileList["#{SRC_APP_DIR}/Rubicant.Test.App.UI/**/*.cs"]

  17: ENGINE_SOURCES = FileList["#{SRC_APP_DIR}/Rubicant.Test.App.Engine/**/*.cs"]

  18: TEST_SOURCES = FileList["#{SRC_TEST_DIR}/**/*.cs"]

  19:  

  20: #### Build Initialization

  21: task :initialize_build do

  22:     rm_rf BUILD_DIR if File.exists?(BUILD_DIR)

  23:     mkdir_p BUILD_DIR

  24:     rm_rf DEPLOY_DIR if File.exists?(DEPLOY_DIR)

  25:     mkdir_p DEPLOY_DIR

  26: end

  27:  

  28: #### Loading Properties

  29: task :load_local_properties do

  30:     configatron.configure_from_yaml("local.properties.yml")

  31: end

  32:  

  33: task :load_test_properties do

  34:     configatron.configure_from_yaml("test.properties.yml")

  35: end

  36:  

  37: #### Deployment Targets

  38: task :deploy_local => [:load_local_properties, :deploy]

  39:  

  40: task :deploy_test => [:load_test_properties, :deploy]

  41:  

  42: task :deploy => [:test, :expand_app_config] do

  43:     cp FileList["#{BUILD_DIR}/{hello.exe,engine.dll}"], DEPLOY_DIR

  44: end

  45:  

  46:  

  47: #### Compile Targets

  48: csc :compile, [:initialize_build, :compile_engine], {:files => UI_SOURCES,

  49:                                                      :target => "exe",

  50:                                                      :out => "#{BUILD_DIR}/hello.exe",

  51:                                                      :references => FileList["#{BUILD_DIR}/*.dll"] }

  52:                 

  53: csc :compile_engine, [], {:files => ENGINE_SOURCES,

  54:                           :target => "library",

  55:                           :out => "#{BUILD_DIR}/engine.dll"}

  56:                 

  57: #### Testing Targets                

  58: task :test => [:compile_tests, :run_tests]

  59:  

  60: csc :compile_tests, [:compile], {:files => TEST_SOURCES,

  61:                                           :target => "library",

  62:                                           :out => "#{BUILD_DIR}/tests.dll",

  63:                                           :references => FileList["#{BUILD_DIR}/**/*.{dll,exe}", "#{RHINO_DIR}/*.dll", "#{MBUNIT_DIR}/*.dll"]}

  64:  

  65: task :run_tests do

  66:     mbunit(MBUNIT_DIR, BUILD_DIR, FileList["#{BUILD_DIR}/tests.dll"], {:assembly_path => FileList["#{BUILD_DIR}/engine.dll", "#{RHINO_DIR}/*.dll"].to_a})

  67: end

  68:  

  69:  

  70: #### App.config expansion

  71: task :expand_app_config do

  72:     expand_template "#{CONFIG_DIR}/App.Config.template", "#{DEPLOY_DIR}/hello.exe.config"

  73: end

The point of this build file is to be able to churn out two different builds based on two different sets of properties. This is based off of my builds that I do at work where we need to deploy and test in a test environment before going into production. It would be as simple as adding a production.properties.yml and a deploy_production target to simulate this fully in this script.

So basically, we call deploy_test (or deploy_local), which in turn loads the test properties, and then the deploy task.

Deploy calls the test task, which builds the app, builds the tests, runs the tests. If any tests fail, the build will fail here, making sure we don’t deploy any code that doesn’t pass tests.

Finally, we expand our app.config in a way suitable for the environment we’re going into.

Finally, run the executable to see that it worked!

   1: E:\projects\Rubicant.Test.App>deploy\hello.exe

   2: Hello, World! (Test Version)

   3:  

   4: E:\projects\Rubicant.Test.App>

You can download the source from http://blog.beigesunshine.com/wp-content/uploads/2009/01/rubicanttestapp.zip and try it out for yourself. The default rakefile goes to an exe and an assembly. You can also run both deploy_local and deploy_test and create a single exe file by using rake -f rakefile_single_exe.rb deploy_local.

Coming up, a post on some of the specifics of rubicant.

Update: Don’t forget to check out Part 2 and Part 3.

In previous posts I have mentioned that I think that there might be a better way to automate builds than NAnt. I also mentioned that I had looked at a few of them and been mostly underwhelmed. I’ve spent a large amount of time building a process for builds that works well for me and none of them seemed to erase my pains.

I also mentioned that I would be working on some items that may even drive some content to this blog, among other things. Today, I introduce the fruits of my labour.

Please note that this is NOT recommended for any sort of production environment. It is currently at best a way to try out Rake on .Net projects.

What is rubicant?

rubicant is my own personal set of tasks that sit on top of rake, a rubyish interpretation of make. I’ve used ruby for some scripting in the past, and also used rake in a rails app that I developed. I felt that the combination of both would alleviate some of the pains that I (and I’m pretty sure I’m not alone here) feel when I use NAnt.

I was admittedly scared to even try building my own set of tasks, and actually didn’t even know where to start. I kept rolling the idea around. One day I was going to start doing it now. Then the next I wasn’t. As a father of young children my spare time is very limited and very few and far between, especially for something that would demand so much of it.

And then the I started coming across others experimenting with exactly what I was talking about. First it was a post by Dave Laribee, as well as another post in his comments. And now as I read over them again, I’m seeing that there’s more people feeling like I do. I started to google and found some great posts by Jay Fields and to a lesser extent one by Martin Fowler.

Anyway, in my looking it seemed like no one had actually put out a reusable library that anyone could just pick up and automatically compile a project within 5 minutes.

And thus, with some much needed inspiration from the above sources, rubicant was born.

What isn’t rubicant?

Well written for one thing. Take a look at my tests and they’re enough to make someone blow a gasket (I kid, I LOVE his twitter rants) I started writing them thinking I knew what I was doing and let me clear something up for you. At the time, I had a greatly misguided view on BDD/Specification testing. Either way, it’s still got my code covered and has helped to drive out some of the design, especially when loading framework information.

Another thing it is not is a complete solution. I had 4 goals in functionality that I wanted. They were:

1. Build C# code
2. Test C# code (with MBUnit)
3. Copy selected files in a meaningful hierarchy
4. Template expansion using configatron to allow for easy configuration swapping.

Why rubicant?

First off, automated builds are the only thing that I feel I truly have a grasp on. I feel comfortable enough in myself and my process that I could come up with something useful. I don’t think of myself as a guru, but I do know that I have a set of build scripts at work that are robust and involved while trying to stay (somewhat simple). In other words, I don’t consider myself a guru, but I do feel I have a grasp on the subject.

I was also feeling too much pain with NAnt. As well, I didn’t feel that any of the other solutions out there really felt like what I was looking for. I was also looking for a learning project in ruby. I wanted to try driving out a design via testing using ruby. A lot of things. Either way, I felt like I wanted to do something for myself, but that also might provide some sort of benefit to the community, even if it just ended up as a failed attempt. In a sentence: I wanted to try and provide SOMETHING back to a community that I feel has given me so much.

Even if this ends in failure, it’s been exactly the experience that I’ve wanted thus far, and though I’m sure I’m in for some rough waters ahead, I think that it will continue to drive me to learn, improve and better myself. Okay, so there is definitely some selfishness there, but hopefully you can forgive me in the name of Continuous Improvement, even if it’s my own.

How do I get it? How do I use it?

Well, if you want to get it, you can go to the project site on google code and download the source. There are instructions there on how to install it. As for how to use it… stay tuned for a sample project and build file. Hopefully very soon.

Update: Don’t forget to check out Part 2 and Part 3.

I told myself I would do a whole lot more writing than I’ve been doing. I’ve even got ideas of things I would like to write on! Honest. Anyway, between Christmas, kids and a project (that’s related to this blog!) that I’ve been working on, I haven’t had a lot of time to sit down and focus.

So to my whopping 0 subscribers, just you wait! There will be content. Oh yes. There will be content.