Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Dev Blog - Johan Danforth

I'm Johan Danforth and this is my dev blog - a mix of .NET, ASP.NET, Rest, Azure and some other random coding stuff.

  • [.NET 2.0] Visual Studio Tools for Office

    I've been attending a few VS.NET 2005 seminars now, and I'm quite curious about the stuff you can do with Visual Studio Tools for Office. It is interesting to use Word and Excel as clients because users know how to use these tools and the Actions Pane is the perfect place for simple controls to help the user fill in and submit a form or similar.

    If you're interested in stuff like this, check out the things available at the home page.

  • The bluetooth worm is spreading

    We used to joke about this a couple of years ago, we all knew it would happen, and now it seems to be spreading - the bluetooth worms. Why anyone would walk around and have his or her mobile set on discoverable mode, I don't know. Even less choose to install something without being sure what it is :)

    You can find out more from any of the bigger anti-virus webbys out there, like F-Secure.

  • TDD: Who is testing the tester?

    I posted earlier about the book "Test Driven Development in Microsoft.NET, and I liked that book very much, it's not that. I've been using JUnit and NUnit in smaller and larger projects, but I've never used it in the way you often see it described in books written by the TDD-gurus and the way it is described in this book. I can't help it, but it feels kind of stupid to create a test the first thing you do, just to see the compile fail, write enough code to make the test compile then see the test fail, then add "dummy code" so that the first test pass but the rest fails... you know the drill :) 

    Then there is this thing about testing every class in every layer in a system or application. Writing that many tests manually would probably make me go nuts, and the quality of the test methods would most certainly drop after a while. The value of unit testing only gets as good as your test code, right? I've seen some tools that try to create test code for you automatically, but I've not been that impressed.

    The way I've been using JUnit is that I've created tests against the facade layer or (web) service layer and then added the tests as a target in my ANT build scripts. That has worked out pretty well. If someone in the team changed something in the database or some other layer, the test fail and you (most of the time) get a pretty good tracktrace which shows where the problem lies. Even so, writing really good tests for that layer only (with scripts for setting up database tables and populate with test data), can take quite some time. Of course, it depends on what kind of system you're building and if the service/facade interface takes complex parameters which makes it hard to test properly, but imagine writing tests for the service layer, business layer, utilties and data access layer too. You would probably spend more time writing test code than anything else :)

    Some would probably say TDD, XP and Refactoring is something invented by a few smart guys so they would get longer contracts and get to spend more time coding and less time documenting ;) I just wish some of my customers believed in those methods when I was a consultant :p

    Personally I'm going to continue to use parts of TDD, XP and refactoring that I like because I think these methods (not that refactoring is a dev method but anyway) have got some really good bits in them. Besides, I love to read the books about them.

  • Some old articles from CodeProject

    I moved or copied a couple of old ASP.NET articles I wrote from CodeProject to my blog, mainly to keep track of them. They're available under my Articles section here. Old ones, but pretty good primers for new ASP.NET developers.