Install this theme
Unit Test Naming Convention

I like Roy Osherove’s unit test naming convention: 


A unit of work can be as small as a method or as large as (many) class(es) so long as it runs in memory is under our complete control. A unit of work is a use case in the system that starts with a public method and ends up with one of three result types:

  1. a return value/exception
  2. a state change to the system which changes its behavior
  3. a call to a third party (when using mocks)

So why should we name tests like this? First off, test names should express a specific requirement. This requirement is derived from a business or technical requirement, which is then broken down into small enough pieces, each of which represents a test case. Secondly, test names should include the expected input (or state) and the expected result for that input (or state). This clearly expresses the requirement of the test. It forces the developer to think about specific input variables (or current state) during the test and expected result from that state. Thirdly, test names should be presented as a statement or fact of life that expresses workflows and outputs. Unit tests are just as much about documentation as they are about testing functionality. They should be optimized for readability by the lucky bastard that will be reading over your tests in a year. He’s lucky because you followed this naming convention. 



Now go forth, follow the naming convention, and be happy with your tests.

Job Stories

I am always looking for ways to improve my planning process. User stories have been semi-helpful, but it was such a chore, like washing dishes minus the job-well-done feeling you get after seeing the pile of cleanliness.   I stumbled upon Alan Klement’s post regarding a new method. The problem with user stories is that they focus on who has a stake in a task and how the task should be accomplished. And so he proposes a new tool: the job story.

Job stories focus on context, causality and motivations instead of assumptions, subjectiveness, personas and implementations. They help you think of the why: Why do users want to do this? Why is this feature important? Why should I do this? 

The basic format is this:

Job Story Format

  1. Refine A Situation By Adding Contextual Information
  2. Job Stories Come From Real People Not Personas
  3. Using Situational Segments*, Design Modular Job Stories Which Features (Solutions) Can Plug Into 
  4. Add Forces To Motivations
  5. Job Stories Don’t Have To Be From A Specific Point Of View
*A situational segment is a collection of tangent jobs that someone wants to get done.
User story: 
As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.
Job Story:
When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.
User story: 
As an estimator, I want see the item we’re estimating, so that I know what I’m giving an estimate for.
Job Story:
When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I’m estimating is actually the correct one.
User story: 
As a moderator, I want to select an item to be estimated or re-estimated, the team sees the item and can estimate it.
Job Story:
When an item does not have an estimate or has an estimate I’m not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.
Motivation Using Pie

… Charts.

I stumbled across this article pitching a foolproof tool to motivate you and/or your team. Here’s how to do it:

  1. Write down categories for everything that motivates you at work: recognition, money, learning new things, etc. You can write as many or as few things as you want and there are no pre-set categories. Anything that matters to you can go on your list.

  2. Give each category a percentage weighting in order of its importance to you. The total weightings should add up to 100%, thus giving you a comprehensive pie chart of the things that motivate you.

  3. Use a “red, yellow, green” color coding system to rate how satisfied you currently are with each of the categories on the list. If you are very satisfied with your compensation, give it a green. If you are completely dissatisfied with how challenged you feel in your job, give that a red, and so on.

I’m really looking forward to giving this a try. Hit up the source to see some of the original author’s interesting findings. If you’ve ever done this, how’s it turned out for you?

Meaningful User Stories

A user story is a simple sentence that describes a small piece of system functionality. To write good ones, just remember the “3 C’s”:

  1. The Card
  2. The Conversation
  3. The Confirmation

The Card

As a [user], I want [function], so that [value].”

The card is a simple sentence that states who we’re doing this for and what value it will bring. It’s called “The Card” because it is usually written on a 3x5 index card.

The Conversation

As a Creator, I want to upload a video from my local machine so that any users can view it.

- The “Upload” button will be a persistent item on every page of the site.

- Videos must not be larger than 100MB, or more than 10 minutes long.

- File formats can include .flv, .mov, .mp4, .avi, and .mpg.

- Upload progress will be shown in real time.

The conversation is an open dialog between everyone working on the project and the client. It is a stage in which you can reevaluate the user story and split it into multiple stories, if required.

The Confirmation

As a Creator, I want to upload a video from my local machine so that any users can view it.

1. Click the “Upload” button.

2. Specify a video file to upload.

    1. Check that .flv, .mov, .mp4, .avi, and .mpg extensions are supported.

    2. Check that other filetypes aren’t able to be uploaded.

    3. Check that files larger than 100MB results in an error.

    4. Check that movies longer than 10 mins result in an error.

3. Click “Upload Video”.

4. Check that progress is displayed in real time.

The confirmation is a test case. A test case is a series of steps that a user must do in order to achieve a user story.

One Final Note

Make sure you INVEST in your user stories. All good ones are

  1. Independent
  2. Negotiable
  3. Valuable
  4. Estimable
  5. Small
  6. Testable
iOS Bundle ID vs. Bundle Seed ID

This drove me crazy. So I hope this post comforts someone out there. In case you didn’t know the difference between the Bundle ID and the Bundle Seed ID, here it is:


Bundle ID:

Bundle Seed ID:

How to Share Your iOS App with Beta Testers… Wirelessly!

This is a really convenient technique for distributing your apps over the internet to beta testers, clients, humans. Make sure that the UDID of the device that your app will be downloaded on has been added to your Provisioning Profile. Here’s the quick version:

  1. In Xcode, make sure you are building for ‘iOS Device.’
  2. Go to Product -> Archive
  3. Go to Window -> Organizer
  4. Select the app you want to distribute and click “Distribute…”
  5. Select “Save for Enterprise or Ad-Hoc Deployment” -> Next
  6. Select the DEVELOPER provisioning profile you want to use
  7. When the time comes to save it, make sure “Save for Enterprise Distribution” is selected. 
  8. Type the title and the EXACT URL that the file will reside in (so for example,<appname>.ipa)
  9. Upload the .ipa and .plist files to the (in the above case, ‘downloads’) folder on your server
  10. Create a link <a> for your download. The format of the link: “itms-services://?action=download-manifest&url=<appname>.ipa”

Your happy testers/clients/humans can now download the app by going to the page and clicking the link. 

I’m looking forward to this day

"Launch Day: the culmination of thousands of hours of focused, dedicated work; hundreds of scrapped ideas that will never see the light of day; dozens of sleepless nights; a single burning desire that united a team to build something for the world with their hands and with their minds.

It is also, as we like to say at Facebook, a marker in a journey that is 1% finished.”

Calculating UIView Frame Using Auto Layout

This. This has been bugging me for the past 3 business days. Perhaps due to my poor Googling skills, I’ve lost many brain cells from all that head bashing. Anyway, I’m still learning how to use auto layout. I was in need of generating a UIView programmatically using auto layout. The problem was that the resulting view would always have 0 width and 0 height! I stumbled upon this and my life got better. In order to force the system to calculate frames, you do the following:

[view setNeedsLayout];

[view layoutIfNeeded];

That’s it! I had to share. I’m incredibly happy right now.

Mac: Control Brightness on a Secondary Display from the Keyboard

You normally adjust the brightness of your display using F1 and F2. 

You can adjust the brightness of your secondary display using Ctrl+F1 and Ctrl+F2