Claudio Lassala's Blog

As it turns out, I get a lot of great feedback regarding my posts around improving productivity. That to me is great, since this is a topic I feel very strong about, and I’m very passionate about it too. So I guess I’ll just keep doing it.  🙂

Today I was reading ScottGu’s "useful links" post (you don’t read Scott’s post? Shame on you…),  and one of his links was to this post by John W Powell, with 10 tips to boost productivity. I’m glad to see that I’ve been using pretty much almost all of those tips (just one exception), even though in some cases I use or do something slightly different:

• For Build "solution" I use F6 (instead of Ctrl+Shift+B), and for Build "current project" I use Shift+F6, instead of whatever the default is. Notice that F6 and Shift+F6 are the default keyboard bindings in C#.
• For things such as creating auto-implemented properties, or doing refactoring, I use CodeRush/RefactorPro! (I think I’ve already said that many times in this blog, right?).
• Instead of the recently released PowerCommands for VS 2008, I’ve been using Cool Commands for quite sometime now. CoolCommands has pretty much all the things provided by PowerCommands, and more (for instance, there’s a "Find in Solution Explorer" option that I use a LOT, and I can’t find anything similar in either PowerCommands or VS. It’s unfortunate that the author of CoolCommands hasn’t updated it for VS 2008, but it still can be used regardless.
• I do NOT let VS generate unit test code for me. As Derik Whitaker commented, "…if you allow test to be generated you may not fully understand the intent of the test.  Making it almost useless.". I agree with that.
• For mocking dependencies, I’ve chosen to use TypeMock. At the time I was evaluating mock frameworks, TypeMock was the one that seemed to be a better fit for me, and I’ve been happy with it.
• For data-driven tests, I’m not using a SQL Server database. I don’t like using SQL for this because if a developer just gets latest in source code and tries to run tests, everything would fail until the developer sets up his SQL database (unless the code is pointing to a server on the network, which I don’t like because then the developer couldn’t get any work done if not connected to the network). Instead, I’m using XML as the data repository. We have here a DAL that works against XML files, so it’s easy for us to create test data, put it in XML files, and put those in source control, which allows the developer to get latest and run tests immediately, besides being quicker to execute then going against a fat SQL Server DB. Granted, some people may say "if it touches the file system, it is not a unit test", so we also have the option to build the XML files as resources into the test DLL and our DAL will still use it, so there’s no file system touching going on if we want to.   😉

Also, reading through John’s post’s comments, somebody mentioned SonicFileFinder, which I had never heard of before. I’ve obviously decided to check it out, and I’m loving it!! I’ll actually have another post related to that tool and the other ones I used around that area of productivity.