rails-tutorial第3章

###branchについて
$ git branch
これにより今いるブランチを確認することができる。基本的にmasterブランチは常に安定しなければいけないので、新規機能を作るときは必ずブランチを切る。

$ git checkout -b static-pages
-bはブランチを切るということ。このコマンドにより、masterブランチから離れる。

###コントローラー
$ rails generate controller StaticPages home help
上記はStaticPagesコントローラーを作りhomeアクションとhelpアクションを追加する。さらにそれに対応するviewやテストを用意するという意味。また、rails g controllerコマンドは必ずコントローラー名を複数形にして書くこと。


###テストについて
```
require 'test_helper'

class StaticPagesControllerTest < ActionDispatch::IntegrationTest
  test "should get home" do
    get static_pages_home_url
    assert_response :success
  end

  test "should get help" do
    get static_pages_help_url
    assert_response :success
  end

end
```
上記はrails g controllerコマンドを使うと自動生成されるテストコード。
スクリプト言語とテストは切っても切り離せない。

```
test "should get home" do
    get static_pages_home_url
    assert_response :success
  end
```
例えば上記は
get static_pages_home_url：static_pagesコントローラーのhomeアクションにリクエストを送った時に、
assert_response :success ：必ずなんらかのレスポンスが返ってくるはずだという意味。

ちなみにテスト駆動開発は、まずあるべき姿をテストコードで書く。テスト失敗する。テストが成功するようにコードを足していく、そしてリファクタリングを行うというスタイル。


staticpagesコントローラのタイトルをテストしてみよう

```
require 'test_helper'

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

  test "should get home" do
    get static_pages_home_url
    assert_response :success
    assert_select "title", "Home | Ruby on Rails Tutorial Sample App"
  end

  test "should get help" do
    get static_pages_help_url
    assert_response :success
    assert_select "title", "Help | Ruby on Rails Tutorial Sample App"
  end

  test "should get about" do
    get static_pages_about_url
    assert_response :success
    assert_select "title", "About | Ruby on Rails Tutorial Sample App"
  end
end
```

書くテスト3行目に足されたのは、
assert_selectはそのページのセレクトタグの中は以下のようになってますか？というもの

```
3) Failure:
StaticPagesControllerTest#test_should_get_home [/home/ec2-user/environment/sample_app/test/controllers/static_pages_controller_test.rb:8]:
<Home | Ruby on Rails Tutorial Sample App> expected but was
<SampleApp>..
Expected 0 to be >= 1.

3 runs, 6 assertions, 3 failures, 0 errors, 0 skips
```
ちなみにテストを実行した結果。
最後の行は3つのテストが走って、6つのアサーションがある中で、3つが失敗したよーって意味。

###初めてのリファクタリング

```
<% provide(:title, "Home") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Sample App</h1>
    <p>
      This is the home page for the
      <a href="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>
```
<% provide(:title, "Home") %>この部分は:titleに"Home"を代入している。
<title><%= yield(:title) %>はtitleをyieldメソッドで引っ張ってきてるという意味。

これにより、provideメソッドを除く、ドクタイプ宣言からheadタグまでが共通化できた、というかbodyタグの内側以外は全部同じなので外側にまとめようってこと。
<%=yield%>の中に各テンプレートが代入されるので、各テンプレートはbodyタグの内側だけ書いていれば良い。

その結果application.html.erbに共通のコードをまとめる。

```
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
    <%= csrf_meta_tags %>

    <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>
```
yield(:title)のtitleは各テンプレートから引っ張ってくるよーってこと。


###branch のマージ
トピックブランチで作業したら最後にmasterブランチにマージしてあげる必要がある。

トピックブランチ内で
$ git add -A
$ git commit -m "Finish static pages"

$ git checkout master
ここでマスターブランチに移動。この時点でgit logをしてもトピックブランチで設定したコミットメッセージは表示されない。
$ git merge static-pages
これでトピックブランチの内容をmasterブランチに反映できる。

この状態でgit push heroku master を実行すればデプロイできる。


###minitest reporters
railstestでgreenやredを表示するときの設定

```test/test_helper.rb
ENV['RAILS_ENV'] ||= 'test'
require File.expand_path('../../config/environment', __FILE__)
require 'rails/test_help'
require "minitest/reporters"
Minitest::Reporters.use!

class ActiveSupport::TestCase
  # Setup all fixtures in test/fixtures/*.yml for all tests
  # in alphabetical order.
  fixtures :all

  # Add more helper methods to be used by all tests here...
end
```

require 'minitest/reporters'
Minitest::Reporters.user!
この2行を追加する。

###Guardによるテストの自動化

guardは何かファイルが更新されたら〜〜の処理を実行するというもの。
これをminitestと合わせると、ファイルを変えた時に勝手にテストを実行してくれる。

1.$ bundle exec guard init
を実行して初期化する。

2.$ sudo yum install -y tmux 
cloud9の場合のコマンド。これによりguardの通知を受け取るのに必要なtmuxを有効にする。

3.生成されたguardfileの先頭の行に
guard :minitest, spring: "bin/rails test", all_on_start: false do
を加える。

4.gitignoreの最後の行に

```
# Ignore Spring files.
/spring/*.pid
```
を加える。

5.bundle exec guardを実行する。