[gingerlime]

after reading sandi metz POODR[1], I tend to prefer the approach on the post too. However, I also must say that the time it takes to execute unit tests, even with factories, db access etc is still an order of magnitude faster than running things like feature tests with capybara. This is by far the biggest drain on test time (and resources), and these are also the tests most difficult to write and maintain. Way too often, when we decide to change some functionality, there's a whole battle with tweaking capybara tests to work again.

Perhaps I'm showing my lack of knowledge or experience with capybara, or integration testing, but that's one aspect I wish there were some better tools / approaches. Having to dig through css/xpath elements to click on or perform interaction is still a major PITA. If anybody has some suggestions to share, I'd love to learn more!

[1]http://www.poodr.com/

[regularfry]

I think the key here is not to try to aim for anything like full coverage with capybara, just enough to be effective. Martin Fowler has some words on this here: http://martinfowler.com/bliki/TestPyramid.html

[gingerlime]

Thanks for the link. We're pretty much using this pyramid approach intuitively, but just as a single data point - one feature test takes around 15% of the execution of our entire test suite (with around 850 tests). This one test is quite comprehensive and touches the core functionality, but nevertheless suffers from all the negative aspects Martin Fowler mentions.

Were we to improve our unit tests to run even faster, as the post suggests, the difference in execution time will become much more pronounced. several orders of magnitude.

I think feature/UI testing is still an interesting space for better tools, but of course the problem is very difficult to solve.