自分用アウトプット2020/12/05

githubの使い方

*ファイルやディレクトリの変更修正をリポジロリに反映させることをcommitという
*変更をリモートリポジトリに反映さ出ることをpushという
*変更修正を一時的に記録しておく場所のことをindexという
*溜まった変更修正の中から追加するコミットを選択することをアドという

コミットは細かく分けるほうがエラーが起きた時にわかりやすいだけでなく、作業の進捗も管理しやすい。
作業完了ごとに逐一コミットの操作をするのは効率が悪いため、インデックスとアドを利用する

githubを開発に用いる際のフローチャート

1.ブランチを切る
2.ローカルリポジトリにコミットする
3.リモートリポジトリにプッシュする
4.プルリクエストを作成する
5.レビュアーがチェック
6.修正依頼
7.修正
8.レビュアーがlgtm
9.リモートリポジトリのマスターブランチにマージ
10.ローカルリポジトリのマスターブランチにぷる

問題がなければ6.7は省く

コンフリクト

ブランチごとに違う作業を行なったことでファイルに辻褄が合わなくなることをコンフリクトという。例えばコントローラーファイルを同時に編集し、一人はindexアクションを追加し、もう一人はdestroyアクションを追加した場合などに起こる。
この場合、お互いのファイルに存在しないアクションが生まれてしまう。

コンフリクトをなるべく回避するために

*作業の前にマスターブランチからpullを行う
*無闇に同じファイルを編集しないようにメンバーと連絡を取り合いながら作業する
*あらかじめコンフリクトが起きそうな場所を把握しておく

リヴァー

間違えてpushしたコミットを取り消すことができる。
コミットを修正するというよりも、間違えたコミットと逆の作業を行なったコミットを追加するイメージ。

テスト

*単体テストはモデルやコントローラーなどの機能ごとに問題がないか確かめる
*結合テストはユーザーがブラウザで操作する一連の流れを試して問題がないか確かめる。
*ユーザーが開発者の意図する操作を行った時の挙動を確認するテストを正常系という
*ユーザーが開発者の意図しない操作を行った時の挙動江尾かっ九人するテストを異常系という

以下は異常系の単体テストの例

RSpec.describe User, type: :model do
  describe '新規登録' do
    it "nameが空だと登録できない" do
      user = User.new(name: "", email: "kkk@kkk", password: "00000000", password_confirmation: "00000000")
      user.valid?
      expect(user.errors.full_messages).to include("Nickname can't be blank")
    end
    it "passwordが空だと登録できない" do
      user = User.new(name: "hiro", email: "kkk@kkk", password: "", password_confirmation: "00000000")
      user.valid?
      expect(user.errors.full_messages).to include("Password can't be blank")
    end
  end
end

異常系のテストの流れ

1.保存するデータを作成する
2.作成したデータが、正しく保存されるかどうかを確認する
3.正しく保存されない場合、生成されるエラーメッセージが期待されるものかどうかを確認する

it

どのような結果になるか試しているのかを記述する

examaple

itに記述した名用の総称

expect(X).to eq Y

結果がXになることを期待してYと比較する

マッチャ

includeはマッチャの一種。Yの内容がXに含まれているか判定する
他にはeqなどがある

.errorsメソッド

エラーを表示するためのメソッド

.full_messagesメソッド

生成されたエラーの中からエラーメッセージを出力するためのメソッド

valid?

データが正しく保存される場合はtrueをそうではない場合はfalseを戻り値として返す