It recently occurred to me that we should expect an architecture "evolved" TestFirst to have a higher FractalDimension than architectures arising from less extreme processes.
Where and how does the notion of "fractal dimension" come in ?
Well, let the "boundary" of a software system be defined as the count of all methods belonging to that system (as opposed to e.g. Servlet API methods which call into the system if this is server-side code, or event dispatching code for a desktop application) which are called "first" when the system is exercised, by whatever method (unit tests or manual testing). The exact measure of the boundary varies, by this definition, according to how we test the code; but that is not a problem.
Let the "surface" of a software system be defined as the count of all methods, or the LOC count, or any reasonable measure of how much complexity the boundary "contains". We can also think of the "position" of any atomic element of code in a space with a suitable number of dimensions as being determined by the functionality that this element of code covers.
Now, if we draw the "shape" of a software system developed entirely without disciplined (non-manual) testing, BigBallOfMud-style, we should see a more or less round blob. Points on the software's interface (the blob's outer boundary) are the only ones from which the functionality within the blob ever gets exercised.
Systems with a more formal architecture, possibly with regression and unit tests, but without TestFirst, might be expected to look like smaller blobs with connecting "tissue"; this organization has a slightly higher fractal dimension.
Systems developed "TestFirst", on the other hand, explicitly minimize one measure - the "distance" between any point inside the system and its closest neighbour on the boundary. We should therefore expect to see a convoluted shape - the "manual boundary", that is the one resulting from manual tests, i.e. a user banging on the system, has roughly the same shape, since the software is (presumably) delivering the same functionality; but the unit tests "extend deep within" to cover all of that functionality while staying at a more or less constant distance from the code being tested.