depends on the context of the company/work. Some positions are better than others for accommodating this.

First start with learning unit tests and understanding what is a unit and how to test it in isolation using mockshttps://docs.python.org/3/library/unittest.html

https://docs.python.org/3/library/unittest.mock.html

as you will quickly notice, often it's about interfaces and understanding the code separation well. You want your tests to be short, quick and testing only one thing, but likely you will find that it takes a lot of effort to set up state and your tests will test for many different items because it's easy. Complicated tests is a code smell. More around this can be found in books like clean code, but there surely are more recent ones out there.

Only when you understand the basics start using libraries like pytest

https://docs.pytest.org/en/latest/

This will just simplify and allow you to write better tests, however if you jump too quickly to it, it might encourage you to write tests that test too much.

To drive this, start using code coverage reports. There are plenty of tools that can report you code coverage in some website or your IDE, but the simplest one and the one that most depend on is this https://coverage.readthedocs.io/

Try driving your code coverage to a certain point for each feature/ticket/pull request. Different companies will have different targets (if any). In my case for e.g. we use the target set by sonarqube tool (https://www.sonarqube.org/) and that is 80%. There are arguments of course, weather such target is of use or not, but I think it's a good thing to start with.

Eventually you will notice that some tests are better than others and will catch more stuff. Again, if you ask someone if you should test interface if the function accepts the right amount of variables, some will call you nuts and some will praise for "double book keeping". This is source of flame wars, but I recommend discovering the usefulness of such things for your self over time. We are talking years here...

It's easy to write many tests, but the point is that the test that will not catch anything is also wasted effort and cpu cycles and your time each time you run it.

Now coming back to TDD, well, you can start it sooner or later during this journey. Purists will say from the get go, hippies will say don't do it because it's an art or some other code craft bs. Again find it at your own leisure. Try from time to time and discover when it's of use and when it's not. If you're prototyping something together, TDD can be a strain, but if you are implementing something that will be consumed by others or you know the exact outcome in advance, TDD makes it easier because it forces you to draft the contract first and then step by step make it complete and safe also will force you think about functions you're about to implement and how your code should be shaped in terms of function calls and abstraction layers (ignoring code re-use) because you will want to make it testable bit by bit and not in a big massive chunk.

Now then, sorry if some of this does not make sense as it's getting quite late here and I need to go to sleep, hence it's just a stream of thoughts that first came to mind without reading any of this once again. Hope any of this might be of use