Test Driven Development of prototype software


#1

In my job, I’m kind of a handyman of software. I do all sorts of different things. I prefer designing and implementing systems and APIs, but I also work on UI/UX/end-user applications, because… that’s what my boss wants sometimes.

I’ve been programming since I was 10, and mostly teach myself. I’m three years out of college, where I double majored in EE and CS. My CS curriculum was pretty lackluster and had almost no software engineering content. But hey, I know how to program and have a piece of paper that says so!

I’m one of those developers who doesn’t really write tests. Because I didn’t know how to write tests without ending up with an unmanageable pile of garbage. Recently, I’ve been watching some videos on testing and test driven development, and I’ve started decoupling and testing my libraries.

When I’m charged with developing a product, I’m given a non-specific, high-level description of what’s needed. I would not call this requirements, but rather guidelines. This is generally always the case. I flesh out the details of what the customer actually wants by creating a prototype, showing to the customer, and iterating (the customer is usually my boss). By the end of this process, I have enough knowledge of the problem that I could write functional requirements for it. Historically, I’m immediately asked to do something else, and the prototype becomes production :confused:

My question is this. Given the prototypical nature of my usual workflow, and the lack of requirements, is test driven development the wrong methodology for me? Or should I be taking a different approach to this process. Because it seems to me that TDD is driven by the requirements. How can I write a test, or even determine units, when I have nothing but a vague, high-level notion of what I’m solving, with no clear details? I suppose I could write a test every time I had an idea for a feature, but with constantly evolving prototypes, that would be terribly inefficient. I probably throw away, or refactor to the point of rewriting at least 2/3rds of the code I write.