Test Driven Development - How to practice Test Driven Development during your internship?

Applying the practice of Test Driven Development can be a great way to create clarity as you write Software.

Lake Chelan, Washington, USA

---

For an Audio Summary, click the Play button below:

---

Test Driven Development (TDD) has been around for a long time. For those unfamiliar with the term, the technique usually involves writing Automated Tests for the Customer Experience of your Software, before you even write the Software. You may naturally ask the question, but aren’t the tests going to all fail as the Software has not been written yet? That is exactly the point with Test Driven Development. You write failing tests, that capture all the Customer Scenarios your software is going to implement, and then you follow up with writing the actual software, to make each of those tests pass as you flesh out the implementation.

The practice of Test Driven Development, was made popular by Kent Beck, an American Software Engineer, who helped pioneer the concepts of extreme programming in the late 90s. Test Driven Development has a number of merits that enable software engineers to code confidently and produce bar raising software with low defect rates.

In the summer of 2010, I got my first opportunity to mentor an intern, Jamil. Before Jamil started on the team, I thought about different projects that I could ask Jamil to work on. I also thought about how to enable Jamil to implement his software while using the practice of Test Driven Development. This was a radical idea at the time, and I really appreciate Paul, my manager at the time, who supported me in this direction. An intern’s time is limited, usually around 12 weeks, and for a Software Development Engineering intern, writing working software is crucial for assessing their ability to succeed as an intern. My idea was to have Jamil, spend the first couple of weeks of his internship to learn about the Customer Experience of the software he was going to produce, and write automated tests that would fail to pass at the beginning.

As Jamil started on the team, I explained the ideas to him and referred him to some of the written material on the concept. Jamil was excited about the idea and started learning about the concepts. I also introduced Jamil to the XML based Test Automation Infrastructure, that I had created for the Scheduling Engine of Microsoft Project. The automation infrastructure was crucial in allowing Jamil to write the automated tests upfront, and then follow up with writing the actual software to build the desired customer experience. Jamil, understood the concept, and had the necessary automation infrastructure to build his software, working backwards from the Customer Experience.

Tip #1: Test Driven Development only works if you have a good Automation Infrastructure to begin with, that allows you to extend the behavior of your Software. Before you jump into using the technique, evaluate the readiness of your Automation Infrastructure.

---