Searching for my motivation in 1s and 0s.

BDD

May 26, 2012

I have long been a fan of Test Driven Development (TDD). I have used all kinds of frameworks for doing my tests and for all of them have adopted the Act, Arrange, Assert pattern. I have looked into doing Behaviour-Driven Development and like the idea, just never found a framework that I was comfortable with and could use back and forth with unit testing.

I have been using OCUnit that ships with Xcode to do my testing. I decided that I wanted to branch out. I had heard good things about Kiwi for doing BDD with iOS. I decided that I should try it out. I normally I stick to the web and spelunking, yet this time I decided to buy a book on the subject: Test Driving iOS Development with Kiwi. This book is only available from the iBooks store.

I have to say the book was worth every penny. I really thought it was a simple and easy introduction. It doesn't try and cover every nook of the framework, but it gives you enough information to get you started and how you can easily use it. It also takes advantage of the fact it works on the iPad: you get media built right into the book. Rather than just text walk throughs, you get video / slides of how to do things visually. I really love this new way of doing books.

If you have never done or looking to do testing for you application (shame on you if you don't), you should really look into this book and Kiwi. I give it 5 stars!

February 15, 2009

Lately I have been trying to teach people TDD and running into the usual suspects of misconceptions. I decided that maybe it was about time to update my tool belt and try teaching in a new way. I also wanted to try out something new and hopefully improve myself. I decided to give BDD (Behavior Driven Development) a try.

I have been practicing TDD for many years now and I just recently started reading about BDD. When I read Dan North's intro about BDD, I had a funny feeling I had heard this story before. Back in 2004 while working at Microsoft, I was pairing with Brian Button when he said something that stuck with me, yet I have not thought about in years: "Instead of Test Fixture per class, why not test per feature.". (I know that is probably not word for word.) All this started to rush back at me so I decided to do a bit more reading. There are quite a few frameworks for working in BDD, yet I thought I would start simple and use what we do at work. (Always find it easier to start with what people know when learning something new).

I think the hardest thing for me to change in my thinking was the naming of my test class. (This is where the flashback to Brian happened again so I just dove in and gave it a try). I would normally just give my tests the name $ClassUnderTest$Tests. That really doesn't communicate my intent. It really just is a logical grouping. If I use the file as a grouping now, it makes it easier for me to switch. I now call my file $SystemUnderTest$Specs (where System Under Test could be a class). What helped me out tremendously is thinking of my feature / design as a user story. I gained much of this through reading Scott Bellware's article that focused around this area.

In this example, I am using the Test Fixture Per Class pattern as the classic approach. [I must admit that way back in my learnings of TDD I learned that very descriptive names are important.] The three main portions of your test are still the same: Arrange / Act / Assert, just laid out differently (I labeled them here for the example). The difference is really about how you arrange the tests themselves. This is not the only difference, you also have to think about how this code communicates to the person looking at it. I find this the one thing I really like about this approach. You focus on the concern that you are testing (refunding a guest account). The underscores are a style thing. If you don't like them, don't use them. Some frameworks use this to build reports and I have found that it is easier to read with the underscores.

The one thing I don't like about the way the test looks right now is a little bit of readability. I also feel the act and arrange should not be together: things just don't seem to flow. If you think about it: you also have to replicate arrange portions in each test (like guest identifier and amount) because we don't have a place to set this up. It also is missing some key pieces that Scott explains in his article. Here we change a couple of things around and I think come up with something easier to read (and explain):

All this for me is just the first part of my journey. Lately I have been moving to writing more of my tests in this style and I am finding I really like it. I don't recommend you go and change all your unit tests to this style: it is not worth it. Just try it out. Get a feel for it. Don't get caught up in different styles at first. Learn them, internalize them and do what works for you.