I hope this isn’t too extremely obvious, but I found that I had to take a step back and re-examine my unit tests to find this simple improvement to speed up my unit tests.
When I wrote about how I’m hooked on test-driven development (TDD), the example in that post was too simple and time savings are not noticed. However, let’s dive in to something a little deeper where we have a full class to test oppose to a single internal function.
You have a common interface that is used by multiple concrete classes and you don’t want to specify each Ninject binding manually.
You have a large project with many interfaces and many different concrete implementations. Because of this, managing every single Ninject binding is becoming challenging and time consuming.
By leveraging an additional Ninject NuGet package called Ninject.extensions.conventions, you can write a single line (wrapped over several for readability 😉 that will manage all of your Ninject bindings.
During the creation of my first Android application – Behavior Therapy Tracker – I wanted to display a list of behaviors to manage; more importantly though, I wanted an easy way for users to add new behaviors to the list.
My solution to this problem was simple, add a one-liner form to the footer of my ListView that contained the behaviors.
I’ve only been doing TDD for a few weeks, but I’m completely sold. I don’t want to go back! I’ll be honest though, it hasn’t been easy. I’ve made mistakes, I’ve wasted time, but I’m really starting to reap the benefits.
I’ve always thought I was a good developer. I write decent code and it works mostly as expected. It took me many years into my career before I wrote my first unit test. It always fell into the category of too time consuming or expensive. Oh the irony!
As I started learning how to write to unit tests, I always found myself rewriting things I already did just to get them to be unit tested; how frustrating! A unit test that should have only took a few minutes, ended up taking a really long time because the code had to be refactored just to be tested. No better way to turn you off from unit testing.
Enter test-driven development…