[self-interest] UnitTests

[Michael Latta]

Obscure code can be written in any language, even Cobol.  The larger a system is the more obscure it will feel to any new reader as the amount they know is x% of the total.

The value of tests is that you do not need to know the complete set of consequences, the tests reveal that, and encourage experimentation.  That is the theory.  In practice the cost of 100% test coverage is very high and becomes a deterrent to change.  The best balance we have found is sufficient system tests to ensure no unintended user visible changes result in mission critical aspects, where the cost of test maintenance is worth the value.

One system I work on is huge, has several million lines of code, and has a run-time object graph measured in 100,000s of objects.  Some aspects of this system are well documented as of 8 years ago, but there has of course been drift.  Even with current documentation there were large parts of the core system that have not been successfully modified by other than the original authors.  I like the idea of executable tests as documentation because when the "documentation" gets out of date, the test breaks!  Something similar for overview and high level structure and relationships would be pretty cool as well.  Combining a dynamic object system with active constraint enforcement could produce a very agile and robust system.

Michael




On Jan 11, 2011, at 7:23 PM, Jason Grossman wrote:

> Ioke (http://ioke.org) follows Self (deliberately) in being very expressive and dynamic, and fairly lenient with scope (e.g. traits are used extensively), and unit tests are not mandatory.  But the base library itself is full of unit tests, and is exceptionally well documented.  I suspect that this approach is the best solution to some of the problems of powerful systems like Self.  I understand that the Smalltalk community has (by and large) traditionally had the view that the source code is the documentation, and I think that's been a mistake.  Specifically, it's been one of the things that's led to this impression that you can make a mess easily in Smalltalk.  Seems to me that it's very easy to make your code opaque even if it's well structured, e.g. by giving slots names which make sense to you but not to other people.  Similarly, in a large system it's hard to tell people which parts of the enormous Smalltalk object hierarchy your method is relying on using code alone.  Explicit
> documentation (explicit but not mandatory) is much less likely to be opaque.  (Or so I imagine.  I've never added anything significant to a really large system.)
> 
> I may just be venting my frustration here.  I recently spent hours trying to understand the code for the Smalltalk WikiWorks server before giving up.  SOME of it is exceptionally clear, but not the bits I wanted to change.
> 
> This is not a plug for using Ioke instead, by the way.  For one thing, it runs too slowly to be useful.
> 
> Jason
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>