This article is one of the contributor of Element3, after experiencing the TDD componentized development process of Element3

The author of this article: World Wind thirteen

TDD confusion

A lot of project teams don’t use TDD (Test Driven Development). I think it’s a very high percentage of development teams today, especially in small and medium sized companies. The reasons may be some of the following:

  • TDD is cumbersome and adds to the workload
  • TDD is too complex for the average programmer to master
  • TDD is not a necessary investment of time
  • TDD is too ideal, let’s face it
  • TDD is great, but our company is too weak to hire such professional developers

I think there are some possible reasons for this:

  • TDD may not be well understood
  • The team is not given space and time to experiment
  • Not looking far enough and focusing only on the outcome of the current project
  • No real experience of the benefits and benefits of TDD

TDD thinking

There’s another expression in the Extreme programming community:

In the final analysis, developers are not capable, not good TDD, say what is useless, TDD is to deliberately practice, “first throw 10,000 balls again!” . 😀

Generally speaking, this TDD (test-driven development) is like a lot of experience ability, not personally experience, not in-depth experience, will not have a deep feeling, should now popular “really sweet” law, always want to use, experience, will say good.

For example, when someone tells us that working out is fun, addictive, and hugely rewarding, we can’t experience it, we know it, and we can’t practice it. And then what? There are always a lot of reasons and excuses to give to others and to excuse yourself.

  • It’s too much work, too much work, too much work every day
  • Fitness is very difficult (to get a fitness card, please a fitness coach), ordinary people do not have the conditions
  • Fitness is not a priority, so I don’t have much time to devote to it
  • The fitness lifestyle is the ideal way, the current situation is still to face
  • Working out is great, but the situation at home doesn’t allow it

Of course, fitness is an individual thing, while TDD is a team and company thing, and sometimes it can end up being harder to push. Of course, you can also start from yourself and gradually lead the people around you to join in, which requires a process.

In the open source community, however, the situation is probably better. On the one hand, developers are usually is a part of the open source project for the pursuit of technology that will be more willing to adopt advanced programming thought and concept, market and business pressure is relatively loose, the control of the open source project community leaders are usually technical masters, correctly treat some technical practice the important influence to the quality, Therefore, the development process of open source projects may be more scientific, rational and orderly, even though the people involved in open source projects are scattered all over the world, it does not affect their ability to produce high-quality software and results.

Element3 TDD

Recently participated in the component development of the open source project Element3. The whole project has established the principles and specifications of TDD test-driven development from the beginning of the project, so the participants are either familiar with TDD development methods, Or they are learners who want to learn and understand TDD, Vue3 and ElementUI in depth, and therefore have a good foundation in mentality and willingness, and at least there is no resistance or resistance to TDD development.

In this process, I personally have a deeper understanding of TDD development mode. Here are some of my personal feelings:

In fact, most of the time, I do not want to talk about specific technology, I think more than technology can change their own mentality, specific technical information, is not enough online? In this day and age, even a lifetime’s worth of learning. When it comes to TDD, most people don’t know much about it. I’ve probably known what TEST-driven development means for years, but it’s only been a year or two since I started practicing it. On reflection, one of the main reasons may be a lack of knowledge, not knowing how good TDD is and not thinking deeply about related issues. To paraphrase a style I saw recently:

Because you don’t hear the music, you think the dancers are crazy.

Because you haven’t experienced the benefits of TDD high-quality code, you might think that test-driven code writers are crazy.

Progress component

Personally, I have only reconstructed one component: Progress. It took me two weeks to complete the reconstruction of one component of Progress. Note: Just refactor/rewrite, this period is the premise of clear requirements, implementation scheme has been ready, I once again rewritten, just need to use test-driven development, ensure the quality of the code, the original has been tested using concrete realization way, to a large number of reference, reduced the demand of communication among this time, the implementation scheme of time, etc. I guess if I had to do it completely out of thin air, I wouldn’t know if I could do it in a month.

“Is that it? You might be teasing my development efficiency, I also know it is a general ability and qualification of mediocre programmers, this is normal, but it is also true, we’d better admit that our own is the most common, a big advantage is that after using TDD, even mediocre programmers, such as I can also write clap breast confident code, A real down-to-earth feeling, the prevailing mindset in the software industry is: Where is software without bugs? It’s normal to have bugs. It is true that the complexity of software determines the high probability of software bugs, but such a concept and argument has encouraged a lot of software code shoddy, just to achieve the function quickly, regardless of future maintainability, scalability and so on.

