On Thu, 9 Dec 2004 08:52:29 +0900, Florian Gross <flgr / ccan.de> wrote:
> Eric Hodel wrote:
> 
> 
> 
> > On 08 Dec 2004, at 13:12, Nicholas Van Weerdenburg wrote:
> >> Immutability also speaks to this- it's an interface contract that says
> >> "read-only", limiting side effects. Having experienced the beauty of
> >> making objects immutable and watching the   exceptions flare was a
> >> epiphany for me in Java development.
> >
> > I've used unit tests for this more that immutability.  Your same
> > euphoric state can be had with a solid, comprehensive set of unit
> > tests.  (Not to say that immutability can't help.)
> 
> I agree heavily with this. Specification by testing is a great way of
> ensuring that things work. Note that you can also state what things
> should *not* be allowed which can be just as important as testing that
> things are allowed and work correctly.
> 
> Unit testing in general leads you to decoupled components that you can
> swap out easily with Mocks (which means that in the real code you will
> be able to replace them with similar Objects that use the same
> interface) for ensuring that interfaces are used correctly. I'd like to
> recommend the "Test-driven development by example" book -- it explains
> well how to enforce code quality via tests because it uses tests to
> state what should be done before it is done. Whether it does always make
> sense to do that is another factor, but it is certainly an interesting
> way of looking at Unit Testing.
> 
> Another point I'd like to address is integrating specification and
> documentation. I'm doing this by embedding simple test cases into the
> documentation in the style of sample code. I can extract those and
> verify that the samples in the documentations still make sense easily.
> 
> Personally, I would also like to see a way of testing whether a given
> Object implements a contract (here: passes a suite of unit tests) -- I
> think that would be useful for multi method dispatch. (Called method
> overloading in the C++/Java world.)
> 
> Unit testing and how they can be integrated into development is a very
> interesting topic. I think they can be used for much more than they
> usually are.
> 
> 

I never though of actually including tests into documentation until I
read you mentioning it a week or two ago. It sounds like a great idea.

Test-driven Development By Example is a great book- especially the
second half. Tests as a continual design pressure to produce good
modular and decoupled code, along with the associated concept of
design as emergent behaviour, are probably the coolest software
development concepts I've encountered since design patterns in 1994. I
wasn't sold on TDD until Beck's book made me see the light of it's
impact on design. Plus seeing design emerge in reverse- evolving
bottom-up from code- gave me a much deeper insight into top-down
design.

I still  have a conceptual gap extending it to design at the macro
level (high-level interfaces and coupling) but I can intuitively see
how that might evolve well as emergent design from the design
influence of unit testing. I think I might have a natural inclination
to top-down design, which makes me overly fond of Java-type
interfaces.

Still, how far emergent design can extend into a large system, as well
as how well large, normal-talent teams can collaborate well and
produce a good overall, consistent emergent design, are questions I
think are far from being answered. Especially when considering legacy
code, frameworks, and component libraries.  Also, I feel that imposing
contracts to pressure existing designs into successful refactorings is
a powerful technique.

Regards,
Nick