Figuring out what existing code does can be a challenging and time-consuming task. Oftentimes, we are asked to do so while simultaneously expected to build out new functionality on top of existing methods. How can we make sure what we are doing doesn’t break existing functionality? We need to embody Sherlock Holmes! By applying an iterative approach to building tests that act as a flashlight in a dark corridor, we can enlighten ourselves to the functionality of code that we didn’t write and are now responsible for. Test Driven Discovery looks and operates differently than Test Driven Development. It has different objectives and a different process, but they are both deeply interconnected.
I am a second career developer who spent ten years in a previous career taking episodic moments and disjointed ideas and weaving coherent narratives. When I look at an application’s code that I did not write I try and approach it with the same eye towards building a systematic story. Test Driven Discovery is the tool used to make that story. With some creative and iterative use of our testing application and donning Sherlock Holmes’ cap, we can discover what lies beneath the code that we didn’t write, refactor and add to it, and hopefully not break too many things in the process.
Test Driven Discovery: Applying TDD Principles to Existing Code
Full Talk (40 Minutes)
Food & Swag Sponsors
Learn more about each of our Event Sponsors.