I tend to read the release notes on Tools. That was one thing the eclipse team was good about for a while. My #1 gripe about Xcode, somehow, has disappeared now. That was that when I was working on a unit test, I would have to open up the build window, find a node about running tests and then drill it open and find the test then drill that open and click on a button to see the console. Now, I can do build, and if there‘s an error in the unit test, the build console will pop open, with the log messages, and the error!!
I‘m writing some code for caching images on the phone. Here‘s a unit test of the file-based repository:
To run, target is set to Unit Tests and I do Command-B. The tests pass, so the build window does not come up on its own. When I bring it up now (command-shift-B), I see my run results including log statements!!
Now I‘m going to duplicate the first assertion and invert it to cause a failure:
(Click to see full size.) Notice that I am seeing the error immediately, don‘t have to drill open ten nodes on a tree. Also, the lower window scrolls to show the site of the error. This is pretty much perfect now. Here is a closeup of the failure message, with a log message right underneath (I wrote a Category for making UIImage compliant with NSCoding).
Now I fix it again and rerun, and get this (notice the execution time):
This is a gigantic improvement. Using Xcode for TDD made me realize that a test runner is largely superfluous and superfluidity is not something you want inside the part of the VSM that you are going to be running through a thousand times a day. Seriously, drill open the plugin runner in eclipse and look at what it shows you. How much of that do you use? The arc of JUnit mirrors this realization: as early as in the Contributing to Eclipse book, there is a section where Gamma and Beck make a runner that just reruns the tests in the background as part of the conditional compilation (which, incidentally, I don‘t miss in Xcode). Then Beck, when he tried to make some scratch from junit (a few years ago) returned to this. The strongest side of apple is this lean one where basically you don‘t get anything until it‘s absolutely needed and then only enough; they would never leave a bunch of half-used fluff lying around for a decade sucking up oxygen.
I generally like to engage in rhetorical challenges, even (maybe especially) when things go right. I‘m scraping right now to think of complaints I have of Xcode. I have done a lot with it. I finally added my own unit test custom templates and added them to source control so everyone on the team can just check them out and they will magically appear. I want to alter the project templates so I can get OCHamcrest and OCMock into projects as I create them. I saw a post on that, but I am a bit concerned that might all end up in the loo because 4 is imminent. Anyway, Thank you Xcode team. This tiny change takes the tool from worst to first for me in the TDD realm.
My only remaining complaint is that OCHamcrest is not quite as fluid in O-C as it is in Java. I kind of hate having to take Int or Bool onto the assertThat statements. But it‘s not that bad. The tests are still pretty readable.