unit testing

I rather enjoyed this interview with Jay. It was nice hearing a reasonable voice in the discussion – namely, there’s no need to be over-zealous about any one approach. Even in my own work I’ve seen a tremendous benefit to testing as I write code. It saves a lot of headache and provides some assurance that things still work down the road when code changes. Of course, as always, you need to be confident your tests are thorough enough in the first place.

It’s been a while since I was deep into CoreData, but here I am again. And this time, I’m writing proper unit tests.

Things were going pretty well – I had about 50 test cases with a few related asserts in each – until I started messing with saving, and fetching tests. I ran into some odd behavior where sometimes a particular test would pass, other times fail with different results in one assertion. All I was doing was creating a managed object, setting a relationship, saving, and reading back to check for proper order. Pretty trivial stuff.

I looked deeper.

If I ran just that one test case by itself, it would always pass. If I ran “All Tests”, it would always fail. Sometimes I would get several fetched objects when only one was expected. Sometimes those would be in different orders.

As I dug deeper, I attempted to reset my context on each test case

Swift

1

[self.managedObjectContextreset];

No luck.

To this point, my managedObjectContext has been a singleton – to follow the pattern of the rest of the appellation. I had a hunch the problem might be there – especially if multiple tests are running (concurrently, even?).

By no means is TDD (Test Driven Development) a new concept; I’ve known about it for years. I had sone some unit testing on projects prior, they became an integral part of routine when I started consulting for HP’s Software R&D lab. We’ve been very good about testing out all the important logic of the application, save automated functional testing of the UI (more on that in another post).

This post is really about TDD, not convincing you to unit test your code (something you should be doing). Actually, I’m not a diehard TDD fanatic. Rather I use principles of testing first before writing application logic. I don’t want to get stuck the pedantics of true TDD development.

My journey, if you will, started as I had a turning point in two projects for Pivotal Action that convinced me. The first project involved a bit of interplay between iBeacons (CLBeacon) and networking, which would be impractical to manually test with physical hardware. The second project involves a lot of transformations being applied to objects, and some networking. In both cases, relying on rather extensive unit tests could ensure I wasn’t breaking functionality with new features.

My general approach involves a few simple practices:

Create a mock data set for input. I often use JSON files because it’s easily readable, and you can use the same data on multiple tests if you need. Also helpful if you’re testing mock network response data

Create a test data set, or scenario. First pass, go with the “golden path” – the best case scenario

Determine what your desired outcomes are in a best-case scenario

Create separate test cases for each kind of data you may have to deal with. Again – start with the best case scenario

Write some logic code to either transform data, or respond to it

Go back to step 1 and create a new set of data representing one type of problem, or family of very similar problems. This could be malformed data, error codes from API services, etc. as well as common problems : out-of-bounds errors, off by one, nil, and others.

Keep repeating 2-5 until you’ve exhausted just about every scenario you can reasonably think of.

This may seem boring and repetitive, but I assure you that thoroughly testing your logic will uncover holes in your implementation before you even start writing application and UI code. You’re also more likely to survive refactoring unscathed if you have extensive unit tests covering the changing code. I recently benefitted from this when I converted a set of model classes over to a CoreData stack. It wasn’t a perfect 1:1 refactor, but it uncovered some places where I had to adapt my expectations and logic so that the transformations would be the same in the end.

I’m not perfect at this, but I can say that doing unit testing before really getting into the guts of an application has saved me a lot of work farther down the road. I also have more confidence that changes I make aren’t breaking existing functionality. Give it a shot.

I use this blog quite a bit for documenting little quirks, bugs, work-arounds, neat things, and tutorials so that I know where I can find the solution in the future. At the same time, you benefit by hopefully not having to go through some of the same messes I did just to get to this point.

I love CakePHP so far (but still quite the noob), but my biggest gripe is the documentation. The basics are there, but there’s often too little documentation to get the novice going. From the Bakery docs, it’s not exactly clear how to perform tests on models when HABTM (has and belongs to many) relationships are involved. Have no fear, it’s doable (though not straightforward).

Hopefully you baked your MVC pieces and included test scripts to go along with them. If not, do that first. The key part to getting the tests for models that have HABTM relationships is to set-up a fixture representing the table that stores the relationship. Don’t actually set-up the test – just the fixture.

It has been an interesting month – at the same time I’m picking up CakePHP, I have a client project that uses the Zend Framework. Right out of the gates I like CakePHP better. ZF doesn’t seem quite as cohesive as Cake, so getting it set-up has been more challenging. Granted, the client’s setup is a little more complex than the standard setup, but it still seems like there’s a lot more work involved just to get things going – lots more configuration. After two days on Zend I already realize how spoiled I am with Cake.

With Cake, I’m finally starting to learn unit testing. It seems real simple in theory, and I’m sure it is once you get the hang of it, but it is tedious. I’m talking about the amount of actual work involved just getting these test cases working. My simple pleasure at the end of the day is watching the screen fill up with a bunch of green “Pass” statements… no red.