As to whether using two different tools for the same cucumber features depends on the test domain and which suits it best. If Watir-webdriver suits front-end testing better than Capybara-webdriver, or vice versa. You'd need to invest some time investigating Capybara (a design spike, to use Agile parlance) to compare it to what you're used to. Try to be objective, even though it's very difficult (in my experience) with a familiar framework, and then do a Cost Benefit Analysis of changing. The direct Cost may only be time/effort but it's still a cost which can impact project delivery.
Capybara is not incompatible with DRY programming - an abstraction layer (like Abe mentions in his reply) is possible with Capybara's custom selectors. Once these have been created, you can use capybara finders and matchers on your custom selectors like so;
Capybara.add_selector(:slide_show) do
xpath { ".//div[contains(@class,'slideshow')]" }
end
Capybara.add_selector(:slide_show_element) do
xpath { ".//div[contains(@class,'slideshowelem')]" }
end
allows you to use Capybara's find;
find(:slide_show_element, 'Sunset').click
From the Cucumber perspective it's possible to pass that locator string through from the step;
And I Click "Sunset" in the "Holiday Pictures" Slide Show
through a step definition like this;
Given /^(?:I |)Click "(.*?)" in the "(.*?)" Slide Show$/i do |picture,slideshow|
within(:slide_show, slideshow) do
find(:slide_show_element, picture).click
end
end
So, the question remains one of process - is having two frameworks impacting your workflow? And would reconciling the two involve an unacceptable loss of time?