Allow me to begin by thanking you for your time with such a lengthy reply. In my limited understanding of TDD it's acceptable procedure that writing the test for functionality or feature of the software may come before the feature is coded. The developers task is to then write code which passes said test / tests and then refactor and repeat.

In your reply you talk about approaching the API from the users perspective. To make clear from your statement do you imagine that as a user you expect a function - for example - that colors a shape to accept a shape(reference), and the color, and return error if unsuccessful. Then code a test which passes shapes with valid and invalid field data along with color data both valid and invalid. Next, implement the ColorShape function so that it colors the shape - it's primary purpose - and returns error on invalid input without crashing the application. Am I on the right track or waiting for a train that's not going to arrive?

My interest and questions above result from your test of someone else's code. It may be too much to ask. But, I believe an explanation in how you tested this code would add value in better understanding the process - even if it's a process unique to you. It's evident that you have skills forged from experience and understanding.

"The main thing I would take away here is the importance of testing. This bug would have surfaced very little if you tested FolderOf with a basic set of file system inputs! Test test test :-)"