After an OS X upgrade from 10.8 to 10.9, I noticed some previously-passing Capybara specs were failing. The failing specs all shared a similar structure:
it 'should show some text in the 2nd tr' do
visit some_path
page.should have_selector('tr:nth-child(2)', text: 'some text')
end
Notice nth-child pseudo-selector; this seemed likely to be involved as other specs using have_selector with plain class selectors continued to pass.
I applied a number of patches that folks seem to be performing on their new 10.9 installs (installed XCode 5.0.1 and then dev tools via xcode-select --install, running brew updates, etc) and nothing changed. What led me to a solution was this Nokogiri Github issue from the Mountain Lion release:
https://github.com/sparklemotion/nokogiri/issues/742
I ran one of my failing specs with the DYLD_PRINT_LIBRARIES=1 flag mentioned in this issue:
dyld: loaded: /usr/lib/libxml2.2.dylib
dyld: loaded: [repo]/vendor/ruby/1.9.1/gems/nokogiri-1.6.0/ports/x86_64-apple-darwin13.0.0/libxml2/2.8.0/lib/libxml2.2.dylib
As the issue suggests, I added a reference to Nokogiri directly below Rails in my Gemfile (it did not have an explicit reference in the Gemfile before this). After that, I see this load order:
dyld: loaded: [repo]/vendor/ruby/1.9.1/gems/nokogiri-1.6.0/ports/x86_64-apple-darwin13.0.0/libxml2/2.8.0/lib/libxml2.2.dylib
dyld: loaded: /usr/lib/libxml2.2.dylib
With the libxml dylib loaded first from the bundled Nokogiri, my specs pass again.
Continue Reading