I've never used Cucumber, but a lot of this article seems very familiar. I was working in a C++ desktop app, and we had similar problems with our tests. Some de

I've never used Cucumber, but a lot of this article seems very familiar. I was working in a C++ desktop app, and we had similar problems with our tests. Some developers insisted on thoroughness and would write massive sets of end-to-end tests (in addition to unit tests). Our test suite was rapidly becoming slow and unwieldy. After about 8 months of development, we had around 1000 end-to-end tests, which took an hour to run. That was already painful, but we feared what it would be in a couple years if we kept adding tests at that rate. My solution was to abstract away the things that made it slow and swap in faster components for the tests. Network connections were replaced with in-memory buffers, external programs were pulled into the same executable, and timers were simulated. Bam. The tests compiled in minutes and ran in seconds. People actually ran and listened to the tests because they were fast and reliable. Of course, I was then left with no real end-to-end automated tests. The 'almost end-to-end' tests I had covered most of the software, though, and manual testing was used to catch the rare bug that would slip through. My conclusion was similar to that of the article: if you were going to do real end-to-end testing, you couldn't write very many tests.