Do I need TDD to create another Repository method that just calls different SQL scripts?

I have joined the tail end of a project and tasked with adding a method to an existing repository that needs to pick up data from a SQL database and copy it into another instance and run a transformation on the copy.

Existing methods in the repository uses Dapper for data access and executes embedded Sql scripts.

The data access layer has been abstracted out to allow testing. Other components the repository uses such as logging and error handling are testable with interfaces that can be mocked.

We are using the repository pattern and have created all the abstractions such as IRepository and there are no hard dependencies on anything.

To build out my new method, a large part of the process is to be consistent and reuse the existing style of executing Sql scripts with the same logging and error handling, and reusing the same coding constructs found in existing methods.

Conceptually and practically, I am not building new components.

In regards to testing after the code is written, I know how to write tests, mock the data access layer, create an in-memory database, pass through test data and test edge cases. Here, I genuinely do need to write a bunch of tests once I have written the method. I know what tests I need to write against acceptance criteria. Following this I can do some refactoring such as Extract Method.

But, in regards to TDD, to me, this stands for Test-Drive Design. I apply this if I don’t already know or have the testable classes, methods, dependencies and their abstractions and existing components I need to create my method.

Yet it has been suggested that I do start with TDD.

But all the Lego pieces are already there.

I think I only need to create tests after the code has been written. Integration tests mainly.

So in theory, what is my starting point if I want to still apply TDD to add another repository method in this context?