TDD Random Record

2014 I have been engaged in the Agile Practice Consulting project, which is also a rewarding year for me, in particular, every point of the consulting project changes, whether it is the improvement of code quality, or self-organizing team building, can make us feel gratified. People-related issues are complex issues, changing people, changing an organization is a more complex issue, and there may be a lot of non-technical, non-competency issues involved.

In December 2014 I carried out a TDD (test-driven development) training in a company, a total of 4 hours to complete a specific needs example, looking at the step-by-step deepening of the understanding of TDD, until 2014-12-31, but also 2014 the last day of the afternoon after training TDD courses, After a series of summaries, a participant said: "Unit tests need to write more code, but from the overall point of view of the project, a word ' value '." Then a participant sent a copy of his training experience on TDD, called "TDD Caprice" will be the subject of this article, this article may be better to reprint this article, to understand a developer of TDD understanding of the mental process, as well as the views of TDD.

Note: The original text is published with Hxfirefox's https://github.com/hxfirefox/blog/blob/master/TDD/TDD%E9%9A%8F%E6%83%B3%E5%BD%95.md.

The original text reads as follows:

TDD Random Record

I dedicate this article to the Pioneers and communicators of TDD

This article is purely personal experience, if the similarities are purely coincidental

I never thought I was a good programmer, not even qualified, but deep down I was longing for success in programming.

Unfortunately, every time I write a review of what is called code, there will be frustration, want to reconstruct but also feel intertwined, difficult to start, but also feel that they have to rewrite the hard to write out, and spent a lot of thought, so discard the heart is unwilling.

Have thought about how to write good code, for some time think that only strictly in line with the code of programming norms is good code and then like to abide by the precepts of the word, there is time to think that only use the design mode can be called excellent code and then non-mode, all the pattern. But these did not let me out of the fog of development, is always an endless class, repair the bug.

Whether there is a way to get me out of the fog of development, at least to allow me to easily trim the code, reduce the incidence of bugs, I think this approach to me is successful.

The initial exposure to TDD is through the company's internal "code Daquan training", like the revolution in the Zeller of a cannon, opened the vision of software development for me. After testing the development, small steps iterative, continuous integration, these new term suddenly poured into my brain, both fresh and obscure. Like a person's young easy to commit infantilism, the first knowledge of these new term thought to understand all the TDD, the results found in the process of practice everywhere, stumbling, difficult. The swallowed of the development ideas that each link in TDD really implies, let this training only leave a vague figure of TDD in my mind: a safety net for software development.

Although not understanding the essence, but after the training experience and intuition tell me that TDD is a path to the software I aspire to success, although I find it difficult to move forward. Fortunately, the team was supported by the team's agile coaches, and the pair allowed me to systematically understand the idea of TDD.

Test -First, in fact, is about the demand boundary, testing is not aimless, but the exact cost of an activity. Where the test comes from, from demand, demand to push performance test, also planning product boundaries, can not reflect the needs of testing is a waste, so the development needs to be appropriate. Development is a utilitarian activity, always in pursuit of profit, and testing on a red line, once crossed means loss.

Small step Iteration , "Let the Bullets fly" in a sentence is very classic: step to step, a step to big, click, easy to pull the egg. The legacy of code stacking is complex, complex enough that no one wants to touch, and is constantly cursing at how bad the code is, which is a true portrayal of the stride. The small step of TDD is to write a test and then write an implementation, each implementation is tested, so the sum of the little wins for the victory, the final end of all the code is just let the last Test pass, it is so simple.

Refactoring, this is my favorite part, why? Because all of these activities will require you to think and look like you're going to have your code move toward the master code. Beautiful code is not a stack of tricks, but the right thing to do at the right time and the right place, refactoring is easy to achieve. Refactoring is something that can be addictive once you start, allowing developers to think and practice again throughout the development phase until they can no longer add or remove a letter.

Continuous Integration , you ultimately need to deliver the product, the product is the value of the customer needs, just as the chef will end out the guests point of the meal, no chef is all the ingredients listed in the present to you, but mixed together, cooking stew, some of the ingredients need to be processed first, This kind of eating is soft and hard moderate, and some is the last pot, so that the taste of fresh and juicy, the chef is such a step by step to integrate the ingredients, each step of the treatment are available are valuable, are for the follow-up of the bedding. Software development is also the same, continuous integration is to ensure that each time the completion of the value can provide support for the follow-up.

Written here, someone might ask you how to know that TDD is the truth, is the road, it must be suitable for everyone? No, I didn't know that everything I wrote was just an experience that happened to me. This experience tells me that TDD forces me to think more, to cut my long, complicated and unrealistic fantasies, to crush them into small fragments, to refine, to filter, to accumulate, and eventually to become the closest thing to value, and that final thing is the sense of accomplishment that I have been pursuing. If you want to know if TDD is right for you, the best way is to try and experience it, for better or worse, you can get more experience than I do.

Bo Master Summary

TDD is not omnipotent, but TDD is not useless, it is important to use the methodology of people, to introduce a colleague in a word:

站在教学的角度来讲，我还是很推崇TDD的，TDD是一个很好的思维框架，如果非要教人一个思维框架的话就得教TDD，不然人会瞎碰，不思考，不总结，不结果导向，靠灵感编程，凭直觉设计，撞大运修bug。最糟糕的是因为没有好的习惯会接二连三的发生灵异现象。同一道题，习惯不好的人做，总能做出无数种新问题来。而且问题套问题，给他解决要浪费我半天时间，如果他学会了TDD出的错只在最近一个引入的变化里，就好纠正多了。甚至他自己都能纠正。

The blogger is very sympathetic to the colleague's view, and the author thinks:

tdd重要的不是测试代码本身，是解决问题的思维，也许可以泛化，哪怕没测试，如果能够做到快速验证，反馈，价值的稳定叠加，有足够信心，也未尝不可。也许你会说测试可以cover功能，那么如果只有这一点的话，我更喜欢BDD(behavior-driven development)，因为这具有用户最终的使用价值。如果你说快速定位bug，我们我更倾向于BDD(bug-driven development，自创的)。这写都是TDD的结果导致的好处所在，而价值反馈思维才是实现TDD背后原理。TDD驱使我们以结果导向，使得我们简单设计(并不是无设计)，日常重构我们的代码库，注重交付价值流稳定叠加。

Whether it is "TDD Caprice" or a Daniel's "TDD is not as beautiful as it seems," tell us that there is no universal rule in the world, TDD is good or bad in your judgment, this article will not give you a perfect answer, this need your own exploration.

TDD Random Record