Defining unit and integration

I've a rough form of this post boiling away at the back of my noggin for a little while but a post on StackOverflow and an old blog post by Roy Osherove has prompted me to finally write it.

While this goes against a previous post on this subject, I think Roy has hit the nail on the head with his definition of "unit test". Integration tests I have an issue with, but mostly as I think the bucket "integration test" is too large.

I see two types of integration tests:

Unigration Tests: Tests written as unit tests, but as a key part of what they do they hits one external resource which is under complete control of the developer. A unigration test is a fast (as it can be), consistent (with early failure with Inconclusive if the external resource does not exist), automated and repeatable test of a functional unit-of-work in the system. For example testing the individual methods in data access layer.
This differs from Roy's "integration test" in that he does not specify functional unit-of-work in the system and he allows for inconsistent tests, where as for a unigration test only allows for three states, Passed, Failed and Resource Unavailable (Inconclusive).

Pure Integration Tests: Is any test which does not fall into the above two definitions. Either as the developer does not have full control over the resource, is testing more than a single functional unit of work or requires multiple external resources.

Software dependencies and CI server

To build our suite of applications one alas must install a few things. I've love to get away from it and use something like Apache Ivy but alas I don't see that happening in the near future. Prior to installing a CI server we were managing this list of dependencies by the wonderful method of hope. Hope that someone had sent a mail indicating that a dependency exists and that everyone has read said mail. 

Hudson can't read emails and act on them in an intelligent manor so we shall have to automate it. The solution I am currently using is:
First I set up a software share with two folders, Static and Core.

Static is the MSI/other set up stuff that requires a degree of human interaction to make work. Visual Studio and Oracle drivers currently live in this folder. This remains a manual process, but requires the minimal amount of work to keep everything up to date as very few items will live in this folder.

Core is the MSI/setup files for the stuff that can be automated.

In the version control I have created a new "Environment" folder, in that is a "Build" sub folder containing a bat file which auto-installs all the core dependencies and looks somewhat like:

:: Silverlight 4

if exists "c:\DEV_SILVERLIGHT4.$$$" goto DoneSilverlight

start /wait %INSTALL_LOCATION%\Silverlight4_Tools.exe /q:a /c:"setup.exe /q /norestart"

start /wait c:\windows\system32\msiexec.exe /qb /i "%INSTALL_LOCATION%\Silverlight_4_toolkit_april_2010.msi"

echo Done > c:\DEV_SILVERLIGHT4.$$$

:DoneSilverlight

I've then created a new job on Hudson which checks out just the Environment\Build folder and executes this script. 

It is not ideal, the current solution does not support multiple slaves and finding out how to do silent installs can be a pain (luckily sites exist that help a lot) but is currently keeping our one-node Hudson server up-to-date and allowing any developer to update their machine without involving a sacrifice to the Gods Of Broken Builds.

Quickie: IKVM.NET - Logging Exceptions

The toString in Java Exceptions do not include the stack trace, the ToString in .NET Exceptions do include the stack trace. Nlog expects Exception.ToString to include the stack trace, so when logging Java exceptions either wrap with a .NET happy version or including the stack trace in the message.