When should I use IDD? By Gil Zilberfeld @Typemock
Whenever you feel you’re wasting your time.
Ok that covers a lot. Where do you start? Much like any optimization, you start where the bottleneck is. Note that we’re trying to make people more productive, so we usually are not talking about seconds (although these can add up to a nice sum).
If people wait a few minutes for an operation to complete, a few times a day, for a few days, here’s a bottleneck. (You can use your team’s coffee consumption as a metric).
The optimization point is usually in the development process. Either you’re waiting for feedback too long, or just getting the system ready to check things. That’s a sign that IDD can help.
Now what? Let’s say you’re system takes 3 minutes to load before you can do anything. What does it do there? Get data from the database, prepare a cache, could be a combination of things. But here’s a secret – it doesn’t matter.
What you need to decide is what the minimal setup you need to run what you’re actually interested in. Suppose you got all the data from the database, and now you’re playing with the form displaying it, that’s your queue. You can short-circuit all the data bringing, by filling the data yourself.
We’re talking about changing the production code here, and this is no refactoring. Sure, your form will act the same, but the application now fills the data by itself – not from the database. Imagine what will happen if this kind of code gets deployed.
Just like with unit testing, IDD (with Isolator, for example) does not require you to change the code. Instead you change the runtime behavior. You fake the calls to the database and return the values that make a faster setup. The isolation code is throw-away code, but it does save you the accumulated time you waste waiting for stuff to happen, and you don’t touch the real setup code.
So there you go. The rough guidelines for IDD. Use it!