I recently finished an iPhone app for a client in California called RoadStoves. RoadStoves is the leader in the growing gourmet food truck business popular in Los Angeles and other cities. The app is called Road Stoves GPS and, as you might guess from the name, is a GPS tracker to keep tabs on the location of your favorite trucks. There are other food truck apps available, but this is the only one on the market providing location-based services showing trucks “near me”, GPS map locations, and driving directions. It’s a very handy app for all the foodies in the LA area.

I was happy to find out today that Road Stoves GPS is now the #3 paid navigation app on iTunes!

Thanks to everyone who turned out for the iPhone presentation Chris Bartling and I gave at last night’s Jam Session! We had a great time talking about a fun topic. I hope you enjoyed it.

There were some questions about Apple’s approval process. I mentioned that I just submitted an app this past Saturday and said I didn’t know how soon it would be before it was given the thumbs up. I wish I had checked my email during the break as it was approved last night. That’s not too bad a turnaround time. Thanks Apple!

Thanks again and I hope I’ll see some of you at next month’s CocoaHeads.

I would really like to thank all of you who attended the inaugural CocoaHeads meeting last Thursday. I couldn’t have been happier with the turnout and participation from everyone. It was also nice to finally meet many of you with whom I’ve traded emails over the past couple of months.

We had a great mix of people at the first meeting ranging from experienced Cocoa, NeXT, and Mac OS developers to those experienced with other languages/platforms, but just starting out with Cocoa and CocoaTouch, to those just starting their journey into software development. This should make for a very interesting group!

Andy Atkinson started polling at the end of the meeting for what technical topics people would like to see at upcoming meetings. I think the final ones we settled on were:

• Intro to iPhone Development
• Overview of RubyCocoa
• Unit Testing with OCUnit
• NSFoundation Framework
• Intro to CoreGraphics
• Overview of Instruments

Some additional ones I would personally like to see covered (even if I’m the one covering them) are overviews of Core Data and Core Animation.
Let me know if there are any others that I missed and should be tracking.

John Shields wrote up a nice summary of his thoughts on the meeting that you should check out.

I’d like to thank Bill Heyman and Damon Allison for showing us some very cool demos of what they are doing over at CodeMorphic. Good luck guys and keep ‘em coming! If anyone else would be interested in demoing their products or projects, just let me know and I’ll find you a slot.

I’d also like to thank everyone at Synergy Information Services. Their facilities are great and they also have a larger room available should we need it. We all also greatly appreciated the pizza and soda!

Vlad will be posting the Getting Started with Cocoa presentation and sample code to the website. Keep an eye out at Synergy’s CocoaHeads Page over the next few days if you’d like to download that content.

BTW, if you are interested in understanding the history of Cocoa and Mac OS X, I’d recommend checking out David Shaw’s website. He has a wealth of information on NeXT, Rhapsody, and Apple that many of you would find very interesting. Great job David!

As I mentioned the other night I’ll be giving a presentation on Object-C 2.0 at the July meeting. This will be a much more detailed look at ObjC which will allow us to dig into its core syntax and features.

I hope to see you all again at the next CocoaHeads meeting on 7/10 @ 6pm.

-Thanks,
Bob

Over the weekend, I finished reading the 3rd edition of Cocoa Programming for Mac OS X by Aaron Hillegass. The previous edition had long been considered the best introduction to the topic, but it had grown rather out of date given the major changes introduced in the Leopard release of OS X. Thankfully, the 3rd edition has been completely revised to reflect the current state of Mac OS X development.

Cocoa Programming for Mac OS X is an introductory guide to programming on the Mac platform. It provides broad coverage of the core Mac programming concepts you’ll need to write real world applications, but is not intended to be a definitive reference on the subject. Aaron’s presentation of the material is excellent and the code examples really help explain the concepts being covered.

The organization of the book has changed considerably since the last release. Several less-relevant and irrelevant chapters have been dropped and replaced with chapters covering Core Data, Core Animation, web services, and garbage collection. Additionally, the existing content and examples have been significantly revised giving this release the feel of a whole new book.

I would highly recommend this title to anyone interested in Mac development. Even if you own the previous edition, I think you’ll find the new and revised content well worth the price.

Over the past few months I’ve been spending a lot my free time learning Objective-C and Cocoa. Although it’s been fun learning a new language and framework, it has been somewhat of an uphill climb. Objective-C was the easy part. If you have some familiarity with C and also some experience with an OO language like Java, C#, or C++, you’ll pick it up within a week or two. Cocoa, on the other hand, can take quite a bit more time to wrap your head around. It’s a very large and robust framework and understanding how to use its constituent parts to form a whole requires a fairly significant investment of time and effort.

One of the biggest challenges to learning Cocoa is the lack of up-to-date books. There are several on the market, but most are woefully outdated. The language, development tools, and available frameworks and APIs have changed considerably since these books were written which can present an obstacle to learning from these older references. Thankfully, there are some new and updated titles coming out this year from Aaron Hillegass, Bill Dudney, and Erik Buck. I’ve got ‘em all on pre-order!

