TDD may be a happy approach for Us

This article taken from http://php-coding-practices.com/category/test-driven-development/, read in part  I feel pretty good as follows:

Test-Driven Development(TDD) is about writing your unit tests before u program the actual code.

The goal of TDD
Clean code that works is the goal of TDD. Then

• It gives u a chance to learn the lessons the code has to teach u. If u only hack together the first thing u can think of. u wont have the chance to think of a second. better thing.
• It improves the lives of the users of your software. Keep in mind that if u do not test your software. your user will.
• It is a predictable way to develop. u know when u r finished without worries about a long bug trail
• It just fells good to see the green bar.

However, how do we get to clean code that works, with all the external factors that seem to be preventing us form doing so? we drive deveolopment with automated test- which is ultimately called  TDD.

Why do We doing in TDD?

• We write code only if an existing automated test has failed. we eliminated duplication.
• design dynamically, with running and working code providing feedback between decisions.
• We must write our own tests. because we cannot wait 20 times a day for a colleague to write our tests.
• Our development environment must provide rapid response to small changes.
• Our designs must consist of encapsulated components in order to make testing of each of those easy. This is very important and very difficult to achieve environment.

The TDD mantra
Red - Green - Refactor, according to Kent Beck, author of TDD by example. is the TDD mantra. 

• Red means a test failed
• Green means our make the test work by writing code that satisfies the test and refactory
  
• our use refactoring to make the code as simple and reusable as possible.

Social benefits of the TDD

• if u can avoid long bug trails, then QA work can be proactive instead of reactive.
  
• if u can avoid long bug tails , managers can actually manage and plan the project and r able to involve ur customers in day-to-days development.
• if clean code that works can be written really fast, planning of programming teams can be made in day-to-day cycles instead of week-to-week or even month-to-month. making software is going to get a lot more profitable for your company.
• If there r no long bug trails ,we have shippable software everyday. We can provide our customers with a fresh update everyday with new functionality, making all teammates even your customers involved very happy,

Why should we use TDD?
TDD is about managing fear in programming(This sounds interesting). We have all been a situation where we had tackle a complex beginning. We are afraid of not getting the system to work- at least not programming, has a host of other effects, too:

•  Fear makes u tentative
•  Fear makes u want to communicate less
•  Fear make u shy sway form feedback
•  Fear makes u grumpy
•  Fear makes u inferior
•  Fear get u out of control

None of these efforts want to be experienced -especially not in programming, When u r tackling one of these very hard programming problems. these effects of fear can be the reason ofr the project to fail. They can be the reason for u to fail. TDD is about eliminating fear when programming.How should we tackle a difficult programming situation?

• Instead of being tentative ,begin learning concretely as fast as posible
• Instead of hiding in ur pit, get out and communicate more clearly.
• Instead of getting inferior and out of control, work on being superior all the time
• Avoid getting grumpy, Life's too short to waste ur energy, HeiHei!

Programming is like facing all other sorts of tasks, When u break a big task up into small chunks u cannnot only measure ur progress, but u can also better organize yourself and get the task done. the tests in TDD r like sub-taskes of the one big task the project. Once we get one test working, we got it working forever. If if fails, we can quickly fix it up. the important thing to note is that we have someone notifying us about crashed in our application.With another test working we r one step closer to getting the overall system to work. When one test fails, we did not go one step back. We went forword another one, because our code taught us a lesson about itself -about its relation to other code, input, etc.

Should we always use TDD?
I am a firm believer in TDD. However, some people like Kent Beck. say that it is also good enough to revert to ur ordinary programming practices as long as u reserve TDD for special occasions. However, there r occasions where TDD is still insufficient.

Think of PHP security, Of course u can test whether ur security barriers work. However, u cannot test whether your security methods r efficient enough to make hacking the system impossible.