- (void) testViewBinding {
	TestableSimpleViewController *viewController = [[TestableSimpleViewController alloc] initWithNibName:@"TestableSimpleViewController" bundle:nil];
	[viewController loadView]; //It is not strictly necessary to call loadView for this test as we access the view property which will call loadView if view is nil
	assertThat(viewController.view, isNot(nilValue()));
	assertThat(viewController.button, isNot(nilValue()));
}
 
- (void) testUIButtonActionBinding {
	TestableSimpleViewController *viewController = [[TestableSimpleViewController alloc] initWithNibName:@"TestableSimpleViewController" bundle:nil];
	[viewController loadView]; //Here we must call loadView since we have not accessed the controller's view property to trigger view loading from the nib
	assertThat([viewController.button actionsForTarget:viewController forControlEvent:UIControlEventTouchUpInside], onlyContains(@"testAction", nil));
}

Testing View Reloading
View controllers should be able to unload their views if the application receives a memory warning while the view is not visible and then reload the view when it is needed again. We can reproduce that same sequence of messages in a test. For a non-trivial controller we would add additional assertions to test that any other view dependent properties were correctly released and recreated as the view was unloaded and reloaded.

- (void) testViewUnloading {
	TestableSimpleViewController *viewController = [[TestableSimpleViewController alloc] initWithNibName:@"TestableSimpleViewController" bundle:nil];
	[viewController loadView];
	assertThat(viewController.view, isNot(nilValue()));
	[viewController didReceiveMemoryWarning];
	assertThat(viewController.button, is(nilValue())); //Note that while viewController.view is nil here we cannot test that directly as accessing view will trigger a call to loadView. Instead we can only test that our outlets have been released as expected.
	[viewController loadView];
	assertThat(viewController.view, isNot(nilValue()));
}

Testing Switching Between View Controllers
View controllers frequently have dependencies on other view controllers. If those dependencies are tightly coupled it becomes very difficult to test the behavior of a single view controller. Instead we can expose those dependencies and replace them with mock objects in order to isolate the controller we are currently testing. Here we have a simple table view controller which presents a detail view controller when a table cell is selected. By mocking both the navigation controller used to present that detail view and the detail view itself we can capture and verify the table view controller’s behavior.

- (void) testSelectingACellPushesADetailView {
	id detailViewController = [OCMockObject niceMockForClass:[GenericDetailViewController class]];
	NSDictionary *data = [[NSDictionary alloc] init];
	UINavigationController *navController = [[UINavigationController alloc] init];
	id navigationController = [OCMockObject partialMockForObject:navController];
 
	TestableTableViewController *viewController = [[TestableTableViewController alloc] initWithNibName:@"TestableTableViewController" bundle:nil];
	viewController.detailViewController = detailViewController;
	viewController.modelData = data;
 
	[navigationController pushViewController:viewController animated:NO];
	assertThat(viewController.navigationController, isNot(nilValue()));
 
	[viewController loadView];
	[[detailViewController expect] setModelData:data]; //expect that the detail view will be given some data to display
	[[navigationController expect] pushViewController:detailViewController animated:YES]; //expect that the detail view will be pushed onto the nave controller
	[viewController tableView:viewController.tableView didSelectRowAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]];
	[detailViewController verify];
	[navigationController verify];
}

So what makes test-driven controllers different?
I certainly could have written these example controllers without any tests around them. However by writing tests I was encouraged to make a couple of changes to the way I structure my code.

• My controllers expose dependencies that might otherwise remain buried in their implementations. In the example above I exposed the detail view controller my controller used so that I could replace it with a mock object. That made it possible to test that the expected data was passed to the detail view but it will also make it easy to switch to a different detail view controller in the future.
• By focusing on testing just one class at a time I am encouraged to create well defined interfaces and a clear set of responsibilities for each class. That in turn leads to more modular code which is easier to maintain and reuse.
• I write bugs but if I write a test to reproduce them and then prove that they are fixed I shouldn’t ever see the same bug twice. It is much easier to catch a missing nib binding because a test failed than it is to see the app crash when displaying some view and have to track down that exc_bad_access error in the debugger.
• Most importantly by writing tests I can have confidence that my code works as I expected, not only when I first write it but also every time I run my tests (which happens every time I build the app). With that feedback I can change one controller without fearing that I might have broken something somewhere else in the app.

