Reading Eli‘s post, got me thinking about this, too.
I think that, if the team is too small, it can’t be both agile in development and in support.
How do you satisfy your customers? Immediately satisfy the ones with problems with the existing product or rapidly deliver new features to those waiting for them?
If you can afford a team for training and writing documentation, I think that team can handle support in a reasonable way. except when support involves correcting a bug. Then you are back to developers.
But the problem with developers not being in touch with support issues is that they might loose touch with the real world usage of their products.
If support is mostly about help users with their doubts and not about solving problems in the product itself, the newest trend is to develop and support a community of users that support themselves.
And you can always use TypeMock™ to deliver bug-free products.
So far, he came up with a basic mock framework and running environment, but we would like to take it further and integrate it with any unit testing framework.
Eli Lopian from TypeMock™, has an article on CodeProject about the disadvantages of design for testability and how to use TypeMock™ to remove these disadvantages while keep the advantages of unit testing.
I have to say that I agree with Eli: design for testability is BAD. It exposes more that it needs just for the purpose of testing and might increase the number of classes and interfaces that need to be implemented, tested and maintained. It also increases the attack surface of the system being built.
I am a firm believer in code for testability. Using tools like Visual Studio and TypeMock™ you can easily test private members of a class. You can do almost the same you would do in design for testability without exposing what doesn’t need to be exposed and go even further by factoring your code in smaller methods easier to test.
There is a good set of articles about Unit Test Patterns in the TypeMock™ site:
- Unit-Test Patterns for .NET – Part I
This article looks at patterns in unit testing and describes the main patterns found in tested .NET code. It also describes the problems with each pattern.
- Unit Test Patterns for .NET – Part II – TypeMocks
Programmers who have incorporated unit testing into their development process already know its advantages: cleaner code, courage to refactor, and higher speed. But even the most die-hard unit testers can falter when faced with testing a class that relies on system state for its behavior. This article looks at the TypeMock pattern that can help you solve these problems.
- Unit-Test Patterns for .NET – Part III – Natural TypeMocks™
In this series, unit-test patterns and the advantages that it brings have been discussed. Although there is great power in using TypeMocks, there are times when the reflective API can falter when refactoring code. This article will look at how to test the interaction between classes using Natural Type Mocks to solve these problems.
Just let me know to see if I can accommodate it on my geekSpeak.
I’ve been asked what I use for code syntax coloring in my blog.
I use Windows Live Writer with VSPaste from Douglas Stockwell.
Microsoft has announced the date for PDC08. Will this be a keeper?