Although the book market may be a bit lacking at the moment that doesn’t mean there aren’t useful resources to be found. In fact, you’ll find quite the opposite is true. Apple’s Developer Connection posts many references, guides, and sample code at its site. There are also a number of useful third-party resources I visit regularly including MacDevNet, CocoaDev, CocoaBuilder, and Scott Stevenson’s excellent Cocoa Dev Central. Additionally, you’ll find dozens of great blogs and articles in various places. One of my new favorite Mac dev blogs is Marcus S. Zarra’s and Matt Long’s Cocoa Is My Girlfriend. The content is great and the name is brilliant!

The problem isn’t that there’s not enough information to be found. The problem is how do you make sense of it all and more importantly, how do you use this information to build a real application?

To help in this regard I’m starting a new site called Operation: Cocoa. Its purpose will be to provide the aspiring Cocoa developer with a path through the maze. Although it will likely be a few months before the site is up and running, I’m already working on content and will be hosting it on this site in the interim. The first tutorial entitled “Hello Cocoa” will be posted in the next week or two.

I’m very interested to hear any comments or opinions you have about this idea: what you think about the site name, what kind of content would you like to see, etc.

Thanks,

  -Bob

For the past few months I’ve been spending a considerable amount of my free time learning Objective-C and Cocoa. Apple’s Leopard release has introduced so many new and interesting developer technologies that I decided it was finally time to dive in and learn to write code for my favorite platform.

One of the new Leopard APIs I’ve been excited to learn is called Core Animation (CA). CA is a new Cocoa framework providing you the ability to create UIs with rich animations and compositions by using with a simple, consistent programming model. This allows you to easily create visual effects for your applications that would be impractical, if not downright impossible, to do on other platforms.

One of the challenges to learning CA (especially given my n00b status) is the lack of books and tutorials on the topic. So, I was pleasantly surprised to receive an email from the Pragmatic Programmer guys introducing Bill Dudney’s new book Core Animation for OS X. It provides in-depth coverage of all the key concepts including animations, filtering, layering, and 3D effects. I’ve just started reading it, but it looks great so far. I’ll be sure to write a full review when I complete it.

The book is currently available in “beta” PDF form with the final print version available in July. You can find out more about the book and get your own copy at its website.

I’d like to say thanks to everyone who attended my Spring 2.5 presentation at last week’s TCJUG meeting. We had another good turnout, which is always nice to see. Jeff Jensen at Intertech is always a great host and I had a fun time presenting. I hope the info was useful to you. I’ve attached copies of the presentation and sample code for your reference.

Thanks again!

-Bob

I’d like to say thanks to everyone who attended my JPA presentation at last night’s TCJUG meeting. It was a full house and there was a lot of good conversation during and after the presentation. As always, Jeff Jensen at Intertech is a great host and I had a fun time. I hope the info was useful to you. I’ll post the slides and demo application as soon as I finish making some Maven tweaks. Look for it early next week.

Thanks again!

-Bob

I was recently compiling a list of Test-driven Development (TDD) “Best Practices” for my client project’s wiki site and thought this would probably be useful to the community at large. I’ve been an avid practitioner and proponent of test-driven development for a few years now and have found it to be one of the most important practices I’ve adopted. If practiced correctly, it will have a significantly positive impact on the design and quality of your code.

Without further ado, here is my list of key concerns to keep in mind while practicing TDD…

Test Behavior, Not Methods

It is important to write test cases that test how a client object would interact with the class under test. A common question asked is “should I write unit tests for private or package-private methods?”, and my general response is, no. Private methods should not be directly tested as they do not comprise an object’s publicly exported API and instead only exist to support its publicly observable behavior. This certainly isn’t a hard and fast rule. If a private method is sufficiently complex or would be difficult to fully test via its public methods it can make sense to test these directly. If you choose to do so you’ll need to write some reflection code to invoke these methods or use something like the utilities provided by the JUnit Add-ons project.

Apply the “Too Simple to Break” Rule

Although maintaining a high degree of code coverage across the test suite is important, striving for 100% coverage is not advisable. There is a point of diminishing returns that needs to be considered. A good rule of thumb is if a method is too simple to break, don’t write a unit test for it. The question of what constitutes “to simple to break” is certainly up to interpretation, however, it’s rarely useful to write a unit test for a method like the following:

public String getName() {
    return name;
}

Testing simple getter and setter methods is generally not advisable.

Use Object-Oriented Best Practices In Your Test Cases

It is important to view your test cases as first class code assets. The same design techniques you would apply when writing your production code should be applied to test cases as well. This means you should look for opportunities to refactor your test cases to pull up common functionality into a base class, remove duplicate code, decompose long methods, etc. Failing to do so will drive up the cost of change and will contribute to the test suite losing value over time.