For those of you who caught it last week at the SDForum, here are the links people requested:

• Maven plugin for Javascript Unit Testing with Rhino/ScrewUnit (from C5)
• The current code for the “wizardize” example we walked through.
• Blue Ridge (Rails integration tool)
• ScrewUnit
• JResig’s Presentation on JS Testing
• The slides we used

To sign up for next Wednesday, go to the EBig site.

I’m looking forward to participating in a panel Is Canvas the End of Flash? this month at SXSW on the role the new HTML Canvas element is playing in web development and how it compares to Flash. Much of the perspective I have for this panel comes from my long history working with Flash and from our recent work with Canvas for Isilon Systems on InsightIQ.

The panel has been organized by Greg Veen of SmallBatch, Inc., creators of TypeKit and includes Chet Haas from the Adobe Flex team, Nathan Germick from social gaming start up Wonderhill and Ben Galbraith from Palm and Mozilla, also lead of the ambitious Bespin project.

Come check us out if you’re going to be in Austin.

Also check out some of the presentations by friends of Carbon Five at SXSW:

From Dinosaurs to Digital: A Museum Convergence Success Story from Maria Giudice of Hot Studio on her work with Jonathon Denholtz of the California Academy of Sciences.

Social Search: A Little Help From My Friends a panel on social search organized by Brynn Evans that includes CEO Max Ventilla from our recently acquired client Aardvark.

Beyond the Desktop: Embracing New Interaction Paradigms a panel on interactions that go beyond keyboard+mouse includes Nathan Moody of Stimulant, masters of the multitouch Microsoft Surface and NUI design.

The teaser for it… Recent evolutions in JavaScript testing frameworks now allow creating test suites, test-driving development, and running tests on a continuous integration server. This allows us to support more complex JavaScript, have confidence in the implementation, and push more of the logic from the server into the browser, reducing the load on the server…

Hope to see you there.

<plugin>
    <executions>
        <execution>
            <goals><goal>javascript-test</goal></goals>
        </execution>
    </executions>
    <groupId>com.carbonfive.javascript-test</groupId>
    <artifactId>javascript-test-maven-plugin</artifactId>
    <version>1.0-beta1</version>
    <configuration>
        <includes>
            <include>src/test/javascript/suite*.html</include>
        </includes>
    </configuration>
</plugin>

You will probably also need to add Carbon Five’s public repository so that maven will know where to grab the plugin:

<pluginRepositories>
    <pluginRepository>
        <id>c5-public-repository</id>
        <name>Carbon Five Public Repository</name>
        <url>http://mvn.carbonfive.com/public</url>
    </pluginRepository>
</pluginRepositories>

The <configuration> section contains standard maven <include> and <exclude> tags to allow you to specify any Screw.Unit test suite html files you would like to include in your build.

Now when maven executes its test phase, it will include your javascript tests as well. Any test that fails will halt the build. When the test phase is complete the target directory will contain a ’screw-unit’ directory that contains the test reports. There will be two files for every file included in the test execution The first is an XML file named TEST-dir1.dir2.dir3.filename.html.xml that contains the test results for that file in a reasonable approximation of JUnit’s xml format. The other file will be named dir1.dir2.dir3.filename.html and will contain a sort of snapshot of the test suite’s html at the time the tests completed (the javascript will be removed and the css will be baked in).

Like Blue Ridge, the javascript-test-maven-plugin relies on the excellent env.js project and the less-excellent Rhino project to emulate a browser in Java. Unfortunately this combination creates the possibility of discrepancies between the browser and build results, and the probability of relatively slow test execution. To keep the simulation as realistic as possible, javascript-test-maven-plugin recreates the test environment for each Screw.Unit html file, so the more tests you can cram into a single file the faster your builds will run.

