Posted
Posted 1/20/2010 10:17:28 PM
When I started playing with Visual Studio 2008, I liked the Tests feature, which enabled me to write unit tests from within the IDE. Finally I didn't need NUnit or any of those other third-party tools. I don't like third parties. However, I never really saw the advantage in tests until my stint at A Major Insurance Provider, which was all about Enterprise practices and what-not. They showed me how they do their tests and over time, I began to like the idea. MV6 even had 150 unit tests.
Recently I discovered the Code Coverage feature of Visual Studio 2010. For every overload of every method of every class, it tells me what percent of my code is covered by my tests. Here I was thinking I was finally doing the right thing and being all Enterprisey, and along comes another analysis feature I never considered. So I ran it against my new KC Architecture and the results were disappointing.
I thought I had pretty decent code coverage, but the results say otherwise. Almost all of my constructors and destructors had 0% coverage; along with a bunch of helper methods. Luckily, this gave me an opportunity to revisit my initial design and I realized alot of things could be static, thus obsoleting the constructors and destructors entirely. Obviously, none of my UI Event Handlers had coverage. Who thinks about unit tests on the presentation layer?
Even on my Business layer, where most of my logics live, I found tons of cases I hadn't considered tests for. For example, my error logger has four Write() overloads, and I only had tests for one of them. Even then, I only had tests for a couple of execution paths. Additionally, I've been using the Visual Studio Code Analysis feature, which tells me to validate parameters prior to using them; and I hadn't written any tests that involved testing for null or other invalid parameters. VS2010 actually accounts for these items. So much more useful than the VS2005 most .NET shops are using.
So I sat down and started adding Tests. Before I knew it, I had doubled the number of tests in the KC Architecture. Of course, I tend to throw many scenarios into a single test and debug issues with the message overload (i.e. Assert.IsTrue(result, "Failed on record "+i.ToString());); but I'm sure I could easily double or even triple the number again by breaking the tests into more discrete tests like the real Enterprisey people do.
I'm learning. I'm still a code cowboy; but I'm moving into more of an Enterprise mindset. Slowly but surely. I honestly don't see why we have to be Enterprisey Developers to build Enterprisey products. I was once told that I delivered more than an Enterprisey College Graduate delivered in a whole year. I like being the guy that does that.