I such velocity may in some “the pursuit of results”, “fast break not only” the company projects are not acceptable, however, this is the real progress of high quality software, the other day in the extreme programming group of statistical programming ability is very strong friends one week “no smell” (Sonar scan no bad taste, The output of high-quality code is only two or three hundred lines per day. For average programmers, it is probably about one hundred lines per day. What can one hundred lines do? Probably far from the high-speed expectations that many business leaders have: “I have an idea/requirement, can I have a Demo next Monday? It better be online this month.” This rate is not to say that cannot come true, just need early have corresponding preparation and accumulation, programming and development in this matter, actually is, the more abundant accumulation, strain capacity can be stronger, build a development team, a kind of enterprise culture, batch of high-quality software development talents, nature can only fast not to break the “efficient delivery.

It is as if we do this Element3 component library, or various other front-end UI component library, people use it can very quickly and efficiently build interface, a business needs, in some small and medium-sized company load programmers do three a day, five to add and delete interface effects are possible, but the company leader or a person think of an outsider, One of the widgets took so long to develop? The same is true of the various back-end development frameworks and other technical elements; without corresponding accumulation, there is no efficient delivery capability.

The benefits of TDD

Here are some of the benefits OF TDD that I’ve seen with this open source component refactoring:

TDD helps clarify requirements and thinking, because you need to write tests first to get started, so what should you test? At this time will put end to the results of the analysis is clear, and then split into small tasks can be realized, simple to complex, write the unit tests first, and then deduces the corresponding code realization, after the test pass, then write a unit test, pour a launch business code realization and so on, this is what we say development pace of TDD. In the list of GitHub repository Issues of this Element3 project, you can see the corresponding task dismantling process of the members participating in the project. There are dozens of tasks and sub-tasks for each component reconstruction. The whole process is calm, patient and rigorous. In fact, the more complex the component, the more beneficial it is.

TDD can help you refactor with confidence. Real refactoring is not just about changing the original code. Refactoring has been published in two editions, the first using the Java language as an example and the second using JavaScript as an example. How does the keyword ensure that the observable behavior of the software is not changed by adjusting its structure and code without changing its observable behavior? Based on the years of programming experience of many master programmers, only 100% comprehensive coverage of automated unit tests can be guaranteed. And to achieve 100% coverage of automated unit test, the best approach is to start from the write unit tests, write the business implementation code, and test drive so that the whole process down naturally to reach 100% of the unit test coverage, even if part of the code don’t need to test, more than 90% is also a very easy thing, With this assurance, we can boldly try new ideas, resist change, and deliver consistently with high quality and efficiency.

By the definition of refactoring above, most of the direct modification of implementation code that we see in common projects is known in the permission programming community as “messing around”. Those of you who have experienced TDD know that this is true. Frequent Bug fixes, unstable software quality, etc., will naturally lead to team members are resistant to any modifications, afraid of business needs and changes, increasingly unfamiliar with the source code, and have no confidence to complete even small improvements quickly. Each change and release requires a lot of human-assisted testing, regression testing, etc., and the subsequent costs are actually huge and incalculable.

Sometimes not demand changed, but their ideas have changed, and the initial implementation may consider not attentive, may adopt the implementation is not ideal, now want to use the better way, then you need a can guarantee the safety net, then TDD constructed by the universal coverage of unit testing will play a great value,

There is a Bug is found, the TDD constructed unit tests also can help us to quickly and accurately positioning problem, if the existing test can be normal through contrast test and Bug to the analysis of possible causes will soon be able to have ideas, to solve the added by unit tests for corresponding Bug scene, It is possible to quickly reproduce the problem locally and resolve it quickly and accurately.

The reconstruction process, two or three weeks on this project involves the change directory structure, transform the TypeScript language and other major changes, which in some project in the company can be very terrible decision, however, because of the security of the unit test, team members adhere to use TDD for development, are very orderly and smoothly completed these changes. For the foreseeable future, projects with such a good foundation will have a very strong momentum, a flywheel effect, a snowball effect, to deliver value more and more efficiently and meet user needs and changes.

Finally, I hope this article can cause you some interest and confidence in TDD, practical experience, looking for a group adopts TDD, involved, true across the programmer watershed, yes, yes, in my present concept, programmers can be divided into two kinds, one kind is can TDD, one kind is not TDD, It was almost a watershed. Both language, framework or business direction, so, when you appreciate the power of TDD, you will find that with this way of programming, a variety of programming languages may be is no longer boundaries, using such a technique, a similar spirit, what language programming can write high quality software code, from slow to fast, “the world martial arts, “Only fast” is just a matter of deliberate practice…

other

Stay tuned to Element3 and the Blossom Hill team as we continue to update the best content. Also welcome star and PR