I would argue that the question will not give any meaningful information and that you should make a stand if you are questioned in your practices as a professional.
I will start by the question itself:
Uncle Bob's Three Rules of TDD:
1 - You are not allowed to write any production code unless it is to
make a failing unit test pass.
2 -You are not allowed to write any more of a unit test than is
sufficient to fail; and compilation failures are failures.
3 - You are not allowed to write any more production code than is
sufficient to pass the one failing unit test.
These rules imply that you will be "trapped" in a loop of:
1 - Writing a little piece of test (maybe simply a
MyObject obj = new MyObject()) which will break, because you don't have the class
2 - Then you create a class called
MyObject, making all tests pass
3 - Then you write some more testing:
Assert.equals(obj.name, null, "Default name is not null")
4 - Then you create an attribute called name that is always
null, making all tests pass
5 - Then you write more testing....
Each of these steps are seconds long, you keep jumping frenetically between test and production code. The act of writing tests is embedded in the act of writing production code, and vice-versa.
So, how long did it take to write this unit test? Maybe you can have a text editor plugin that tracks the time you passed writing in files in the test folder. Is this information useful? Probably not.
Maybe your PO will ask:
But we want to know if TDD has a positive ROI...
The reason we don't question doctors why they spend time cleaning their hands 10 times, with 10 strokes on each side of each finger and under the nails, it's because they are professionals (literally they do). They take responsibility on their craft.
Accountants use double entry bookkeping, which is basically the process of TDD: Making a smallest step on the assets column, then making the equivalent on the liabilities column, and checking everything is OK.
TDD is a software craftsmanship practice, it is done because it is necessary to produce high quality software, which allows changes and improvements with security that quality is not denigrated.
If the PO don't value this and prefers to deal (financially) with the consequences of badly designed software, no problem, but he/she will have a hard time dealing with professionals that value high quality of their craft.