In XP/TDD Progammer (xUnit style) have always carried the burden of ensuring correctness. This is how it should be.

The point of acceptance tests, at least the FIT style “customer” tests that I’m thinking of, is communicating the behaviour of the system. They are the answer to the criticism that XP is anti-documentation. Done well acceptance tests make a better documentation. Better because by plugging the documentation into the code something magical happens: the document becomes alive. As long as we commit to running and keeping the acceptance tests green, it must always describe the system as it evolves.

The primary purpose being documentation, the focus of the tests should be readability over completeness: a couple of examples illustrate that a field must be a date; in a functioning XP team obvious edge cases such as February 29th can be left to (programmer) unit tests.