I read two questions: (1) should we document the tester-written unit tests and (2) how should we treat tests that assume implementation details?
It's important to distinguish between scaffolding and unit tests. (Please don't get caught up in my terminology; I'm just trying to make a point about some concepts.) Scaffolding is code a developer writes as part of creating a feature. They take whatever form the developer wants them to take. They might be tests against interfaces. They might be tests against internals to the implementation that are not in any way a part of any specification or requirement. The may be tests that produce a pass/fail result, or they might emit blobs of data that only made sense to the developer while he was coding and debugging.
Once the code is working, the scaffolding is probably just a pile of junk. Even if the interfaces don't change, if the scaffolding assumes implementation details, there is no guarantee or expectation that the scaffolding will do anything useful.
No one should have to maintain someone else's scaffolding, and it should be the developer's job to document their scaffolding if they choose to keep it around.
Unit tests (for the purposes of this answer) are tests against an interface that is a response to a requirement/specification. Unlike scaffolding, unit tests restrict themselves to public interfaces. Unit tests are written to produce a pass/fail result. Most importantly, unit tests should still pass if the interface remains the same but the implementation changes.
I think unit tests should have some kind of accompanying documentation. Perhaps it's comments in the code, or perhaps it's an external document, although you need to remember that as the tests change, someone will have to update the external document too.