This week I have made two discoveries that really has made me happy. They are not news by any means but I has been like they have clicked into place in my brain.

The first one is surrounding the subject of testing in agile projects, which a lot of people seems to have opinions about - but I haven’t heard anyone go: “Do like this!”. I suspect that it has to do with current testing process are rigid on many companies and there is a reluctancy towards changing the quality assurance process. Also the amount of regression testing increases for each sprint.

We have had some trouble to get testing to work smoothly in our projects, but we are closing in on a solution. I do not claim to have the answerer or not even know much about the theories behind this big subject - but this works fine...

Avega is starting up a corporate blog and have asked me to post some posts there. Sounds great so I have just posted in some items from www.marcusoft.net to my “Avega”-alias.

http://blog.avegagroup.se will not be live in a few weeks though, so keep cool until you can read me in … stereo. ;)

A few interesting questions arose:

• How will Google tackle the indexing. Will a search for “marcus hammarberg” yield a hit at the Avega-blog before www.marcusoft.net?
• How to use Windows Live Write (which I have fallen in love with) with SubText.NET (the Avega blog engine of choice)? Luckily there is a simple solution here.

Here are some of the latest pictures of Albert (and one that includes Elin). He’s sick right now but the mood is still on top.

I found a feature that I thought was a bug in Visual Studio… If you have ReSharper (4.0 in my case) installed, it shows your missing references directly in the .config file.

Of course, there are limitations to this—secondary references cannot be resolved, but it is still a great help. Unfortunately, it confused me for a while, thinking it was a bug in the config editor of Visual Studio. But I take that one on me.

Let me first be very clear - I’m not a RegExp-guy. I find them quite hard to understand at times and often take refuge in .NET code.

Also, I was very surprised to not find any hits for the search of “RegExp even numbers” - I thought that I would find numerous examples.

But after reading a bit here, I learned enough to create my first naïve regular expression - a regular expression to allow only even numbers:

^\d*?((0)|(2)|(4)|(6)|(8))$

Again, my apologies for being a newbie on this… but hey, it works.

I also found this resource very useful for trying out my expression.

Regular expressions are very powerful, but “with great power comes great responsibilities”… - that is, they are often hard to understand.

Thanks, Fredrik S, for the links.

OK - sometimes it just to confess - I took a chance, or didn’t know what I was doing - call it what you want.

In TFS Build-scripts there are a much nicer way of calling MSTest than the Exec-task as I suggested. There is already a task for it, called TestToolsTask. With this task you can much easier reach all the properties you need. And it even contains some undocumented features such as the TestContainer-property.

Here is my updated version on how to call the task:

<TestToolsTask
  TestContainers="$(BinariesRoot)\Debug\Company.Service.Host.Test.Integration.dll"
  BuildFlavor="%(ConfigurationToBuild.FlavorToBuild)"
  Platform="%(ConfigurationToBuild.PlatformToBuild)"
  PublishServer="$(TeamFoundationServerUrl)"
  PublishBuild="$(BuildNumber)"
  PathToResultsFilesRoot="$(TestResultsRoot)\..\IntegrationTestResults"
  TeamProject="Betalningsplattformen2"
  ContinueOnError="true"
/>

[UPDATED, see this]

I have created a task that runs some unit tests in a certain DLL and the publish the result to a TFS service. We use this task in our TFS MSBuild script in order to execute some integration tests in the last step of the build process. In order to get some value from the integration tests the solution needs to be deployed, for example.

The most tricky parts of figuring this out was:

• The path to MSTest.exe - as it turns out there are a environment variable to the root of the Visual Studio Tools - %VS90COMNTOOLS%. And via that we can reach MSTest.exe with%VS90COMNTOOLS%\\..\IDE\MSTest.exe
• To publish a build you need the buildId to send to the publishbuild-parameter of MSTest. It can easily be obtained from the TFSBuild parameter $(BuildNumber)

So here you are - my task to run...

I had a quite strange experience today. I did a presentation about unit testing for another project. Nothing strange there. But the thing was recorded (via LiveMeeting, worked great after some initial confusing surrounding the mic) and then put out on the developer portal of my customer.

So later on I heard my lame jokes echoing through out the nearby workstation. Excruciating painfully… it’s just not funny the forth time you hear your own jokes…

Quite cool experience though. I like doing presentations.

In my current project we have reached a very good code coverage percent (98,7 %, yes we are proud) - but we are aspiring to take it a step further.

We are now constructing a series of integration test, used to run through the actual production code an verifying that everything works as expected.

Said and done - I implemented a few test that did that. Soon though some questions and problems arose;

• Integration test assumes that something is released and the that tests are executed against that release
• You don’t want the integration test to be executed when a developer is running the unit test on his development machine inside Visual Studio.

When looking around on the net it seems that many people are missing the Category-attribute from NUnit in MSTest. That looked like a very nice way to solve the problem but...

We have for several days now been chasing a bug for a couple of days now. Very, very annoying…

Here is how it goes:

We have a unit test on that calls a stored procedure in Oracle, using ODP.NET. On our local machine (and also on the test server) everything works fine. But when the build script is running the unit test, an out-parameter of the DATE-datatype was always returned as NULL.

This was so strange since it’s the same code against the same database instance. The difference was that it was another account, the TFS Build Service Account, that was running the tests.

The solution was to configure the regional settings for the TFS Build Service Account to use Swedish (in our case) Regional Settings as the default user profile.

[UPDATED] That checkbox should be checked!

So good to solve this. Thanks to the anonymous “client dude” that...