Real world Test Driven Development (TDD) - Does it work?

I am grateful to pass on this. Latin is simpler.

First, developers can/should not ran away from unit testing it gives confidence to business that code is tested with proof.

"TDD is writing unit tests to fail and the code.". Every top gun come and say this. This is awesome and whats wrong with it.
But, in real time how you write test cases??
To write test, you need to have concrete interface and method defined, messages defined and complete picture of implementation.Which mean you should have complete design ready no change in this.
If above is not clear, there will be too many turn around to fix code and then fix tests. Over the top, they say, be agile, requirement can change any time.
In agile design and requirement is not 100% clear how can you be sure that actual coding is already done in head of developer before starting development.
Problem with TDD is too much of time wasting and speculating on paper to thing about test cases and loops of code and test.

In my opinion, following is more efficient manner for coding (before sending code to testing team) -

Code rough ⟺ Adhoc Test (manual Test) ⇒ verify business requirement ⟺ Refine the code ⇒ Complete ad-hoc manual unit test ⇒ Write unit tests (rough) ⇒ cover code as much as possible ⇒ Send to Testing team for coding and writing acceptance test.

I would even advocate to just go for rough test and send the code to testing team. In real scenarios testing team can't write their test (Acceptance test) without having code. So while they start writing tests developer can complete the unit tests.

Anoop KumarTo write test, you need to have concrete interface and method defined, messages defined and complete picture of implementation.Which mean you should have complete design ready no change in this.

This is true and while I'm taking my first steps into TDD, I'm finding it time consuming, yet helpful. If you are a solo developer working on a project, then you've know what the application will look like and function. This design phase is often the hardest part. My strategy is to first draw rough sketches of the interface and then figure out how the user will feel. We did lot of mistakes when launching the first version of crazyengineers.io but have improved significantly in the recent days.

Where TDD really shines is when you're writing functionality the either derives from or depends upon the existing functionality. I've just written some part of the new project I'm working on and found out that the tests tell me what's breaking. With phpUnit, it's damn easy to figure out which part of the code needs a fix.

However I've also found myself struggling to get the test to function as expected. I'm still learning; but have lost about 80% of the time trying to get the test to work and writing the relevant application code was only 20% of overall efforts.

I'm wondering how'd it work when the scope of project grows and you've to modify the tests. Will keep sharing my experience here and look forward to hearing our fellow developer experiences.

unit test cases writing is really important for TDD. Mostly it is used for API based development where Rest /SOAP call are made. are you writing webservices call?

kunaljdare you writing webservices call?

The web app produces JSON responses; but it's just a minor functionality of the overall app. I'm writing unit tests as well as functional tests; with extra focus on functional tests.

It's just that the overall efforts in writing a correct test sometimes takes 4x the time to write the actual functionality. It could just be me, though. I'm new to programming.

You already became pro at coding when you ask yourself this question. Most developers ask this to themselves, but never write test cases😲😲 and make simple mistakes like e.g. coding 'O' instead of zero 😀😀😀(ME).

Our imagination about that project gets nice boost when we write test cases though.