The simple fix for the nunit problem was to find someone with nunit already installed, and copy the binaries across onto my machine, everything works fine.
PS oh and load nunit.core.dll and nunit.framework.dll into the GAC using gacutil.exe
Monday, June 27, 2005
Saturday, June 25, 2005
Beta 2 woes
Well, it's been another interesting week at the bleeding edge of technology.
I discovered a problem with one of the third party controls we were using that caused events to fire in a different order to what we were expecting. This issue only occurred on my laptop, and just to prove it wasn't hardware, I ran it on a VPC on my laptop, and it worked as expected. After much searching and gnashing of teeth, I decided that a reformat was in order. As discussed earlier, I have had some issues with the upgrade from beta 1 to beta 2 of visual studio 2005, and figured that it could well be some framework issue, especially since the third party component used .net 1.0, and we were developing for .net 2.0 beta 2. I figured it would also give me the advantage of being the only one in the office with a completely clean install of visual studio 2005 beta 2.
So after half a day of re-installing my system, I finally am back to a place where I can develop. The biggest issue however is that I can't install nunit because the installer won't run unless it sees the .Net 2.0 framework beta 1. As I have mentioned earlier, I'm a bit of a unit test fanatic, and without it I feel crippled. My first thought was, grab the source and compile it under vs 2005 beta 2. No such luck, bits of it compile such as the core nunit framework, but not the actual nunit GUI.
Oh well, I guess I'll just keep limping along until the guys at nunit release a new version.
I discovered a problem with one of the third party controls we were using that caused events to fire in a different order to what we were expecting. This issue only occurred on my laptop, and just to prove it wasn't hardware, I ran it on a VPC on my laptop, and it worked as expected. After much searching and gnashing of teeth, I decided that a reformat was in order. As discussed earlier, I have had some issues with the upgrade from beta 1 to beta 2 of visual studio 2005, and figured that it could well be some framework issue, especially since the third party component used .net 1.0, and we were developing for .net 2.0 beta 2. I figured it would also give me the advantage of being the only one in the office with a completely clean install of visual studio 2005 beta 2.
So after half a day of re-installing my system, I finally am back to a place where I can develop. The biggest issue however is that I can't install nunit because the installer won't run unless it sees the .Net 2.0 framework beta 1. As I have mentioned earlier, I'm a bit of a unit test fanatic, and without it I feel crippled. My first thought was, grab the source and compile it under vs 2005 beta 2. No such luck, bits of it compile such as the core nunit framework, but not the actual nunit GUI.
Oh well, I guess I'll just keep limping along until the guys at nunit release a new version.
Saturday, June 11, 2005
The beauty of unit tests
Small confession, I only started writing unit tests a couple of years ago, but since then I find myself becoming more and more obsessed with unit tests. The development manager at the company I am currently contracted to has called me a “unit test evangelist”. Why have I become so fanatical in such a short period of time? I guess being interested in the whole development cycle I can see the huge benefits of code that has been properly unit tested. I’d like to list what I see as some of the advantages, in no particular order, and certainly not exhaustive.
- coverage: it is important that whenever a piece of code is written that the underlying logic is tested as soon as possible, and in isolation from the rest of the system.
- Confidence: If a class has been adequately unit tested, then anyone using that class can have a certain level of confidence in using that class.
- Demonstration: When the writer of a class writes unit tests against that class, the unit tests can be used by another developer to understand how the class is supposed (and not supposed in the case of negative unit tests) to be used.
- Shorter System Test: As I’ve mentioned before, the system test phase of the development cycle is the most unpredictable phase of the entire development cycle. If bugs are found by the developer in unit tests, they will never make it to system test.
- Refactoring: in todays “agile” world, refactoring is how a lot of companies enhance their software, but it can lead to bugs if the existing system is not understood properly. If a project has adequate unit test coverage, then any false assumptions made by the developer refactoring will be picked up immediately by the unit tests and will force the developer to understand that bit of the system before continuing.
- Performance analysis: A good set of unit tests can be used as a starting point for performance profiling. I have actually heard of one company that had the tradition that every Friday, all developers would stop what they were doing and concentrate all their efforts on improving the performance of their five slowest unit tests. Even if you don’t do this, you can at least see where your performance problems may lie.
I hear a lot of developers complaining that it’s too much effort to set everything up to a point where their classes can be unit tested. It can be a bit of an effort in some cases if say you’re working with data layer classes that talk to a database, however, it just requires a bit of thought when you start the project, and a lot of the setup work can potentially be re-used in the main application. I have yet to see any case where putting in the extra effort has not paid off. The only exception I can really think of is that retro-fitting unit tests to a piece of existing software can be more pain than it’s worth, however, this shouldn’t be an excuse not to start. My recommendation would be to make the decision that any new piece of functionality should be fully unit tested.
What I would like to do is over the course of the next few weeks I’ll write up a few articles about getting started with unit tests, and focus on a few different options available. If you have already been convinced by more most eloquent argument and want to get started right away, then here are some links to see you on your way.
For .Net developers, there is nunit.
For Java developers there is JUnit, and
For C++ developers, there is C++ Unit
There is even a TSQLUnit for unit testing your Transact SQL.
- coverage: it is important that whenever a piece of code is written that the underlying logic is tested as soon as possible, and in isolation from the rest of the system.
- Confidence: If a class has been adequately unit tested, then anyone using that class can have a certain level of confidence in using that class.
- Demonstration: When the writer of a class writes unit tests against that class, the unit tests can be used by another developer to understand how the class is supposed (and not supposed in the case of negative unit tests) to be used.
- Shorter System Test: As I’ve mentioned before, the system test phase of the development cycle is the most unpredictable phase of the entire development cycle. If bugs are found by the developer in unit tests, they will never make it to system test.
- Refactoring: in todays “agile” world, refactoring is how a lot of companies enhance their software, but it can lead to bugs if the existing system is not understood properly. If a project has adequate unit test coverage, then any false assumptions made by the developer refactoring will be picked up immediately by the unit tests and will force the developer to understand that bit of the system before continuing.
- Performance analysis: A good set of unit tests can be used as a starting point for performance profiling. I have actually heard of one company that had the tradition that every Friday, all developers would stop what they were doing and concentrate all their efforts on improving the performance of their five slowest unit tests. Even if you don’t do this, you can at least see where your performance problems may lie.
I hear a lot of developers complaining that it’s too much effort to set everything up to a point where their classes can be unit tested. It can be a bit of an effort in some cases if say you’re working with data layer classes that talk to a database, however, it just requires a bit of thought when you start the project, and a lot of the setup work can potentially be re-used in the main application. I have yet to see any case where putting in the extra effort has not paid off. The only exception I can really think of is that retro-fitting unit tests to a piece of existing software can be more pain than it’s worth, however, this shouldn’t be an excuse not to start. My recommendation would be to make the decision that any new piece of functionality should be fully unit tested.
What I would like to do is over the course of the next few weeks I’ll write up a few articles about getting started with unit tests, and focus on a few different options available. If you have already been convinced by more most eloquent argument and want to get started right away, then here are some links to see you on your way.
For .Net developers, there is nunit.
For Java developers there is JUnit, and
For C++ developers, there is C++ Unit
There is even a TSQLUnit for unit testing your Transact SQL.
Beta tools
Sometimes I wonder exactly what I have to offer to the development community, I am just a developer the same as thousands of other developers out there, and rather than just add to the blog noise out there, if I don’t feel I have anything new to offer I’d rather not say anything. However, the one thing I am doing that not a lot of developers are doing at the moment, is writing a commercial application using Whidbey (visual studio 2005) and Yukon (sql server 2005). Most developers I know can’t really find the time to do much more than download the beta’s and have a short play before they go back to visual studio 2003 and sql server 2000. So I’ll share some of my experiences using the beta tools. I’ll start the ball rolling by talking about my recent experience upgrading from Visual studio beta1 to beta 2.
The team lead had done the hard yards initially, and was raving how smoothly the upgrade went, as far as code goes, there were a few minor things that needed around dictionaries etc…, but nothing significant. So when it was my turn to upgrade, I thought the process would be relatively smooth. So I started uninstalling stuff… first uninstall our software, then infragistics, then uninstall all the individual components of visual studio, run the cleanup tool (see here for details on what's involved), then uninstall all the components of sql server, as well as the sql server express instance for our software etc…. so by early afternoon, I was ready to start installing things.
Installing vs2005 beta2 was a very long process, so don’t expect to do this in 10 minutes. It’s good to see they have now included sql Mobile in the default install. There was an error at the end installing sql express, but I knew I would have to install our own instance later anyway, so I pushed on regardless. Installed infragistics, then went on to install our product which should have installed the sql instance. It didn’t, so after looking around in the registry we found that the uninstall of the sql instance hadn’t cleaned up the registry. Deleted manually, and attempted again, this time the sql instance install ran, but came up with a fatal error "Service 'SQL Server (instancename)' (MSSQL$instancename) could not be
installed. Verify that you have sufficient privileges to install
system services". I knew I was an administrator on my own machine (what developer isn't), so hit mailing lists and news groups. There were people quite willing to offer advice, but, especially on the sql down under news group, but when fellow Readify employee Greg Low suggested that re-formatting looked like the only option, I started to get a bit worried. However with a bit of patience and some help from one of my work collegues (actually the guy who writes the installer) we managed to figure out that the uninstaller for the sql instance had not removed the service for the named instance of sql server we were using. So hack around in the registry a bit more, and finally the we are up and running. In total 2 days to upgrade from beta 1 to beta 2. everything else seems to be going relatively well, it is a true testament to microsofts commitment that we are able to develop commercial software on there beta tools, but I will make just 1 criticism..... please make error messages more informative, if the error had've said "Cannot install service, an existing service with the same name already exists", I could have saved a day of pain.
The team lead had done the hard yards initially, and was raving how smoothly the upgrade went, as far as code goes, there were a few minor things that needed around dictionaries etc…, but nothing significant. So when it was my turn to upgrade, I thought the process would be relatively smooth. So I started uninstalling stuff… first uninstall our software, then infragistics, then uninstall all the individual components of visual studio, run the cleanup tool (see here for details on what's involved), then uninstall all the components of sql server, as well as the sql server express instance for our software etc…. so by early afternoon, I was ready to start installing things.
Installing vs2005 beta2 was a very long process, so don’t expect to do this in 10 minutes. It’s good to see they have now included sql Mobile in the default install. There was an error at the end installing sql express, but I knew I would have to install our own instance later anyway, so I pushed on regardless. Installed infragistics, then went on to install our product which should have installed the sql instance. It didn’t, so after looking around in the registry we found that the uninstall of the sql instance hadn’t cleaned up the registry. Deleted manually, and attempted again, this time the sql instance install ran, but came up with a fatal error "Service 'SQL Server (instancename)' (MSSQL$instancename) could not be
installed. Verify that you have sufficient privileges to install
system services". I knew I was an administrator on my own machine (what developer isn't), so hit mailing lists and news groups. There were people quite willing to offer advice, but, especially on the sql down under news group, but when fellow Readify employee Greg Low suggested that re-formatting looked like the only option, I started to get a bit worried. However with a bit of patience and some help from one of my work collegues (actually the guy who writes the installer) we managed to figure out that the uninstaller for the sql instance had not removed the service for the named instance of sql server we were using. So hack around in the registry a bit more, and finally the we are up and running. In total 2 days to upgrade from beta 1 to beta 2. everything else seems to be going relatively well, it is a true testament to microsofts commitment that we are able to develop commercial software on there beta tools, but I will make just 1 criticism..... please make error messages more informative, if the error had've said "Cannot install service, an existing service with the same name already exists", I could have saved a day of pain.
Subscribe to:
Posts (Atom)
Posts
