Being Scott Densmore : Test Infection

Visual Studio Team Developer - Undocumented feature in Unit Testing

scottdensmore — Fri, 29 Apr 2005 19:25:58 GMT

During my whirl-wind tour of Whidbey I am taking the ride using VSTD (there is a joke ther somewhere <STD>). Coming from NUnit / TDD.net and VS 2003, I was used to dealing with configuration through the configuration file myassembly.dll.config. Now that I am using the tests from VS and looking at the new System.Configuration goo (tech term), I thought this feature was gone because I could not find any documentation. Boy, was I wrong.

All you have to do is create an App.config file, rename it to your assembly name .dll.conig and set the file to always be copied (click file and then look at the properties window, there is a drop down for that option), and by magic, the test runner uses this file.

Hope this helps someone out there.

Now playing: King Crimson - Fallen Angel

"You Big Dummy"

scottdensmore — Thu, 06 Jan 2005 19:04:00 GMT

Why is it that I like to make things hard on myself? I was doing some refactoring a class method ["Introduce Parameter Object"] and decided that I would just change the signature, rename the method, blah blah blah in one shot, why not, I was already there. I can just hear Fred Sanford saying "You Big Dummy", go slow, one thing at a time, follow the steps.

Actually it wasn't Fred, it was Brian, and he promptly went over to my bookshelf, grabbed my Refactoring book and hit me in the head with it.

You Get What You Pay For

scottdensmore — Thu, 18 Nov 2004 16:32:00 GMT

Brian Button was looking at some code today and saw this as a test...

adRolesProvider = null;
Assert.IsNull(adRolesProvider);

Enough said.

UPDATE:
Just to be clear... Brian didn't write the test... just found it.

ReSharper .85 is out

scottdensmore — Thu, 10 Jun 2004 02:44:00 GMT

.84 was a huge performance improvement. I am hoping that this will even be better. My question of the day… will I miss this in Whidbey?

Resharper

scottdensmore — Wed, 02 Jun 2004 21:58:00 GMT

I have been using Resharper for a while and until now I have stopped using it, but with version .83 I am very excited. Extract method is here… and it works. I am still a little upset with the loading of the solution and it seems to take a while to parse, but that aside, I am in love. I am so happy that they thought of developers like me who use the keyboard and gave me shortcuts for everything.. Now, if they would integrate unit testing into the IDE I would be thrilled… I could have Team System today. With the project we are on toady, having rename is worth any price, because it not only changes it in the code, but in the comments as well. I think everyone should try this out if they are looking for Whidbey features today.

Can I Get a Tester?

scottdensmore — Wed, 02 Jun 2004 03:30:00 GMT

What makes a good tester? I have pondered this question for a while. I love testers because the make my code so much better, and I think they are extremely fascinating creatures J. In a current project that we are working on, we have invoked the power of Unit Testing and some parts of Test Driven Development. We have about ~100 - 150 Unit Tests per assembly, and each assembly is akin to framework code. So now that we have these Unit Tests, the test cases that I see coming back from the testers seem just like our Unit Tests. I have never given this much thought before, but by doing unit testing have we raised the bar for testers? No longer can they just test all my public API’s with random data, because the unit tests cover 90% of that. So what do testers have to do now?

I am definitely not a tester, but as a developer it is in my best interest to see the test guys that I work with succeed, so I thought I would give some interesting pointers to things I have found that might be useful in this space. The writings from Brian Marick, Bret Pettichord and Lisa Crispin I find very interesting. Bret’s article Where are the Testers in XP? I think answers most of my questions. I would love to here thoughts from other testers out there on this topic so as a developer I can learn more. “Can I get a witness?” J

Why Singletons are Evil

scottdensmore — Tue, 25 May 2004 07:18:00 GMT

While I did not write this, I totally agree with it. Brian Button is probably one of the most talented people I know, and I am sure he would love your feedback.

1) Singletons frequently are used to provide a global access point for some service.
True, they do this, but at what cost? They provide a well-known point of access to some service in your application so that you don't have to pass around a reference to that service. How is that different from a global variable? (remember, globals are bad, right???) What ends up happening is that the dependencies in your design are hidden inside the code, and not visible by examining the interfaces of your classes and methods. You have to inspect the code to understand exactly what other objects your class uses. This is less clear than it could be. The urge to create something as a global to avoid passing it around is a smell in your design; it is not a feature of globals/singletons. If you examine your design more closely, you can almost always come up with a design that it is better and does not have to pass around tramp data to every object and method.

2) Singletons allow you to limit creation of your objects.
This is true, but now you are mixing two different responsibilities into the same class, which is a violation of the Single Responsibility Principle. A class should not care whether or not it is a singleton. It should be concerned with its business responsibilities only. If you want to limit the ability to instantiate some class, create a factory or builder object that encapsulates creation, and in there, limit creation as you wish. Now the responsibilities of creation are partitioned away from the responsibilities of the business entity.

3) Singletons promote tight coupling between classes
One of the underlying properties that makes code testable is that it is loosely coupled to its surroundings. This property allows you to substitute alternate implementations for collaborators during testing to achieve specific testing goals (think mock objects). Singletons tightly couple you to the exact type of the singleton object, removing the opportunity to use polymorphism to substitute an alternative. A better alternative, as discussed in the first point above, is to alter your design to allow you to pass references to objects to your classes and methods, which will reduce the coupling issues described above.

4) Singletons carry state with them that last as long as the program lasts
Persistent state is the enemy of unit testing. One of the things that makes unit testing effective is that each test has to be independent of all the others. If this is not true, then the order in which the tests run affects the outcome of the tests. This can lead to cases where tests fail when they shouldn't, and even worse, it can lead to tests that pass just because of the order in which they were run. This can hide bugs and is evil. Avoiding static variables is a good way to prevent state from being carried from test to test. Singletons, by their very nature, depend on an instance that is held in a static variable. This is an invitation for test-dependence. Avoid this by passing references to objects to your classes and methods.

I hope this explains a little more fully my opinion of the singleton pattern. I have a small collection of links I found through Google of others, including Jim Hyslop and Herb Sutter, who share this opinion. Let me know if you'd like them.

[Now Playing: Metallica - Disposable Heroes (08:17)]