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
- Anonymous
August 17, 2006
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 - Anonymous
August 17, 2006
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. - Anonymous
August 18, 2006
Not bad Mark!
Maybe I should try to attend anyway :) - Anonymous
August 18, 2006
The comment has been removed - Anonymous
August 18, 2006
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 :) - Anonymous
August 27, 2006
The recent discussion spawned by my former post has prompted me to write this entry about test... - Anonymous
October 06, 2006
The week after speaking at TechEd , I'll be giving a talk at .NET Days 2006 in Århus. In this talk ,