kobasaです(´ω｀*)昨日は寝落ちしてしまった…
今日はGitHubの最終カリキュラムとテストコードという新しい内容を勉強しました。
あとは先輩の最終課題発表会を見学してきました！
ビューのデザインに苦戦した、という方が多かった印象。時間とられますもんね。
オリジナルアプリの期間に入ったら有給休暇使って時間つくろうかな?
29日目の勉強内容
GitHubの修正方法
トピックブランチを作成し忘れてマスターブランチにコードを記述してしまった時は、
新しいブランチを作成し、その時に「Bring my changes to 新ブランチ名」を選択すると、変更内容を新しいトピックブランチに移動できる。
コンフリクト
別ブランチの作業が同じファイルを編集してしまい、ファイルの辻褄が会わなくなりマージできなくなってしまうこと。
後からマージしようとした側にコンフリクトが表示されるので、
Resolve conflictsを選択して手動でコードのコンフリクトを修正していく。
複数ファイルがある場合は1つ1つ修正してMark as resolvedを選択する作業を繰り返す。
全て修正し終わったらCommit margeが選択できるようになる。
コンフリクトを発生させないためには、まずプルをして最新のマスターブランチの状態をローカルに反映させること。よく打ち合わせて作業フォルダの確認をすることなどが挙げられる。
Revert
誤った変更をpushしてしまった場合の修正方法。
ヒストリーから変更したcommitを右クリックし、Revert this Commitを選択してPushする。
するとリモートが修正を修正したような形で更新される。
また、誤った変更をcommitしてしまった場合は、commitボタン下部にundoというボタンがあるのでそれを選択する。pushしていなければこれで変更が取り消せる。
テストコード
RailsのテストコードはRSpecというGemを使用して作成するのが一般的である。
アプリの機能を知っていないと詳細なテストコードは書けないので、機能を把握するために新人は最初に任せられることもあるらしい。
記述方法は「ユーザー登録機能」といったある程度の範囲のテスト内容をdescribeメソッドで記述し、
その中にitメソッドを使用して「ユーザー名が空だと登録不可」といった詳細なテスト内容を記述していく。
valid?メソッド：バリデーションを実行させてエラーがなければtrueを、エラーがあればfalseの値とエラーメッセージを生成する。
もちろん事前に実行させるバリデーションをvalidatesメソッドで記述しておく必要がある。
expectationとは検証で得られた挙動が想定通りなのかを確認する構文のこと。
expect().to matcher()を基準とする。テスト内容に応じてどのmatcher(マッチャー)を記述するか決める。
includeマッチャー：expectの引数にincludeの引数が含まれているか確認する。
eqマッチャー：expectの引数とeqの引数が等しいか確認する。
valid?がfalseの時のエラーメッセージは、ターミナルでerrorsメソッドを使用するとわかるが、複雑な情報なのでエラー内容をexpectには取り出せない。
errors.full_messagesと記述すれば、エラーメッセージを配列として取り出せる。
expect(変数.errors.full_messages).to include(エラーメッセージ内容)のように記述することが多い
ターミナルでbundle exec rspec ファイルパスとコマンドを打つとテストすることができる。itメソッドで定義した名前が緑色で表示されればテスト成功となる。
新しい内容に入ると覚えることが一気に増えますね(´･ω･`)
ターミナルの使用頻繁も多くなってきてアプリの切り替えが忙しくなってきました。
コメント