ThoughtShapes Shaping Ideas With Thought

What is good practice for understanding a system? What is the point of understanding a system? How and when does that understanding become outdated? These questions are relevant to system documentation - our topic. This article seeks to directly answer each of these in turn.

I can't think of a better way to learn how a complex application scenario truly works than to look at the test for that scenario (and the tests for related scenarios). What would you rather have:

1. A wordy document that is difficult to understand even if written by a solid writer?
2. A test that creates the complex scenario and tests the expected behavior?

If you're like me and you believe the tests serve as the documentation, I've noticed the following naming conventions help further this concept: