Archives

When OS X 10.5 (Leopard) was released back in late 2007, I told a colleague at the time that Leopard was, by far, the worst release Apple ever put out. You can pardon a bit of hyperbole there, but after a healthy string of solid releases of OS X that just “worked”, the problems produced by Leopard were numerous (one might counter that this is all relative– four to five issues might not sound as numerous to users of other operating systems, but for OS X, these were a pretty big deal, and kept me from switching for months).

By comparison, Snow Leopard marks a great return to the kind of releases the Mac community came to expect. Yes we still have a month left to wait for its release, and yes there might always be small glitches, but as one long-time Mac user the answer to the question of “is it really all that?” the answer is pretty clear to me at least: “Yes, yes it totally is.”

Share/Bookmark

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy– specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes…

Share/Bookmark

I have a native iPhone application in development which requires me to interact with a server that uses a stateful protocol over a persistent connection to transfer messages over the wire. This is definitely not a trivial application to write, even though the UI itself is very simple.

The Problem

Stateful protocols and persistent connections are often interrelated, but not by design. My first problem was to divide the original problem in two: how to manage the persistent connection, and how to handle the underlying protocol so that the stateful aspects did not bubble up throughout the UI.

Share/Bookmark

Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

Share/Bookmark

‘hieroglyphics’ by Em_G

One of the things I most admire about Ward Cunningham’s work is that you can read something like ‘Signature Survey‘ and still find new things to appreciate, even years later.

Ward’s original article discussed a method to tackle large code bases (based somewhat on Tufte’s ideas on data visualization). To quote the original article, he summarized the process as the iterative application of two steps:

1. Inspection. Browse the report looking for startlingly regular or startlingly irregular structure. Examine the source code associated with each (ir)regularity.

2. Projection. Modify the summarization program (the cgi script that generates the report) so as to represent aspects of the inspected code that seem relevant to the inquiry at hand.

The real lesson I took years ago from ‘Signature Survey’ is that, when dealing with any sufficiently complex problem, knowing which questions to ask may not be obvious. And rather than approaching each problem with the same set of questions or criteria in mind, it is useful to let the problem itself guide you to the right questions.

All of this should seems obvious right? It is, after all, a simple idea. Still, if you have never done so, I would ask you to really give this idea some thought. Sleep on it. Think about it during your walk back from lunch tomorrow and take your time with it. Toy with the idea and some current problem you are working on. I’m not kidding– the exercise will be worthwhile in the end, and will continue to pay off.

Share/Bookmark

One of the new features of Groovy 1.6 includes support for per-instance metaclasses. This is a nice addition to the language, since it allows to change the behavior of objects without affecting all instances of the class as a whole.

For testing, it is often useful to mock out specific behavior of an object without affecting the class as a whole. While some mocking frameworks already allow this, they usually run through a few hoops (i.e. “partial mocks”). Allowing support directly in the language can simplify this kind of approach.

Another case where per-instance metaprogramming can be useful is in employing template patterns on a per-instance basis. Picture the case where the domain decides that one of its children is no longer in a valid state. Most domain models handle this by embedding some sort of state object within the children, so that any object holding a reference to the children know what the child can or can not do. With a per-instance metaclass, however, the aggregate root can simply add or replace behavior of that instance of the object alone.

Share/Bookmark

Testing your iPhone application, you may at some point in time need to stub a method call whose return type is a boolean (or some scalar value, or C based structure). The way to implement this (as described in a discussion on CocoaDev here) is to wrap the boolean in an NSValue using the OCMOCK_VALUE() macro defined in OCMockRecorder.h.

While this solution technically works, I find that doing this within the test class itself makes the test cases a little less readable along the way. Instead, I found it useful to extend OCMock to do this type of conversion for me, keeping my test code a bit cleaner as a result.

Let’s take a look at an example by examining the set up for a simple test case..

Share/Bookmark

As I have discussed earlier, you can go very, very far in unit testing your view controllers using the following recipe, without the need to bend over backwards or employ any mocking frameworks:

1. Initialize the view controller in your setup using initWithNibName:bundle:.
2. Force the view to initialize by invoking the controller’s loadView method within your setUp method.
3. Write tests to assert dependencies or behavior.

This works well enough for view controllers, but when it comes time to test your application delegate, this simple approach can begin to break down. Unlike UIViewController, your application delegate is only initialized as a by-product of loading the NIB. Thus, to get this code under test I find OCMock particularly useful.

I show an example unit test below, and discuss how I approached the problem..

Share/Bookmark

I recently ran into an issue building an app which hit an existing (protected) website. Passing credentials along with each request, responses at first appeared to be cached, even after the user credentials changed from within the iPhone app. In sorting through this issue, it gave me a chance to get a bit more familiar with NSURLRequest, and NSURLRequestCachePolicy. As I later found, however, my problem turned out to be cookie-related..

Share/Bookmark

A new version of TeamCity is out, and while I have not taken it for a ride yet, I found this feature particularly interesting:

Risk Group Tests, Tests Re-ordering
TeamCity 4.0 is now able to determine a set of tests which are likely to fail (i.e., recently modified, those with frequent failures history, etc.), and perform those tests first the next time the project builds. This allows teams to confirm potential fixes sooner, reducing feedback time.

There are strong cases to be made for risk-based testing in certain environments. The reason why it is not more commonplace is that implementation is tricky since it requires the CI system to know a few things which are hard to generalize:

• The type of build and testing framework
• Historical perspective across multiple builds
• A good set of heuristics along the way

Since a risk-based approach may mean skipping certain tests on some builds, this may sound like a step backwards to the agile developer. But consider it an alternative to improving overall build time (i.e. “based on very low risk assessment, tests which never failed will not be run every time.”). The hard part is defining what “low risk” means to your project, and how much value you would get reducing overall build time.

This is obviously not an issue on well-run projects with sub-minute builds, but if you were to be dropped into an existing project with, say, a large code base and a fifty-two minute build (I’ve seen it), this can become one way to perform triage on an otherwise untenable position. You don’t need a new CI system to implement risk-based testing, but having this alternative can’t hurt.

Share/Bookmark