That's good.  The reason I ask is because the tests look like they may
become brittle.  That means that with a small change in your code, 4 or 5
tests will fail at once.  You don't (shouldn't) test every aspect of what
is to happen.  For instance, look at this test:
    describe "with valid information" do
      let(:user) { FactoryGirl.create(:user) }
      before do
        fill_in "Email",    with: user.email.upcase
        fill_in "Password", with: user.password
        click_button "Sign in"
      end

      it { should have_content("Signed in as:#{user.first_name}
#{user.surname}") }

      it { should have_link('Products',    href: products_path) }

      it { should have_link('Stock',      href: stocks_path) }

      it { should have_link('Orders',      href: "#") }

      it { should have_link('Sign out',    href: signout_path) }

....

The tests themselves are fine, but with a small refactor of your code they
may fail.  Say that you decide that the homepage is not going to contain
these links, if you're hitting a dashboard etc, all of the 'have_link'
tests will fail.  That's what brittle means.  Is there a need to check that
when the user signs in that those links are present, or would it be better
to just check the path?
    describe User do
      let(:user) { FactoryGirl.create(:user) }
      before(:each) do
        fill_in "Email",    with: user.email.upcase
        fill_in "Password", with: user.password
        click_button "Sign in"
      end
      it 'allows user to visit root_path' do
        visit root_path
        current_path.should == root_path   //as oppose to login_path if
signin was successful
      end
      it 'displays stocks page when link is clicked' do
        click_link 'Stocks'
        current_path.should == stocks_path
      end

    end

and so on... You only need to test something that needs testing.  If you go
too deep into checking if the font is the correct size and the margins are
set for each page you will get brittle testing.  Also try to stay away from
things like:

  it { should_not have_content("Signed in as:#{user.first_name}
#{user.surname}") }

You could easily change to "Logged in as ... " and you test will fail.  If
you wish to check if something is on the page the check for the css element:

    page.should have_css('div.signedInContainer')

How I write the tests is a bit dated, i.e. it 'has a big long description
of what it does' do ... vs what you do which is less verbose and, I guess,
more Railsy.  I still like the description, especially if I'm looking back
at the tests 3 months later!!

Lastly, don't forget these are request specs which have the sole purpose of
acting like a user navigating through the app so you are really dealing a
lot with current_path, have_content, have_css and that kind of stuff.  You
still have model specs which is where the heavy lifting is done on checking
all of the logic, search functions and so on.  Good work on the test
though, it's not easy!




On 30 October 2013 20:25, BitGub <notifications@github.com> wrote:

> In spec/requests/authentication_pages_spec.rb:
>
> > @@ -0,0 +1,48 @@
> > +require 'spec_helper'
>
> Referencing the tests from the tut, as I can't remember syntax or format
> for writing some tests. Some of the tests are pretty much identical, some
> are different as I'm not handling certain things the same way as in the
> tutorial. I'm trying not to do copy and paste 'jobbies' with this stuff.
> … <#1420b0a7d2f7a666_>
> Sent from my iPhone
>  On 30 Oct 2013, at 20:09, Mark Kenny <notifications@github.com> wrote:
> In spec/requests/authentication_pages_spec.rb: > @@ -0,0 +1,48 @@ >
> +require 'spec_helper' Did you write the tests from scratch too, or were
> you following the tut? … — Reply to this email directly or view it on
> GitHub.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/BitGub/zucono/pull/5/files#r7324947>
> .
>