crawfoal / climbalytics Goto Github PK

All the files ending in .html.erb in app/views/boulders

• fill in any gaps
• DRY up stuff

Or maybe don't do this... just make sure to consider this later.

Maybe also scope queries by default (e.g. for boulder logs).

Review what I've done in this application and write a guide that includes things like

• install RSpec, FactoryGirl, Capybara, Selenium, etc
• setting up users, roles, and authorization
• generalize some of the tests and create templates (or even a generator for them)
  Maybe make a rake task to some of this stuff.

Collapse the new password field in "edit user" page.

This will be used to provide a better development experience. It will be easier to design the appearance of the webpages, and the flow through them if we have some realistic data. It can also be used to test data migrations when we get to that point.

Also, review the text fields. Should there be a limit on these fields? I think so, but it should be fairly large.

This makes it so that only the HTTP request type of GET will match the route.

• DRY them up
• apply ideas from books and articles

https://github.com/plataformatec/devise/wiki/How-To:-Display-a-custom-sign_in-form-anywhere-in-your-app

Rails Testing Antipatterns: Controllers

• movement_style (enum)
• hold_types (enum)
• techniques (enum)
• wall angle (enum)

http://testdrivenwebsites.com/2011/08/17/different-ways-of-code-reuse-in-rspec/

http://sass-lang.com/guide
http://willschenk.com/bootstrap-advanced-grid-tricks/
http://www.sitepoint.com/5-useful-sass-mixins-bootstrap/
http://www.hongkiat.com/blog/bootstrap-and-sass/
http://www.cheatography.com/lukas238/cheat-sheets/bootstrap3-sass-mixins/

157-rspec-matchers-macros

It doesn't save (maybe we're ignoring all blank or something?). Additionally, it should clear out current_role.

• Call it "Edit Profile" instead of "Edit User"
• Address issue #21
• Use two columns on sm through lg screens so that we don't have a bunch of whitespace to the right
• Make sure that the "Current password" field and the "Update" button are separated from the rest of the form in a way that makes it obvious that those two items apply to the page as a whole and not just to the last section. E.g. I don't feel like it is obvious that they need to fill this in when changing email.

Do this before / concurrently with #14

• Review the outline in ClimbalyticsPlan.md for the athlete dashboard and add anything else you think would be helpful.
• Modify app/views/users/dashboards/athlete.html.erb to have the basic html structure we'll use for this. For example, say you think we should have each of those three lists in their own wells - make the wells and any headers, etc you think you might need. Eventually, we'll make templates that we can render in each of those wells, below the header (wells/headers are just examples here - you should look around and come up with what you think will look best).

app/views/boulders/index.html.erb

In the code below

describe BouldersController do
  ...
    context 'when the user owns the boulder problem' do
      define_roles(:setter)
      login_user(:setter_user)
      let(:boulder) { current_user.setter_story.boulders.create(attributes_for(:boulder)) }

      it 'deletes the boulder from the database' do
        boulder # lazy evaluation causes this test to fail if the boulder isn't created before the proc below is evaluated
        expect { delete :destroy, id: boulder.id }.to change(Boulder, :count).by(-1)
      end
      it 'redirects to the boulders index' do
        delete :destroy, id: boulder.id
        expect(response).to redirect_to boulders_path
      end
      it 'displays a flash message' do
        delete :destroy, id: boulder.id
        expect(flash[:notice]).to eq 'Boulder was successfully destroyed.'
      end
    end
  ...
end

Can the http request be saved as a lambda, and then this lambda be passed to the expect in the first example? Then the other two could call it before running their expectation. Even better, I should create a shared example for a request that redirects to a specified action and displays a flash message.

https://teamgaslight.com/blog/6-ways-to-remove-pain-from-feature-testing-in-ruby-on-rails

Currently, I'm only using :each because at the time I implemented the tests, I didn't realize you needed to tear down any database changes. In places where it makes more sense to use :all, do so and implement the appropriate after :all block.

I don't think it makes sense to call it there...

http://www.webascender.com/Blog/ID/629/Testing-Rails-4-Apps-With-RSpec-3-Part-II#.VpoHFFMrJPd

Particularly, where it would allow you to use is_expected.to (in the case of the implicit subject). If you use the explicit subject, make sure to name it (don't actually use subject to refer to the subject in the code).

Review the specs for simple examples where the code looks like plain English; use specify instead of it for these. An example of a good candidate (from The Rails 4 Way) is

describe BlogPost do
  let(:blog_post) { BlogPost.new title: 'foo' }

  it "to not be published" do
    expect(blog_post).to_not be_published
  end
end

This could instead be written as

describe BlogPost do
  let(:blog_post) { BlogPost.new title: 'foo' }
  specify { expect(blog_post).to_not be_published }
end

As is discussed in Rails Enum is a Sharp Knife, if you don't explicitly declare the integer "id" then you can run into issues if you a new value to the middle of the list.

Everyday Rails: Model Specs

• should belong to a user
• should be created when user is first assigned a role of "athlete"
• should have many boulder_logs

I can't remember why I did this (I remember having a reason...), but I want to test what happens when an id is passed in the params hash and it matches an id of an existing record (specifically that of one owned by another user during a update action)... is the record updated?

as is done in update_request.rb

We should review the authorizations (e.g. for boulders, boulder_logs...)

For the change matcher, there is the classic example:

expect { BlogPost.create title: 'Hello' }.to change( BlogPost, :count).by( 1)

but I know I could be using this in more cases. Here is just one example (from The Rails 4 Way) to keep in mind:

describe "#publish!" do
  let(:blog_post) { BlogPost.create title: 'Hello' }

  it "updates published_on date" do
    expect { blog_post.publish! }.to change { blog_post.published_on }.from(nil).to(Date.today)
  end
end

http://railscasts.com/episodes/264-guard?autoplay=true

Like #35 but for setters.

• fields for high point, notes, and date (use the auto created column)
• belongs to a boulder_log
• cannot actually be named sessions (devise has a model named that)

I know some of them need to be modified :)

• belongs to an athlete story
• fields for grade, style, rating, notes (private), comments (public), project (a boolean)
• should have many sessions
• when a user first logs a climb (i.e. creates a boulder_log record), the first session should be created (and obviously the date_created will be populated); they can optionally fill in session details

Follow steps as described in Keeping your database in sync with your current branch

Some exceptions could be the outtermost describe block (because it will have the class name), and method name describe blocks. Just look at the output and make sure it is readable.

The homepage is all ready for you! It is on the create-homepage branch, in app > views > home :)

In the edit profile page, the zip code should not have the buttons for incrementing/decrementing a number. It is there because the field is a type of number; we should probably keep the input type on the field as number because I think that this is what makes smart phones pull up the special numbers only keyboard. Instead of changing the input field type, maybe we can just get that decoration/styling aspect to go away?