TDD isn't about testing, it's about design. Writing the tests forces you to think about how the class is supposed to work and what kind of interface you need. The tests are a happy side effect that makes it easier to refactor later.
So, with that in mind, what is the behavior of a static page and what is the interface?
My first response would be "none" and "none".
If this test is intended to run frequently, your concerns would rather be focused on how to present test results in a way convenient to those expected to work with these results.
From this perspective, testAllTheThings raises a huge red flag. Imagine someone running this test every hour or even more frequently (against buggy codebase of course, otherwise there would be no point to re-run), and seeing every time all the same FAIL, without a clear indication of what stage failed.
Separate methods look much more appealing, because results of re-runs (assuming steady progress in fixing bugs in code) could look like:
FAIL FAIL FAIL FAIL
PASS FAIL FAIL FAIL -- 1st stage fixed
PASS FAIL FAIL FAIL
PASS PASS FAIL FAIL -- 2nd stage fixed
....
PASS PASS PASS PASS -- we're done
Side note, in one of my past projects, there were so many re-runs of dependent tests that users even began complaining about not willing to see repeated expected failures at later stage "triggered" by a failure at the earlier one. They said this garbage makes it harder to them to analyze test results "we know already that the rest will fail by test design, don't bother us repeating".
As a result, test developers were eventually forced to extend their framework with additional SKIP status and add a feature in test manager code to abort execution of dependent tests and an option to drop SKIPped test results from the report, so that it looked like:
FAIL -- the rest is skipped
PASS FAIL -- 1st stage fixed, abort after 2nd test
PASS FAIL
PASS PASS FAIL -- 2nd stage fixed, abort after 3rd test
....
PASS PASS PASS PASS -- we're done
Best Answer
If a property is trivial (i.e. it merely returns a value), no, I don't write a unit test for it.
Instead, I rely on the unit tests that prove that the framework parser works, and unit tests that prove that the code that depends on the property settings works.
If there is a problem reading the properties (because one is misspelled, perhaps), it will show up somewhere else in the testing chain (most likely in the integration tests).