There are a few directions for future work. I’d like for the plugin to handle other browser-based javascript testing frameworks. Screw.Unit is popular, but seems suboptimal in many respects. The only limiting factor here is the plugin’s ability to interpret the results. If env.js could run in javascript interpreters other than Rhino, I’d like to give the the plugin the capability to fork out to spidermonkey for better compatibility and performance. Modifying the plugin would be relatively easy, but env.js appears to have some significant dependencies on Java.

Check it out if you have a need for this kind of thing and let us know if you have any problems or suggestions.

Among other initiatives, Carbon Five worked with DNA Direct to roll out their first release of, as founder and CEO Ryan Phelan describes it, “the first genetic guidance program for a top five health plan with Humana, facilitating prior authorization and providing clinical services to ensure appropriate testing with lower out of pocket costs from the right lab.”

I’ve been eyeing solid state disks for the last year or so, speculating that they could have a huge impact on developer productivity once all of the major gotchas were worked out. I specifically though that pairing a decent laptop with an SSD would be awesome, since laptops generally have significantly slower hard disks than workstations. They’re also a bit slower across the board (cpu, memory bus, etc), so I thought the IO boost from an SSD might even things out.

In December I decided to end the speculation, so I bought an 80G Intel x25m (Gen 2) SSD for my 15″ Unibody MacBook Pro.

As it turns out, the SSD is faster than the 7200 RPM disk that was in my laptop by every measure. Though, for most of the day-to-day tasks that I benchmarked, it wasn’t that much faster. For my Java and Rails projects, building (Java only of course) and running test suites ran between 5-25% faster. Deploying Java apps was about 5-10% faster. Reindexing a whole project in IntelliJ IDEA was about 40% faster. These are real improvements, but they’re not the knock-your-socks off speed improvements I thought I might get.

There are some benchmarks that were way-way-way faster. Running migrations on a database: super fast. I just don’t do those things that often. When you read about SSD performance, you see charts that make them seem 10-20 times faster. They are in some cases, just not for most of my regular usage patterns.

I learned that the real benefit wasn’t really speedier builds or faster tests. An SSD simply makes the machine zippy all the time. Applications launch as fast as they do once they’re already cached by the operating system, even when they’re not. In fact, the difference between a warm and cold start for all apps is nearly gone. Spotlight is essentially instantaneous. Opening new windows, web browsing, pulling up preferences, switching between apps… it’s all snappier. Even when you think it shouldn’t be — because the data has to already be in memory — it feels just a tiny bit faster.

You know that feeling when there are two apps vying for the disk at the same time? Everything just slllooooowwwws down as the drive hops from one section of the disk to another, multiple times each second as it fetches disparate data. Yeah, that doesn’t happen anymore. Heavy disk IO and multitasking aren’t a drag. For example, I don’t notice when Time Machine is running anymore because it doesn’t effect my work at all, even when I’ve got a number of my own disk heavy tasks going.

Sounds awesome, right? Well, where prices are now you’re paying about 20 times more per storage unit than normal drives. That’s way better than the 50x from 18 months ago, but it’s still a lot more.

Is it worth it? Since I could get away with buying an 80G model (~$260), I totally think it’s worth it. If I needed a bigger drive than I wouldn’t have been able to bite the bullet in principle ($500 for a 160G drive is crazy). Luckily, it will become an easier decision later this year when the 3rd generation drives hit the market. They’ll been even faster, offer more capacity, and come with a slightly more reasonable price tag.

If you’re thinking about it, get educated because there are drives that are good (Intel x25m) and many others that are not. AnandTech is a great resource for benchmarks and all kinds of information related to SSDs. While most of the major gotchas have been worked out, it’s a good idea to make sure your hardware, operating system, and future SSD will be friendly.

In the end, I’m not getting tons more stuff done than before, but it’s certainly more fun to code when things are always snappy.
Christian

PS: You can check out my limited development-centric benchmarks here.

I created an “Environments” resource group in Xcode and added a copy of my project’s “Resource/Info.plist” file for each environment.

A plist for each environment.

