Speaking At TechEd, Barcelona

TechEd Developers 2006 is in Barcelona in November, and I have had the honor of being invited to deliver a talk on unit testing best practices using Visual Studio 2005 Team System. Since breakout sessions at Microsoft conferences are always one hour and fifteen minutes, it’s going to be a level 300 talk, which will (hopefully) provide some guidelines and tips and tricks for a broad range of developers.

Don’t expect me to talk much about dependency injection, mock objects and similar advanced topics at the session, but if you’d like to discuss particular topics with me, I’d be happy to help if I can.

TechEd is a great opportunity to network and learn new stuff, so I can only urge you to attend if you can!

Comments (7)

  1. Maybe you can dedicate a couple of minutes on naming guidelines for tests. Like whether or not the suffix Fixture should be used or suffix Test instead. How you should name the methods and so on and so forth

  2. ploeh says:

    Hi Gabriel

    Thank you for your suggestion – I will certainly consider it.

    However, naming guidelines for tests is not a subject where I have a firm opinion, so I’d rather talk about topics where I can rationalize my advice. I can talk for many hours about unit testing, so for this talk, I prefer to focus on topics where I have clear arguments for the advice I’m giving, since I feel that advice is most valuable when there’s a clear rationale behind it.

  3. Kost says:

    Not bad Mark!

    Maybe I should try to attend anyway 🙂

  4. Some suggestions:

    – testing web services

    – testing http handlers/modules

    Basically I had a lof of problems defining and creating a test list for service oriented applications. External systems calling my web services and me calling external web services was a pain in the butt to test.

  5. ploeh says:

    Hi Gabriel

    No wonder your service-related tests were painful to perform – they are not unit tests at all, but integration tests 🙂

    Application testing should occur on many different levels, unit testing being the lowest and full system tests being the highest. The higher up in the stack you get, the more difficult the tests become to develop and maintain. This is one of the main benefits of unit tests: Because they are so low-level, they are (potentially) very easy to create and maintain. This is achieved by paying the cost of isolation, and when you test a service using a client (or vice versa), you don’t test a unit in isolation.

    For service-oriented development, I always recommend developing the service using the Remote Façade pattern: The service should really be a library you can unit test, and the web service is just a very thin layer (façade) on top of this library. Vice versa, clients should be treated just like any other data access interface, so you can stub out the real service proxy.

    I’m sorry I can’t be more forthcoming about your suggestions, but this one falls a little besides the topic of the talk. It’s not that I don’t want to talk about this, but since I only have 1 hour and 15 minutes, I have to stick very closely to the subject. If you are going to be at TechEd, I’ll be happy to elaborate on this topic after the talk (or we can continue the discussion here).

    In any case, I appreciate the suggestions, so keep them coming if you have more 🙂

  6. ploeh blog says:

    The recent discussion spawned by my former post has prompted me to write this entry about test…

  7. ploeh blog says:

    The week after speaking at TechEd , I’ll be giving a talk at .NET Days 2006 in Århus. In this talk ,