If you are doing any kind of timestamping on your data, testability requires you to get the timestamps from a mockable provider, rather than using unpredictable and thus untestable values from the system.
For this purpose we usually inject an ITimestampProvider with methods to get the UTC time into any classes that need it.
Earlier we worked on a military project that did not do this. Instead it relied on a combination of the application and the database assigning timestamps.
Unfortunately SQL Server DateTime does not offer the same precision as System.DateTime in .NET meaning that the timestamps were truncated to a lower precision when written and so an object read back from the database would not equal the object that was written.
This is bad for testing. The OR-mapping code in the system was legacy code (meaning: code without tests) so they didn't know this until very late in the project. At that time, fixing it incurred a great cost.
On our current project we are using an ITimestampProvider and assigning timestamps in the application. The datastore is used for just that - storing data.
A side-effect of this is that when we discovered some failing tests in the persistence layer due to timestamps being truncated by the database we only had to modify the application in one place: have the timestamp provider provide data that matches the precision of the datastore (we don't need more than a precision of seconds anyway).
In effect, the requirement to make the code testable forced us to introduce better, more loosely coupled design which in turn saved us a lot of work downstream.
This way test-driven development is not just about line-by-line code quality. It also drives the system towards a higher quality design.