Use Appropriate Method Names

This may seem obvious, but it is all too common to see test methods with the following signatures:

public void testGetUser1() {
}

public void testGetUser2() {
}

Instead, use method names that clearly describe the purpose of the test. Doing so makes your test cases more understandable and easier for the team to maintain. For instance:

public void testGetUserWithInvalidUsername() {
}

public void testGetUserThrowsExpiredCredentialsException() {
}

Don’t Use Try/Catch Blocks to Catch Unexpected Exceptions

The keyword with this practice is unexpected. The JUnit framework automatically handles any exceptions that bubble up the call stack. It is important that you don’t circumvent this behavior by using a try/catch block around a test that should not throw an exception. Doing so can mask bugs that won’t be caught until the code is in production. For instance, consider the following implementation of the UserService interface:

public class UserServiceImpl implements UserService {

  private UserDao dao;

  public User getUser(String username)
                          throws UserNotFoundException {
    User user = dao.getUser(username);
    if (user == null) {
      String msg = "No User found for: '" + username + "'";
      throw new UserNotFoundException(msg);
    }
    return user;
  }

  public void setUserDao(UserDao dao) {
    this.dao = dao;
  }

}

There are two primary scenarios that need to be tested:

1. A valid User instance is returned for the specified username.
2. A UserNotFoundException is thrown for the specified username.

In the first scenario, no exception should be thrown so we should not attempt to catch it. Instead, we should declare, in the test method’s signature, that an exception is thrown. This will allow any exceptions to bubble up to the JUnit framework in the event that our setup code was incorrect and inadvertently caused this exception.

In the second scenario, we are explicitly checking for the case where an exception is thrown. This means we need to wrap this in a try/catch block and fail the test if the exception is not thrown.

The following test case implementation shows how to appropriately test these two scenarios. I’m using EasyMock to mock the interaction with my DAO.

public class UserServiceImplTest extends TestCase {

  private UserDao dao;
  private MockControl ctrl;

  private UserServiceImpl service;

  protected void setUp() throws Exception {
    ctrl = MockControl.createControl(UserDao.class);
    dao = (UserDao) ctrl.getMock();
    service = new UserServiceImpl();
    service.setUserDao(dao);
  }

  public void testGetUserWithValidUserName()
                                  throws Exception {

    User expected = new User();
    String validUser = "validUser";
    ctrl.expectAndReturn(dao.getUser(validUser), expected);
    ctrl.replay();

    User result = service.getUser(validUser);
    assertSame(expected, result);

    ctrl.verify();
  }

  public void testGetUserThrowsUserNotFoundException() {

    String bogusUser = "bogusUser";
    ctrl.expectAndReturn(dao.getUser(bogusUser), null);
    ctrl.replay();

    try {
        service.getUser(bogusUser);
        fail("Should have thrown a UserNotFoundException");
    } catch (UserNotFoundException e) {
        // should be here
    }

    ctrl.verify();
  }

}

Don’t Rely on Visual Inspection

The success or failure of a test should not be predicated on a developer “eyeballing” the console to determine the result. This means you shouldn’t use System.out.println() or Logger.debug() statements to determine your test’s success state. Instead, you should exclusively rely on JUnit’s various assertXXX() methods so the test can be run in an unattended, automated manner.

Use A Code Coverage Tool

It is often difficult to gauge how completely your test cases are exercising a piece of code. Failing to fully test all execution paths could result in you missing a critical application bug that causes a system failure. Coverage utilities can easily be incorporated into your Ant or Maven build processes which will generate a visual coverage report showing you precisely which lines of code were tested.

Here are a few open source tools I use for this purpose:
Cobertura
Emma
EclEmma

Use The Appropriate Tool for the Testing Scenario

JUnit provides a solid framework for unit testing in a Java environment, however, JUnit alone does not provide you all the capabilities you need to effectively test your code. It is important to find the right tool for the job. Luckily, the community has developed a wide variety of extension to JUnit that will help you test virtually any scenario you might come across.

Here are a few unit and integration testing tools I commonly use:
DBUnit
MockRunner
EasyMock
JMock
Selenium

That’s it for now. Hopefully this will provide you with some useful things to keep in mind while writing your test cases. If you have any additions to this list, please comment.

I recently came across a new Eclipse plugin you should definitely check out if you’re doing test-driven development (TDD). It’s called EclEmma and is based on Emma, the open source code coverage tool. Code coverage reporting tools like Emma or Cobertura are a must if you are doing TDD, but the one downside these tools have is it’s not easy to run them against an individual class while you’re writing your test. EclEmma solves this problem by nicely integrating with Eclipse which makes getting coverage feedback as easy as firing up the IDE’s JUnit test runner. It’s still an early release, so you may find some rough edges here and there, however, I’ve been quite impressed with what I’ve seen so far. It definitely looks promising.

EclEmma Homepage