Sunday, August 3, 2008 [Tweets] [Favorites]

Unit Testing Roadblocks

Daniel Jalkut:

I’m ashamed to admit that this is how many a unit test has been put off. Other laziness incubators include the friction of adding a suitable unit test bundle target to a project, and the difficulty of deciding how to factor your unit tests so that they make sense in the context of your project.

[…]

But now you’re bound to run into a vexing question: “how the heck do I debug this thing?”. Since unit tests are generally built into a standalone bundle, there’s nothing for Xcode to run. But when you come across a failing unit test and you can’t figure out why, you find yourself wishing you could step through the code just as you might in an application.

Jalkut points to various tips for unit testing with Xcode. That’s how I originally wrote and ran my unit tests (using ObjcUnit, since Xcode didn’t yet have built-in testing support). Now I’m taking a different approach: using Python and PyObjC to write the tests and py.test to run them. You may prefer not to deploy an application written in Python or Ruby, but that’s no reason not to take advantage of those languages during development. The strengths of dynamic languages are a good fit for writing and debugging unit tests, and the weaknesses don’t matter so much in the context of testing.

3 Comments

How do you debug when you need to step line by line? Is there a trick to get gdb to debug your py.test harness?

Daniel

Daniel: It’s rare that I need to do that, especially since py.test will show a stack trace and the values of various variables and parameters if a test fails. I also use lots of logging, and py.test figures out what each test logged so that it can display it intelligently. If I do need to debug step-by-step, I can attach gdb to the Python process. It may also be possible to start up the tests from within gdb, but I think attaching is simpler (especially since py.test makes it easy to control which tests are run).

I see - so if you wanted to debug a test you could run py.test, attach, and then invoke the desired test? Sounds pretty compelling. Thanks for sharing this approach. I like your idea of taking advantage of PyObjC for dev purposes.

Daniel

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment