Xcode & Snow Leopard – Logical unit tests hanging

I haven’t written unit tests before in Xcode.  I started to read Apple’s article on unit testing with iPhone development because I wanted to follow sound development principles with an agile approach.  Not long into the guide, I got stuck.  Literally.  Using Xcode 3.2 on Snow Leopard caused Xcode to lock/hang during the build of the logical unit test.  Same results after iPhone SDK 3.1 came out.  I couldn’t find anything online either except a few people experiencing the same issue.  In the system console (not Xcode console) I was seeing:

9/18/09 8:35:29 PM Xcode[669] -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620
9/18/09 8:35:29 PM Xcode[669] -runOperationInBackground raised an exception: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620

Xcode[669] -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620

Xcode[669] -runOperationInBackground raised an exception: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2009b7620

Needless to say, I was losing my mind. Finally, a user in the Apple Developer forums, “cde”, posted the following gem:

We have recently discovered the root cause of this problem.

People who are affected can work around it by (I hope you’re ready for this)…

…changing the Time Zone on your Build machine away from Central Daylight Time.  (In six weeks you can change it back, and people in Mountain Standard TIme will be affected.)

No, seriously.  Give it a try.

The problem is a single-character typo in a regular expression that parses the date stamp of the unit test. It causes it to miss the beginning of unit tests that are executed at -0500 or +0500 relative to GMT, so the end of those unit tests is unexpected, and it causes the build log parsing logic to initially hang and eventually crash.

As has been said, “Then I decided to use regular expressions, and I had two problems…”

So until it’s fixed, change your timezone to Pacific time.

An idea for a college course :: Unit Testing

After spending a significant amount of time this week on writing JUnit tests for a Spring Web app, I’ve come to a conclusion.  College courses, even in the grad classes I am taking don’t spend enough time on the concepts behind unit tests.  Granted JUnit and NUnit has been covered in the classes I’ve had but really only the testing framework is discussed.

Test-driven development (TDD) teaches us how to write a test first, make it fail, stub out your methods, and then code until your test passes.  The practicality of TDD in the real world is limited because a requirement is to have your system well designed up front.  Getting to a point where you’ll know method names ahead of time means you’ve spent a significant amount of time thinking about the design and analyzing that design. 

We all know that is rarely the case.

There needs to be a course on the concepts that we need to keep in mind when designing a system so it can be tested later.  What kind of concepts?  Understanding exactly what you shouldn’t do to make tests difficult – limited coupling and high cohesion.  I started to get a better idea of those concerns when I took a training course on the Spring Framework.  Spring lets you use plain old Java beans for most of your core controllers which lets you test the functionality of the controller and not have to test the framework.  Keeping those concepts in mind during your development will help out later.

In this last semester I took a software engineering course.  In one of the lessons, a simple rule came up that I felt was totally appropriate for this theoretical Unit Testing course.  Any methods you create should only take the exact type of arguments you’ll use in that method.  If the method calculates a pay increase for an employee, the method should take float for the current pay and a float for the percentage increase.  Creating a method signature with an Employee object and something like an AnnualReview object doesn’t define the method, it only confuses the developer.  How can you write a JUnit when you don’t know what the method is going to use?

So that’s enough of my rant for now.  I think I’ve written more in this post than I did for my final paper in the class.  Ha!

JUnit Testing

I’d like to point out that writing JUnit tests after the fact is a pain in the ass.  I like to think I know enough about software engineering to develop software that has high cohesion and limited coupling.  Not following test-driven development allows me to forget some of those simple rules and now writing EasyMocks is killing me.