Executive Summary: Wherein the cunning, dapper, and incredibly well-shod hillbilly adeptly and skillfully solves one of the enduring and endearing mysteries of the universe: Why the &*%$ does the first cucumber scenario in the CI build for our GWT app get ignored whenever we run against devmode?

In my recent post on configuring UI tests to run against devmode for a GWT/AppEngine app in TeamCity, I left out an annoying annoyance that has been annoying me for an annoyingly long time. (Let me know when that gets annoying.)

The annoyance: The first scenario would always get ignored.

What made it annoying:

  • Didn’t matter which scenario was first. The first one run would always be ignored
  • It only happened when running against devmode. When we configured to run against our deployed server, it worked fine
  • We couldn’t duplicate locally or even when we logged into the TeamCity server

My initial theory was that it was running the tests too soon and that devmode hadn’t had time to spin up yet. But adding a delay did nossing, Lebowski. NOSSING!

Next step was to create a work-around: a dummy scenario. Ran into an issue in that any ignored steps cause the build to fail, even if all other steps succeed. No matter, we could just make the scenario empty. No steps means none ignored. Except that the build still failed:

image

So this weekend was declared “No more ignorance*” weekend.

The culprit

This line of code in our capybara.rb set up:

Capybara.register_driver :selenium do |app|

    Capybara::Driver::Selenium.new(app, 
        {:browser => :firefox, :profile => 'selenium' } )

end if Capybara.app_host.include? "127.0.0.1"

Which looks obvious in retrospect.

We have a separate profile created in Firefox to run our UI tests. This is because we don't necessarily want things like auto-updates to interfere. Can't take credit for this idea. It comes from Google's page on the subject.

The fix should have been easy: set up a "selenium" profile on the server. But the build agent for our UI tests is running under the local system account. This is not recommended but if I put it under another account, I lose the "desktop interactivity" aspect. That is, I can physically see what's going on while the tests are running if the agent runs under local system account with the appropriate checkbox checked.

It ain't a quick jaunt setting up a Firefox profile for the local system account. You need to be able to Run As... the system account first which involves a separate tool. You also need to realize that you can't launch the Firefox ProfileManager while Firefox is actually running. If you do, you'll just get another instance of Firefox.

Once you do have the appropriate profile created, no more ignored tests to deal with! Just failing ones...

Kyle the Elevated

*Lack of ignorance not guaranteed. The Coding Hillbilly will not be held responsible for any lingering ignorance experienced by you and/or the ignoramuses you call friends.