These plists should not be members of any build target (just like the original Info.plist.

Info.plist files should not be members of a build target.

In each build target’s settings I then set the “Info.plist File” to the plist I created for that target’s environment. Note that the path to this file is the actual path on disk relative to the project root; if you have an ‘Environments’ group in the project but no actual ‘Environments’ directory in your project then this path would be incorrect.

Specifying the plist for a build target.

In code I can then access the plist’s dictionary via the application bundle:

[[NSBundle mainBundle] infoDictionary]

Now I can define the domain name of an API I will be using in each plist and automatically connect to localhost when running tests, to a staging server when using a development build, and to the production server when building a release or adhoc build. Each environment has it’s own build target so I can also specify a different app product identifier for each target and install the different app versions side by side on the same device.

Aarvark has more details on the acquisition. You can also read more about the work did helping the Aardvark bootstrap their team and product development.

It’s not in every agile software team’s bag of tricks. Asking around our fairy savvy office, I discovered it’s far from universal. In the “State of Agile” report from Version One, which includes survey results from 2500 software developers, it wasn’t mentioned. Since I haven’t seen it show up that much in other agile writings, I thought I’d share my experiences here.

What is “5 Whys”? I picked up “5 Whys” from the lean software movement, which sprang from Toyota manufacturing. You can read about its history on wikipedia, but it’s pretty simple: at the end of the assembly line, when a widget comes out with a problem, you stop the line and ask “Why?” Whatever the reason, you ask the “Why?” again. Repeat at least 5 times. The goal is to discover the “root cause” of the defect, and fix the root cause, not just some symptom. Wikipedia has a good example around car repair. Here’s a software example:

1. Why did Sheryl say the sign-up flow was broken?
A: Because she was trying to sign up a second time. Duh.
2. Yeah, but why did the flow break if the user is already signed up?
A: It’s a bug. We didn’t have a test case for that.
3. Why didn’t we have a test case for it?
A: I just didn’t think of it.
4. Why didn’t you think about it?
A: The story seemed easy– I guess I didn’t think it through.
5. Why do you think you didn’t think it through?”
A: I guess I was working alone and was in a hurry.
…

Obviously you don’t have ask “Why?” exactly five times, but that does seem to be a pretty good number. The point is you start articulating the behaviors and procedures that cause the problems.

Taking It for a Spin. I’ve come up with exercise for agile software teams. Like I mentioned, when quality drops below your comfort level, give it a try:

1. (2 minutes) Make a list of the most recent bugs you’ve uncovered. I’ve found that the last 10 is usually enough– if not too much. You can put these on a white board, index cards or a wiki page– all will work.
2. (2 minutes) Prioritize them based on the ones you want to talk about. Which caused the most embarrassment or cost? You usually only have energy to talk about 5 or 6 of them.
3. (15 minutes) For each bug, ask “Why did this happen?” Then, probe deeper until you can’t get much further. Write the answers down where everyone can see.
4. (5 minutes) When you’re done with all the bugs (or out of time), circle common root causes.
5. (10 minutes) Brainstorm ways to mitigate or eliminate the root causes. Come of with one or two SMART goals for the team.

Some of the root causes we’ve gotten to recently:

• we didn’t pair on hard features
• we didn’t ask for clarifications on the requirements
• one engineer didn’t understand the intent behind the code
• nobody looked at the app on Internet Explorer 6

Just like in agile reflections, the changes made coming out of these meetings stick with the team. During one session, the developers decided that there were just too many mistakes that someone else would have easily caught– so they always needed two sets of eyes on every checkin. I’d advocated this before, but it was never applied consistently. To my surprise though, after the reflection, everyone was  disciplined about this policy– and our quality was much better.

[INFO] ------------------------------------------------------------------------
[INFO] Building Gearlist - Data Access
[INFO]    task-segment: [test]
[INFO] ------------------------------------------------------------------------
[INFO] [db-migration:check {execution: default}]
[INFO] Checking jdbc:mysql://localhost/gearlist_test using migrations at src/main/db/migrations/.
[INFO] Loaded JDBC driver: com.mysql.jdbc.Driver
[WARNING] There are 2 pending migrations: 
 
    20100116010256_audit_tracking.sql
    20100121052539_add_daily_reports.sql
 
    Execute db-migration:migrate to apply pending migrations.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] There are 2 pending migrations, migrate your db and try again.

