Integrating VS 2008 unit tests with CCNET

In my current project we are using VS 2008 unit tests. We have a CI environment configured using CruiseControl.NET. When we tried to integrate the unit tests into the CI build process we found out that it does not work out of the box. The main reason was that the XSL files that ship with the current version of CCNET only supports generating build reports off VS 2005 unit test results. So I had to modify the style sheets a bit. I wrote a code project article on setting up CCNET to run the unit tests. The modified XSL files are also available for download with the article. Please find it at http://www.codeproject.com/KB/tips/VSTS2008_Tests_With_CCNET.aspx.

KeyedCollection class

If you follow a entity object based design in your applications you frequently need to maintain lists of your objects. You can use List<T> class to do that. I was using the same method until I ran code analysis on one of the projects and got the warning  for violating rule "CA1002:DoNotExposeGenericLists". The following blog post explains the background behind the rule http://blogs.msdn.com/fxcop/archive/2006/04/27/585476.aspx

A better alternative is to use the KeyedCollection <TKey, TItem> class. As the documentation states it provides an abstract base class for a collection whose keys are embedded in the values. For example you can have an Employee class that has the key EmployeeNumber as a field. In this example you want to be able to do operations on your collection class (lets say EmpleyeeCollection) based on the employee number. Since the KeyedCollection class has to know how to get a key from an item it is an abstract class. You have to derive your own class and override the GetKeyForItem method. The following blog post has a clever method to avoid creating a collection class for every object that utilizes lambda expressions http://vaultofthoughts.net/keyedcollectionlambdaexpressionway.aspx

Technorati Tags: KeyedCollection,.NET,Object Model

Working for a new place

I left the previous workplace and joined CalCey Technologies (www.calcey.com). I made the move in February. The major reason behind joining CalCey was that its a small company. All this time I was working for companies that are considered big players in Sri Lankan IT industry (hSenid, Virtusa, Eurocenter).

There are advantages working for a big company, you get a good knowledge about process and get a lot of training opportunities, traveling etc. But at the same time when the company is big its very easy to loose focus on the core business which is developing software and focus more on the other things. The obvious "other thing" here is process, add to that internal politics and bureaucracy and it can be a nightmare. Having a good process is essential to a software company but it should support the software development work not the other way round. I feel the fundamental problem with big organizations is that teams don't scale well.

Working for a small company on the other hand will give you the flexibility and the freedom the geek inside you desire. It will be easier to introduce new ideas and make changes. But sometimes you can end up with a bunch of  below average colleagues especially in Sri Lanka where people prefer to work for big companies.

There are pro's and con's in both worlds. My personal opinion is that you should start your career at a big company and work for 5-6 years then move on to a small company and after some time you can decide where you want to stay.