TDD - I hate if I do not follow my own rules.

TDD or Test Driven Development is one approach for creating new software, modules, classes or whatever you need in your application.

The main idea behind this is to write your unit-tests first and then your productive code. Sometimes you need to change your tests because while developing the business stuff, you get new ideas on how you get the results you need. But this's fine.

Every time I do consulting in other companies or in my Delphi talks, I tell everybody: "Do your test first, because your development is much quicker" - "And you feel better" - "If every test is green (OK) you can ship the application".

There were complicated classes in the past for my FDK - it had taken more than twice the time to develop them if I hadn't used TDD. And yes, if you do the tests first, it will save you time. So far, so good. Of course, I don't follow my own rules 100% of the time. Sometimes it feels like - this is so simple; I don't need a test for this... In most cases, this is correct - not good, but correct. 

Nearly every app has a point where you have to do more complicated things and like to do some unit-testing. Maybe not for the first release, but if you or your users find the "first" bug, it would be nice if you could write a test to reproduce the bug. Then fix the bug and confirm your test with the OK from your unit-test.

Here's the problem. While creating the unit-test-project you notice, that you have more dependencies in your application than expected. Just one little test and you need to link 90% of the app. Horrible! If you've done the tests first hand, you probably had used more dependency injection. Changing that later is a real pain.

And then?

Your first look into your source code - OMG - What have I done... Yes, I found the problem, but are there any side-effects? Home much unit-test coverage do you have?

OK, Frank - Next time write your tests first..!

Yes, this is an old app from the time where I do not have an MVVM-Framework, but this is no excuse!

Site note:   Assert(TThread.CurrentThread.ThreadID = MainThreadID); it Is very helpful if you are using threads - and I hope with FMX you do everything you can do in a background thread! - Because you sometimes use a class or anonymous procedure in an event from a thread, you haven't done before.