Using Automated Tests to Document Software Architectures - ASPE

long time = timeToUpdateAndNotifyEvent(userState,
listeners);
assertTrue(time < MAX_TIME * MAX_USERS);
}
...
}
Conclusions
With help from a few agile models and some prose, automated
tests were capable of documenting some fairly detailed software
architecture requirements like location transparency and
scalability. Although it remains to be seen whether or not tests
are sufficient for other software qualities, the approach seems
viable so far.
Using tests to document architectural requirements helped
reduce the tendency to over-engineer a solution. The best
solution is the simplest solution that passes the test. Any
complexity beyond that is unnecessary. The tests provide an
objective measure for minimum simplicity required. Tests also
make it obvious where the solution's risks are. Any tests failing
indicate qualities that are at risk.
Tests make it much easier to estimate the cost of deferring a
design decision. When architecture is documented using tests,
the cost of changing a design later will be roughly proportional to
the cost of the refactoring required to make the change. Without
tests, the true cost of a design change is hidden by how easy it
is to update models and descriptions.
The certainty that comes with documenting architecture using
tests comes with a price. Generally, it takes longer to write a
test (and code that could pass the test) for a software quality
than it does to create UML depictions and explanatory text.
However, it is not clear if time saved with less formal
documentation would result in an increase in re-work due to
missed requirements later.
Also, it is not clear to what limit this technique can be extended.
The example presented in this article is more detailed than the
example given in Extreme Programming Explained, but certainly