It’s very easy to include the check goal in your build lifecycle if you’re already using the db-migration-maven-plugin.

...
<build>
    <plugins>
        <plugin>
            <groupId>com.carbonfive.db-support</groupId>
            <artifactId>db-migration-maven-plugin</artifactId>
            <version>0.9.9-m2</version>
            <executions>
                <execution>
                    <phase>validate</phase>
                    <goals>
                        <goal>check</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <url>jdbc:mysql://${db.host}/${db.name}</url>
                <username>${db.username}</username>
                <password>${db.password}</password>
            </configuration>
        </plugin>
    </plugins>
</build>

Check out the project home for additional documentation and details. There’s also a simple, complete example application showing off this configuration.

Enjoy!
Christian


class Views::Layouts::BasicPage < Erector::Widgets::Page
include ActionController::UrlWriter
...
end

Engine Yard will eventually allow us to push a branch to our cloud environment from git (ie “git push engineyard master”) but until that is available the best option seems to be to trigger a github post receive hook directly.

To that end I rewrote an existing script to trigger post receive hooks as a rake task; http://gist.github.com/271433

require 'rubygems'
require 'json'
begin
  require 'restclient'
rescue Exception
end

namespace :ey do

  # Based on http://gist.github.com/114954
  # Discussed at https://cloud-support.engineyard.com/discussions/questions/83-deploying-to-solo-instance-from-automated-build
  desc 'Trigger a GitHub Post Receive Hook to deploy the app'
  task :deploy do
    post_receive_hook 'preview'
  end

  desc 'Trigger a GitHub Post Receive Hook to deploy and migrate the app'
  task :deploy_and_migrate do
    post_receive_hook 'preview', true
  end

  def post_receive_hook(envname, migrate=false)
    token = `git config --get cloud.token`.chomp

    if token.empty?
      token = ENV['cloud.token']
      end

    if token.empty?
      puts <<-EOT
The cloud token is not set.
To store the token, use:
$ git config --add cloud.token SOMETOKEN
or set the cloud.token environment variable.
EOT
      exit 2
    end

    commit = `git rev-parse HEAD`.chomp
    payload = {
        "commits" => [{"id" => commit, "message"=>"[deploy #{envname}#{migrate ? ' migrate' : ''}]"}],
        "ref" => "refs/heads/master",
        }

    puts "Triggering a deploy for #{commit} on #{envname}"
    begin
      response = RestClient.post("https://cloud.engineyard.com/github/#{token}",
                                 :payload => payload.to_json)
      puts "Successfully triggered the deploy"
    rescue RestClient::RequestFailed => e
      puts "Could not deploy your changes"
      puts e.response.code
      puts e.response.body
      exit 1
    end
  end
end

In setting this up I discovered a couple of potential stumbling points:

• The environment must have been deployed via the EY dashboard before you will be able to trigger a deploy using the post receive hook API.
• The branch specified in the API call (and therefore the git branch you should be working in if running that rake task) must match the branch deployed using the EY dashboard.
• If you make an API call to deploy the ‘master’ branch EY will attempt to deploy branch ‘HEAD’.
• If the branch specified in the API call does not match the branch specified on the dashboard the API will report success but not redeploy the environment.

The folks at Engine Yard are working to correct some of those issues and now I’ve got a project which automatically pushes changes to the cloud every time our tests cycle.

I thought I’d just send him to Google but a search for agile retrospective returned descriptions that seemed too heavy weight for the small, skilled, agile-literate teams we employ at Carbon Five.

There is certainly a lot of valuable information and insight out there I and definitely suggest doing some reading to understand the fundamentals and options for running retrospectives. However, since we want to do retrospectives often, we need a practice that doesn’t take much time or effort.

Here’s a recipe we are using these days. You can do this in 30 minutes. I actually did this with our architect for a home renovation project I am working on. Great things came out of it. I think it might have blown their minds.

Setup

Get alll team members in a room with a few stickies each.

You’re here to talk about an iteration, project, or other unit… with the goal of improving the next time around.

Thoughts: 5-10 min

Smiley face on stickies with good things from the last iteration.
Frowny face with concerns, risks, fears,…
You don’t have to be exhaustive, use the time you allocate.

