Handling Support in Agile Teams

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. :D

Unit Testing in JavaScript

Bruno does a lot of JavaScript development and needs to build lots of web pages to test his code. On top of that, those tests always involve a human tester and cannot be included in automated tests (like in continuous integration).

That’s why I dared him to build a test framework for JavaScript.

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.

Any ideas?

Stop Designing for Testability (by Eli Lopian)

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.

Unit Test Patterns for .NET (from TypeMock™)

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.

I’m on geekSpeak

Or I’ll be, on January 23rd.

Here is the complete list of web casts for December 2007 and January 2008: