Suggested by JerryWeinberg.
Pick one chunk of code. (I don't think it matters if it is a separate and named syntactic chunk, such as a function, or embedded within other code ; the rest of the test will take care of that.)
Understand the code, what it's supposed to do, how that is accomplished.
Memorize the code.
Then, close the file, and without looking at the original again, write the chunk of code into a new file from memory.
If you've made a mistake, the chunk was too long, or otherwise too complex. (If you've actually improved on the original, keep the improved version.)
I like this test, this is the point the LotsOfShortMethods people are trying to make, code should be simple, and methods should be small enough to grasp without half an hour of study.
There are ways to make digestable "chunks" without creating named units (methods/functions) -- See HeadlinesTechnique.
Of course, this is a rule of thumb. Some things have a minimum amount of complexity, and then it depends on each person's memory. How many people still remember the precise details of the quadratic formula and could re-implement it from memory without making a mistake?
(Yes, yes, I know that you can, but how many others?)
This is not about reimplementing from memory. It's about committing a manageable amount of detail to short-term recall, then reconstituting that. Look up an implementation of the quadratic formula, close the file, rewrite the same implementation. If you fail, that is no reflection on your memory, but on the clarity of the implementation you chose.
That's what I'm talking about. Not everyone's short-term memory (perhaps you thought I meant long-term, but I realize that is a different issue) is sufficient to do that, regardless of the clarity of the implementation, because that particular example has a lot of details that don't tend to have any mnemonic value for most people.
A good argument for SevenPlusOrMinusTwo "sub-chunks" per chunk.