Cluster: 5-10 min

Create two teams.
Give the smiles to one and the frowns to the other.
Group the stickies into related clusters.

Discuss: 20 min

Identify the primary smiley clusters.
Confirm that you will continue to see these benefits, can you increase them?

Identify the primary frowny clusters and list the themes on a whiteboard.
Vote to discuss – each team member has 4 votes – put dots next to
the issues you want to discuss.
Discuss the top 3 issues – identify SMART (http://en.wikipedia.org/wiki/SMART_criteria) steps to address them.

Rinse, wash, repeat. Don’t feel you have to talk about everything. You are trying to focus on top issues. Once you address those, the next most important issues will surface for discussion.

We do this every other week with our internal team and monthly including our clients.

If you have other recipes for simple reflection, I’d love to hear them.

Light reception to follow. We hope you can hang out after for a glass of wine and to catch up before the holidays.

http://tickets.commonwealthclub.org/auto_choose_ga.asp?area=2&shcode=1501

Fail Early and Often: Innovative Practices for Online Development
Alon Salant, Principal, Carbon Five

Organizations today increasingly struggle to create compelling software products, web sites and social media while working with the daunting details of limited time and resources. Learn new ways of working and delivering early value with simple and easy-to-apply processes from a pioneering software development firm. Discover how agile techniques and tools have helped to sculpt new strategies and sustainable practices, leading to more success, faster turn-around and reduced expenses.

Location:
Commonwealth Club Office
585 Market Street, 2nd Floor
San Francisco, CA 94105

Telephone Reservations: (415) 597-6700

Time: 5:30 p.m. networking, 6 p.m. program, reception to follow
Cost: $8 members, $15 non-members, $7 students (with valid ID)

This is an open invitation. Please share with others.

There are a couple of different options for JS testing available at this point but Blue Ridge’s plugin is the first I have seen which made writing test driven code as easy as I have come to expect while still providing all the functionality I need. In particular;

• Running my tests in a browser is fast. Refreshing fixture pages to rerun tests is dramatically more efficient than waiting for selenium tests to cycle.
• I can debug my tests as they run against their fixtures pages and inspect or manipulate the DOM at any point.
• I have mock and fake objects available to test behavior and stub out dependencies.
• My JS tests run in continuous integration, just like all the other tests.

By writing fixtures pages and tests first I am immediately using all of my code in two locations and running it against slightly different DOMs. That has pushed me to encapsulate most of my code as jQuery plugins and think carefully about how much I depend on the page’s structure. I end up with terse selectors instead of using whatever attributes are readily available and a clear configuration point for my page’s behavior as I chain together plugin calls in $(document).ready().

We’d like to see what other developers have done and share what we have learned so far so Carbon Five is hosting an open discussion of JavaScript testing in our office this week.

Topic: Javascript Testing
When: Tuesday Nov 17
6pm: arrive/network
6:30 – 8 presentation and discussion
Where: Carbon Five office: 171 2nd Street, 4th Floor

Please RSVP if you would like to attend.

<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
  <property name="defaultEncoding" value="UTF-8"/>
  <property name="host" value="${mail.host}"/>
  <property name="port" value="${mail.port}"/>
  <property name="protocol" value="${mail.protocol}"/>
  <property name="username" value="${mail.username}"/>
  <property name="password" value="${mail.password}"/>
  <property name="javaMailProperties">
    <props>
      <prop key="mail.debug">${mail.debug}</prop>
      <prop key="mail.${mail.protocol}.auth">${mail.smtp-auth}</prop>
    </props>
  </property>
</bean>

The properties for an open server look something like this:

mail.host       = localhost
mail.port       = 25
mail.protocol   = smtp
mail.smtp-auth  = false
mail.username   =
mail.password   =
mail.debug      = false

And the properties for gmail look something like this:

mail.host       = smtp.gmail.com
mail.port       = 465
mail.protocol   = smtps
mail.smtp-auth  = true
mail.username   = my.email@address.com
mail.password   = mypassword
mail.debug      = true

The host, port, username, password and debug properties should be obvious.  The key is to change the protocol between ’smtp’ and ’smpts’.  The only real difference between smtp and smtps is that the later causes JavaMail’s SMTPTransport object to open an SSL socket to the server.  Gmail only accepts SSL connections on port 465.  After figuring this out, I was glad to see that Gmail was accepting my connections, but immediately frustrated to find that JavaMail was no longer attempting to authenticate before sending mail.  The trick is that JavaMail checks its transport related parameters under ‘mail.[protocol].[parameter]‘.  This appears to be an entirely undocumented feature of JavaMail.  Fortunately, we can substitute the protocol name into the parameter key as well, so our auth parameter still works with either ’smtp’ or ’smtps’.

Here’s the high-level flow that the functional test runner provides:

1. Load fixture data from a DBUnit dataset.
2. Download and install the application server (if necessary).
3. Start the application server (using Cargo).
4. Deploy the application, waiting until it’s completely started.
5. Run one or more functional tests (using your preferred testing framework – Selenium, HTMLUnit, etc)…
   If a test dirties the database in a manner that must be reset, the test class can be marked with the @DirtiesDatabase annotation. This will reload the database fixture and optionally restart the application.
6. Shutdown the application server.

It’s easy to use… First add the maven dependency:

  ...
  <repositories>
      <repository>
          <id>c5-public-repository</id>
          <name>Carbon Five Public Repository</name>
          <url>http://mvn.carbonfive.com/public</url>
       </repository>
  </repositories>
  ...
  <dependency>
      <groupId>com.carbonfive.test-support</groupId>
      <artifactId>test-support</artifactId>
      <version>0.9.2-m1</version>
      <scope>test</scope>
  <dependency>
  ...

And then write your first functional test:

@RunWith(FunctionalTestRunner.class)
public class FunctionalTestRunnerTest
{
    // This field is automatically injected by the test runner and references
    // the functional test properties (see below).
    private Properties properties;
 
    @Test
    public void propertiesShouldBeSetByRunner()
    {
        assertThat(properties, not(nullValue()));
        assertThat(properties.size(), greaterThan(5));
    }
 
    @Test
    public void applicationShouldBeDeployed() throws Exception
    {
        // Test using your preferred framework... just using URL as an example.
        URL root = new URL(format("http://localhost:%s/", properties.getProperty("appserver.port")));
        String content = IOUtils.toString(root.openStream());
        assertThat(content, containsString("Orange"));
    }
}

Lastly, create the configuration file that goes along with it. By default, it’s called functional-test.properties and lives at the root of the classpath (src/test/resources/ for maven users). Here’s an example:

# Application server
appserver.container         = tomcat6x
appserver.installer         = http://www.apache.org/dist/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.zip
appserver.port              = 8080
appserver.logging           = false
 
# Application configuration
app.war                     = ./gearlist-webapp/target/gearlist-webapp-1.0-SNAPSHOT.war
app.context                 = ROOT
 
# Database fixtures
fixture.restart_application = false
fixture.file                = classpath:/database-fixture.xml
 
 
# Application configuration (not used by the functional test runner)
db.driver                   = com.mysql.jdbc.Driver
db.host                     = localhost
db.name                     = gearlist_func_test
db.url                      = jdbc:mysql://${db.host}/${db.name}
db.username                 = root
db.password                 =

Property values can reference other properties (e.g. db.url) and they’re all set as system properties so it’s easy to override your application properties for functional testing.

Both the database fixture loading and the application server steps can be customized by plugging in a new DatabaseFixtureLoader or ApplicationServerManager, respectively.

Since it’s a JUnit extension, functional tests run exactly the same whether they’re triggered from the IDE or the command line. This approach is a response to how clunky it felt using Maven to launch the application server before running the tests. Also, with only one master orchestrator, it’s easier to handle redeploying the application if necessary.

Want to see a real example? I’ve written a sample application called “gearlist” that’s available via public svn (press cancel if asked for authentication credentials). It includes several HtmlUnit and Selenium functional tests, as well as other types of tests using some of the other test utils I’ve written. Look for the readme for details.

Carbon Five Test Support is hosted on google code, where you can read what documentation there is and peruse the source.

There are a few things to work on, including better exception handling during initialization and some flexibility around the Cargo configuration, however, it’s pretty stable and there’s no reason not to use it now. Give it it try and give me your feedback. The plan is to tighten it up and write some documentation for the 0.9.2 release.

http://ndpsoftware.com/agile_methods/agile_methods.html

Hint: Try dragging around the boxes to see how practices are related to each other.

Warning: If it doesn’t draw anything interesting for you, refresh your browser… there’s a large component of “randomness” to the algorithm and it can get stuck easily.

Warning II: Don’t leave it running in your browser, as it’s somewhat sluggish Javascript… this was a demo thrown together in a couple hours.

I’ll be down in Palo Alto speaking about Automated Web Application Testing Tuesday October 6th. If you’re interest in getting a peek at the typical Carbon Five Java web architecture along with a variety of strategies and techniques for testing, c’mon down and join us. The session will be primarily code-driven. I’ll implement a few features along with unit, integration and functional tests and show off some of the techniques and custom tools that help keep things simple and easy during development. Some of the topics include:

• Brief overview of our typical web architecture and tools stack
• Differences between Unit, Integration and Functional Tests
• Dealing with the database (schema and fixtures)
• Where does test coverage pay off the most?
• In-browser and out-of-browser functional testing
• Carbon Five best practices, custom tools and techniques
• And more…

You can find the gritty details on the SDForum site.

Doors at 6:30 and the show begins at 7:00. Hope to see you there!

Here are the artifacts from the presentation:

• Presentation (.pdf)
• Source Code (svn)
• Build and Run Instructions (readme.txt)

It has been very well received with TechCrunch claiming it the best way to use Aardvark and 4 1/2 stars from over 100 ratings in just a couple days.

Working on this project with the Aardvark team was great. We love their intensely user-driven approach for designing and validating features through iterative development. We also pioneered our own best practices for test driven development to the iPhone platform, something that seems to be rare in the iPhone development community.

There’s great stuff about cheap and fast prototyping and testing techniques, building feedback loops in to product design, and how to come up with emerging product definition that can drive an iterative software development process.

SXSW weights community input heavily in its panel selection process. Take a moment to give our proposal a thumbs up.

I setup a set of styling rules using UniversalIndentGUI’s live preview and saved the resulting config file. I was then able to add a set of custom user scripts in Xcode to run Uncrustify against the current file or selection. I found that I had to specify the source as objective-c to prevent Uncrustify form running some C/C++ styling rules which I did not want.

Uncrustify custom scripts in Xcode

#!/bin/sh
 
~/Applications/UniversalIndentGUI/indenters/uncrustify -l OC -q -c ~/Applications/UniversalIndentGUI/config/uncrustify_obj_c.cfg

Now I can quickly clean up most of the minor formatting inconsistencies which creep into my code. Now I just need to polish my config file until it better matches my expectations for code formatting. In defining my preferred code style I have tried to follow the example provided by:

• Coding Guidelines for Cocoa
• Google Objective-C Style Guide
• Cocoa Style for Objective-C

My current config file for Uncrustify is available here: uncrustify_obj_c.cfg if you would like to use it as a starting point.

Resizing a view’s frame

One option is certainly to implement Apple’s example code and resize the view’s frame based on the dimensions of the keyboard every time the keyboard is shown or hidden.

Resizing a view’s frame with a reference view

When working with complex views, especially views that support rotation, I have found it convenient to add an extra empty view to my xib files to serve as a reference. I set this reference view to the dimensions I want my resizable view to match when the keyboard is hidden. I can then resize my view relative to this constant frame and not need to worry about reversing my resize calculations when the keyboard is hidden.

Setting UIScrollView’s inset properties

When working with a scroll view (or table view) I’ve found that the best option is to set the view’s content and scroll inset properties. Since this does not change the scroll view’s frame it eliminates the flicker the view resizing as the keyboard is dismissed (notable if the scroll view’s parent view has a different background color).

Example code

Examples of all three techniques are available as an Xcode project at http://svn.carbonfive.com/public/jonah/ManagingKeyboardExample/