TDD revolves mostly around unit testing, this answer is going to cover that.
Why do you make applications? Do you make them to see see that C# works well, or do you make them to solve a problem presented by your client (be aware, sometimes the client may as well be you)?
Unless you are a .NET developer working for the Microsoft company and are actually responsible for maintaining the C# language, it is almost always the second case. You are trying to solve a problem, a problem, which has some rules.
The rules presented to you are your business logic, your domain. Once you start working on your domain, that is the latest when you should start writing tests.
Latest? Yes. Speaking from a position of a senior PHP developer, even though it is nice that PHP allows you to do a lot of stuff a compiled language would not (such as returning two completely different objects from a method), it leads to bad code. Hence in many cases, it is better to just write your database layer and not be dependent on an already existing solution with static methods etc. If you do build this layer, you might consider writing tests for that as well, to make sure what you wrote works.
Generally speaking, there's never too early to start writing unit tests, but there's a point where it becomes too late and unnecessary. Such as unit testing your controlers. I have seen people do that and that is not what unit test should do. Your controllers are a procedure, containing factories for services, instantiating them, working with your domain objects, they are not units. If you want to test your controllers, use integration test suites instead.
What should always be tested then?
You want to have unit tests for your domain, your business logic. If you have that and your business rules are indeed only there, you do not really need to worry about the rest of the application, as it should only perform basic CRUD operations on data, which is valid (thanks to tests and good domain models).
TDD From the life-cycle point of view
TDD means you write tests first and then you write code. When you are working on a project, you go through several stages.
- Chosing the right technology - You do not know which programming language you are going to choose, yet, thus cannot simply write tests.
- Chosing your architectural model - You chose the programming language, but have no idea how your project will be structured. Will it be modules, services, MVC? In your case it is most likely going to be the MVVM pattern. Is your whole architecture considered a unit? I don't think so. You do not need to test architecting your application.
- Designing your domain layer - this is the part, where you take user functional and non-functional requirements along with the rules from the client and implement them. Before this stage you are supposed to write tests and then provide implementation to make them pass.
- (optional) Designing services, which use your domain models - You may create services uniting more domain operations into one process, much like a facade. You may write tests before designing these services, but it's an optional task.
As said before, to make sure your application (the wiring part) works as intended, you should use integration tests instead of unit testing.