Help Beta

This framework is a new implementation based on techniques used successfully over a decade. We're confident you will find it useful, but we'd like to know just how. Please drop us a few notes so that we can benefit from your experience.

Write us when you download the framework. We'd like to know why you are interested, what lead you here, what platforms are important to you and what you are using now (if anything).

Write us again when you run your first test. We'd like to know what was easy and what wasn't. We'd also like to know what kind of fixtures you used and how you hooked them into your application. Send us some test reports if you can.

Then be sure to write us when you deploy this to your whole team (or choose not to). We'd like to know how long this took and what surprised you along the way. Now is a good time to think about contributing case histories for publication on our site. Please mention if this is remotely possible. We'll help make it painless and worthwile.

Finally, write us if you have any trouble. We can't promise to solve every problem but we will sure explain what we intended of the framework and we may be able to do things we didn't intend too. We wont know unless you ask.

Watch this space for special notices of, to and by beta testers.

I have a question and then a long explanation for why this question is important to me.

The question is what is the relationship between the fixtures and the code that they support testing. I took a look at the code for the calculator example. The implementation for the calculator was mixed in with the code to support testing it (the fixture). Indeed, the Calculator class is a subclass of ColumnFixture and contains the HP35 class (which contains 95% of the calculator implementation).

One reason for my question is because we could have multiple interfaces for using/testing the HP35 class and this might mean that it would be awkward (or worse) to have it as an inline class in calculator (is that the right term?).

But a bigger part of my question really comes from my traditional thinking that the test code must be separate from the code under test. This may very well be an artifact of my long experience with testing being done ex post facto and in a separate silo. But i am intrigued by the way you are mixing in the test code and the product code.

In my writing (e.g. ... bility_PNSQC.pdf) i have encouraged the creation of test interfaces to allow for more direct access between test and product code, but here you seem just to mix it all together. Indeed, these concerns were part of what motivated my contribution to the AgileTestingModel. Now i'm not sure if it means what i meant it to mean.

-- BretPettichord

I have another idea. One of the great things about this framework is how easy it is to create tests. But this website doesn't demonstrate this well. It would be neat if there were a sandbox, where visitors could use the wiki technology to change or modify tests and then run them. Would it work to create a page on the portland patterns repository that links to a runner here?

-- BretPettichord


Last edited November 18, 2002
Return to WelcomeVisitors