Test Driven Development in VBA: Eating Our Dogfood

You heard me right. TDD in VBA. It’s completely possible. I know because I’ve spent the last two weeks using Rubberduck’s Unit Testing framework doing it.

With the release of the first version of our software, it was time to start using it. Time to eat our own dog food, if you will. The results were… disappointing, to be honest about it. Truth be told, we weren’t ready to release. I rushed it because I was excited. “This is awesome! Everybody needs this now!” Right….

I wouldn’t change anything though, because actually using the software day in day out flushed out a lot of bugs that we’ve since fixed and are available in the v1.01 alpha build. The Task List wasn’t resizing correctly, the Test Explorer wasn’t inserting new test modules, the list goes on.  I don’t think we would have spotted these if I hadn’t been actually using it. So, all in all I’m happy with the decision to push out version one when we did. Otherwise, we wouldn’t have spotted these issues as fast as we did.

I’ve been interested in the concept of test driven development for a while now, but just couldn’t seem to wrap my head around it. I’m fairly new to C# and the .Net framework. Trying to learn a new language along side a new (to me) development paradigm was just too much I guess. Once I was able to try TDD in a language I know inside out, everything just seemed to click. I suddenly just got it, and began to wonder why I haven’t been working this way all along. (Beside the fact that other Unit Testing frameworks for VBA that I tried just sucked.)

TDD has had two major benefits for me personally.

  1. It’s forced me to actually design my architecture up front.
  2. It has made me fearless.

It’s odd now that I look back on it. When I design a database schema, I do just that. I design it. I fire up Lucidchart or get out the graph paper and I start sketching out how everything should look when I’m done. It allows me to get an idea of where my idea of how things should work and how things are actually going to work are out of sync. Flaws in the design seem to just jump out at you and smack you in the face when you take the time to design first. It’s definitely much easier to change a diagram than it is to change a database table. The same goes for actual code and I was definitely not designing my code first. I did what many of us do and just started hacking away until I had something that works.

How foolish and naive of me! If I take the time to design a database, why wasn’t I taking the time to design my code? I’ve not the slightest idea, but TDD has forced me to. Writing your tests first means you have to understand what each little piece of code is supposed to do before you write it. You have no choice but to design it before you write it. TDD solved a problem I didn’t even know I had.

What if you knew that your code worked five minutes ago? How would that change your life?

~ “Uncle Bob” Martin

When I say that TDD has made me fearless, I absolutely mean it. I know, beyond the shadow of any doubt, that my code does exactly what it should be doing. How do I know this? Because my tests tell me so. The tests are the spec and the spec is the tests. So long as the tests are passing, I know the code works. It’s more than that though. I’m free to change the code without fear of breaking it. If I make a change, and suddenly a test starts to fail, I just roll the change back and try again.

We all have that one file. You know which one I’m talking about. The one that’s been around for ten years. The one no one wants to touch for fear of breaking it. No one should live in fear of their code. It should bend to our will. After all, it is our creation. Code is our medium, the clay with which we work. Tests give us power over our code base. Tests subordinate the code to our will.

I’ve long had a mantra that has been hard to live up to.

  1. Make it work.
  2. Make it right.
  3. Make it fast.

Without Unit Tests, the process often stops after it works. “It works, now don’t break it. Don’t worry if it’s right. It works.” Tests help me make sure I’m always making it at least to the “Making it right” stage of development.

At this point I’m evangelising, so I’ll cut it short and refer you to this absolutely amazing talk from Robert Martin instead. All I have left to say is that I’m a convert. I’m a believer. I’ll never write another line of VBA without having written the test first again.

, , , , ,

  1. The Professional VBA Developer | Christopher J. McClellan

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: