- Hi, all,
Michael Feathers tossed off, in a recent thread:
> hoping to see testability as a use case forAnd I'd like to encourage the group here to begin the discussion - if
> language design in my lifetime
it's not already underway elsewhere - of what that could mean. I'd
very much like to see the language that emerges from that use case -
and I'm pretty sure I'd like to use it.
For my part, I find it easiest to think about language and (other)
development tools together; that is, the implications of a testable
language I envision through their manifestations in (for notable
example) the IDE. We have some of that with JUnit integration in
Eclipse and other Java IDEs and nUnit integration into Visual Studio,
and it's great to have that, but in what ways could it be better? I
like the notion of some kind of special status for test code that
gives it access to things that might not be accessible to production
code, and an execution context that refuses to execute untested or
failing code - of course the tests need a different execution context
or code could never be tested. I am also fond of the notion of inline
tests - not in a nearby or parallel package, not in a separate class,
but right there in the code: THIS is what this function is required to
do. But I can also see that getting messy.
Michael, what do you imagine a highly testable language would look
like? How would it differ from today's languages, and what impact
would testability have on development and deployment tools? Anyone
- Well, here's a coda to this thread. Lots of good and thoughtful replies - for which thanks. I've blended a couple together and here's what I've got. By the way, I have a data structure which is document->parts->checkableAttributes, so a composite makes sense.
I've got a composite which is CheckDocument. That loads several CheckParts, each of which in turn load different CheckAttributes.
Then a call to CheckDocument.IsValid descends through all the Part checkers and attribute checkers.
In each level I loop through the checkers (the loop is in the base class), and use the "&=" operator - it works fine in C#.
Which has definitely reduced the scope of the memorized condition!
Before I started, it looked like a scary refactoring - but TDD made it not scary, pretty fast, more-or-less error-free. A joy to do really, because now the code is much better.