- They are a good choice for happy path tests. Sad paths are often times tested elsewhere (e.g., a controller test).
- They are like using a browser (just a headless one) and exercise the entire application stack.
- They are generally slower to run than other types of tests.
- They assert expectations mostly from the user's perspective (e.g., things visible to the user), but will occasionally need to assert an expectation against something only the application knows (e.g.,
Feedback.count)
Strong Params allows us to require and control what data we accept from the browser request's parameters.
feedback = Feedback.new(feedback_params)
...
def feedback_params
params.permit(:feedback).permit(:note)
end
http://edgeguides.rubyonrails.org/action_controller_overview.html#strong-parameters
Adding a binding.pry statement anywhere in the code execution path will stop the execution at that point. It's a great tool for testing and exploring code, checking method return values and variables.
https://github.com/pry/pry/wiki
flash[:notice]flash[:alert]flash.now[:alert] vs flash[:alert]redirect_to some_path, notice: "some notice"shorthand
ActiveRecord validations add constraints to your model (different from the database constraints) to ensure that Rails will only save valid data to the database. Today we use the presence validator, but there are many, many others.
validates :note, presence: true
http://guides.rubyonrails.org/active_record_validations.html
redirect_to some_pathrender :some_action
http://tosbourn.com/difference-between-redirect-render-rails/
render_templateflashpost :create, params: { some values }
https://www.relishapp.com/rspec/rspec-rails/docs/controller-specs