Test-Driven Development
This week, I choose Test-Driven Development (TDD) as my topic. After reading many articles, I realized that I only knew a little bit about it, which was the part that I needed to create test before writing functional code. Therefore, I thought that I should research more about it through an introduction article. I chose this article below because it had detailed information about TDD. Below was the URL of the article.
http://agiledata.org/essays/tdd.html
In this article, Scott Wambler explained the definition of TDD, the two levels of TDD, the advantages and disadvantages of TDD, the importance of documentation, the Test-Driven Database Development, the Agile Model-Driven Development, the myths, and misconceptions about TDD. He also provided the adoption rates of TDD and a list of TDD tools.
The basic idea of TDD is dividing the coding process into smaller steps: writing one test first for a small bit of corresponding functional code at a time. According to Scott, taking TDD approach required great discipline because it was easy to “slip” and write functional code without first writing a new test. I agreed with him, since I still sometimes forgot creating test first when coding. There were two levels of TDD: Acceptance TDD (ATDD) and Developer TDD. The goal of ATDD, also known as Behavior Driven Development (BDD), was to specify detailed, executable requirements for the solution on a just in time basic. Developers only needed to write acceptance test and enough functional code to fulfill that test. The goal of developer TDD, or simply called TDD, was to specify a detailed, executable design for the solution on a just in time basic. Developers only needed to write developer test (unit test) and enough functional code to fulfill the test. Developers could apply both levels or one of them for their projects. I usually applied developer TDD for my projects, therefore, I would consider using the other level as well.
According to Scott, there were three challenges that made Test-Driven Database Development (TDDD) not work as smoothly as application TDD: the lack of tool support, the lack of motivation in taking a TDD approach, and the popularity of model-driven approach. I understood the challenges that TDDD had when it was a “new” approach in many data professionals’ eyes. In my opinion, if we could overcome the lack of tool support, the situation would be better. With enough tool support, we could encourage people to try taking this approach.
Scott also said that TDD worked for both small projects and “real” projects. He used his experience and Beck’s report to support for his statement. Personally, I doubted that I could even use it for “real” projects, since the adoption rates of TDD (mentioned in the article) was not high. Moreover, most of my previous partners did not even use TDD for our small projects. Therefore, it might not be useful right now for me, but I would consider it in future.
From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.