[enoptix]

I echo his sentiment. Integration testing, especially when you have a JS frontend, makes much more sense. I never saw the point of controller tests and making sure a controller assigns variable @widgets with [widget] and all that nonsense. An integration test will identify all those problems and then some.

[jon-wood]

For my use case (building a reasonably complicated e-commerce platform) I find that the sweet spot tends to be integration testing to make sure the frontend is spitting out the right thing when going through the whole stack, and unit testing to make sure the correct logic is being applied when performing particular operations.

That combination allows reasonably fast unit testing, because database interaction is stubbed out for that level, which gives a decent level of confidence that nothing major has been broken within a few seconds, and then a longer 10-15 minute integration test suite which checks the stack works as a whole.

[sjtgraham]

I agree. Instance variable assignment is an implementation detail, IMO it's more useful to describe their behaviour with a request spec for example.

[enoptix]

Yes, exactly. We use request specs to test regular HTTP requests to regular pages or our API. And then we use feature tests with Capybara and PhantomJS to load the app, click through it, and make it loads as it would in a customer's browser. This covers most of our application. And then we use regular unit tests for anything not customer facing, such as background jobs. But these unit tests make up only a small fraction of our test suite.

[lmm]

The point is to be able to unit-test business logic in the controller. If your app is just dumb crud end-to-end then sure, there's no point in anything but integration tests (and maybe not even those), but if you have any interesting logic then you can get much better coverage more efficiently in a unit test than having to run through the whole stack every time.