I know the exact expected behavior before I start coding. But I am having trouble translating that expected behavior into my TDD test cases. For example. an expected behavior could be the functionality I am building should periodically look into database, compute some metrics and then generate a report. This is a broad piece of expected behavior, unlike a unit test when you test small functionality. As per the TDD principles, it is advised to write tests at your interface and avoid any dependency on your implementation details as these may change in future. I am having a hard time trying to understand how do I do this for the use case I just mentioned ?

You can do TDD at any level. You can do TDD for unit tests.

From what you're describing your issue might not be TDD but defining and implementing the right tests for your systems.

I would say, look at your functions. How can you test them? Look at your interfaces. How can you test them?

TDD is just doing that before you code.