> I only meant not to have a separate test (see the following example) only for the flash message

No offense, while I agree with you one the one hand (there is a certain noise) it is one opinion about how to write best practice tests. 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? See my changes.

> To complete the scenario, there should be a test case for a user that does exists, but fails to authenticate with wrong credentials.

I am curious. 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? I mean if it works as supposed there is no case in which one of these two tests could ever fail or am I wrong here? Or to put it differently: I want to test that the controller handles 'not authenticated' so it doesn't matter from the actions point of view as long as .authenticate returns false.

```ruby
context "not authenticated" do
  context "as a guest" do
    it "redirects to root URL and displays an error message" do
      post 'create', email: 'wrong', password: 'login'
      expect(cookies[:auth_token]).to be_nil
      expect(cookies.permanent[:auth_token]).to be_nil
      expect(response).to redirect_to root_path
      expect(flash[:error]).to eq 'Email or password is invalid.'
    end

  context "as an existiing authenticateable user" do
    it "redirects to root URL and displays an error message" do
      user = FactoryGirl.create :user
      post 'create', email: 'wrong', password: 'login'
      expect(cookies[:auth_token]).to be_nil
      expect(cookies.permanent[:auth_token]).to be_nil
      expect(response).to redirect_to root_path
      expect(flash[:error]).to eq 'Email or password is invalid.'
    end
  end
```
The only difference I see is the set up factory.