The result of TDD is more than unit tests, also building your architecture from the ground up, instead of up down (let the code grow like a tree instead of layout the architecture plans and start filling the gaps with code). There are other alternatives to TDD like BDD (behaviour) and DDD (domain), you have to have a better grasp of ..everything in order to differentiate them and choose which one is right for each project. Also TDD cannot be applied to legacy code (already written).
Automatic tests cannot be written for any legacy project, usually you need to refactor pieces of code so they can be testable. Most likely your senior doesn't have time to do that, make the old code testable. I know the feeling, been there doing this. Also not all domains, frameworks and engines are compatible to them.
Anyway start learn unit testing in your language and you'll figure out stuff on the way.
The result of TDD is more than unit tests, also building your architecture from the ground up, instead of up down (let the code grow like a tree instead of layout the architecture plans and start filling the gaps with code). There are other alternatives to TDD like BDD (behaviour) and DDD (domain), you have to have a better grasp of ..everything in order to differentiate them and choose which one is right for each project. Also TDD cannot be applied to legacy code (already written).
Automatic tests cannot be written for any legacy project, usually you need to refactor pieces of code so they can be testable. Most likely your senior doesn't have time to do that, make the old code testable. I know the feeling, been there doing this. Also not all domains, frameworks and engines are compatible to them.
Anyway start learn unit testing in your language and you'll figure out stuff on the way.
Later edit, I'm currently reading a nice unit test post about real vulnerabilities that affected the internet a few years ago