The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Using TDD to develop a framework

I wonder if TDD can be used to develop a framework? Is it any different,at all,then developing a business class library
Friday, April 27, 2007
What kind of framework? Internal or one published to the world like J2EE? Internally it's great because you evolve it story by story and it's framework that does what you need in response to the needs of your app.

For an external framework I don't think it would work unless you went through a couple of development cycles to flesh it out.
son of parnas
Friday, April 27, 2007
I think TDD is an excellent approach to building a framework.

I'm using these definitions, btw:

Library: Your code calls it
Framework: The framework calls you

Aside from the usual benefits of TDD, when working on a framework, TDD will force you to make the framework testable. This is a HUGE advantage for those who will use your framework later.
Chris Tavares Send private email
Friday, April 27, 2007
You can build to unit tests.  But if you try to develop a cohesive framework without planning the whole thing out in advance, it won't be very good.

Design first.  Code second.  Utilize tests during your coding.  If you find you need to make a change, redesign to ensure that your framework remains cohesive.

Friday, April 27, 2007
I've designed several frameworks and used light-TDD in each case. The first step was to write an ideal client for my framework. This served as both a use case in my design process and as a test case during development. As I went along, finding new features that I needed, I added new clients that exercised those features. Again, this allowed me to evaluate my design decisions and to test the framework against the new use case.

In the end I had a small collection of example framework clients, each somewhat like a simple Hello World program, that could be used to illustrate the use of the framework, demonstrate the framework to supervisors and test the framework in on-going development. Similarly, as bug reports came in against production uses of the frameworks, I would construct example clients to trigger the bug, which would then be used to demonstrate that the bug had been fixed in later builds.

In order to support this kind of testing while developing the framework I had to add several kinds of features to the framework and its API:

  1. run-time logging which could be switched and off
      without a re-compile.

  2. API calls that validated internal state of the
      framework, so that I could run stress tests on
      portions of the framework.

  3. routines to dump the internal state of parts of
      the framework to the screen, so that I could
      examine it in the log after an error.

  4. tags on most data structures so that, if an
      uninitialized or previously freed data structure
      were passed to a framework API, I could detect it
      immediately and abort with a usefull error message.

  5. runtime flags that could disable parts of the
      framework to simplify testing of other parts.

This was a pretty successful method of developing the frameworks. I was able to compress about 9 man-months of effort into less than 6 on one occasion, and the resulting frameworks were both closely tailored to the actual production requirements and still reasonably flexible as new requirements arrived.
Jeff Dutky Send private email
Friday, April 27, 2007
Another side-effect is that some tests will be mimicking a developer using your framework which can lead to a cleaner set of external APIs. I've noticed that many framework designers get lost thinking about their issues and the features they think would be fun/useful. They don't think to deeply about the developer working with their framework though, who will have different concerns.

If the framework designer has his say, then the developer probably won't find it to beautiful. You can negate this by writing tests so you can get in the developer's head. Even better, if you build it in parallel with a developer writing an application on top of it, you two can work out the kinks.
Saturday, April 28, 2007
Build an application.
Build another one.
Start on a third, and notice you have bits in common.
Refactor, include unit tests, and call it a framework.

If you're particularly adventurous, when you're doing the first application you can put some code in a library, along with its unit tests. (Operating system boilerplate such as WinMain() and your message pump are often identical in many applications, so can be stuck in a framework safely. Other code is sometimes a little harder to know when it will be reused.) But you still need the second and third application using the framework, in order to be sure that your framework isn't overloaded with application-specific code. And then the refactoring may include moving some code out of the framework.

Building the framework by progressively refactoring multiple applications helps prove that you are going to need it, because you already have customers actually using it (where "it" refers to whatever block of code you're considering adding to the framework).

Wednesday, May 02, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz