> I usually go with one-assertion-per-test-opinion. But I will follow your approach. How do you want to handle the naming of the tests?

I understand the notion and, yes, I'll vote for it in unit tests. In controller and even more so: in feature tests, having such fine-grained tests makes your tests expensive. Consider the `DELETE destroy` tests: for each of the three tests you need to setup and create the world anew. If you have a fat factory, you'll hit the database quite hard (for a test that is) and you'll get little regression value out of the separated example that checks for the existence of a flash message.

I think it's a good way to describe your tests verbosely when you test-drive your feature, but you can condense them later. As for the naming: I wouldn't name every single aspect of what the action under test does in my `it`. I don't consider displaying a flash message as an integral part of the feature, but one you might as well check for while you're at it.

> Would this be necessary or does it add value? I just think that although there definitly are these two use cases isn't that something that belongs to the .authenticate - ducktype?

The added value would be that the displayed error message is also an unrevealing "Email or password is invalid" as opposed to "Password incorrect". I partly agree that the core functionality is covered by `User.authenticate`, but it's an integration test and so you're double-testing things anyway.

> The only difference I see is the set up factory.

Correct. So how would you DRY it up? :wink: