TECH EXPERT 17日目 テストコード
テストコードでよく使う記述
describe ＃どんなテストコードかいてんの？
「〇〇について記述する」do~endの間に記述し、入れ子構造可能。
it ＃こうなるはず
「どのような結果になることを試しているのか」do~endの間に記述し、入れ子構造なし。
example
上記のitに記述した内容の総称、itに書く、「こうなるはず」の例。
expect(X).to eq Y ＃Xの結果はYなん？
eqのように結果を判断するものを、マッチャという。
context ＃どんな時を確認したいん？
特定の条件を分けたい場合に用いる。使用方法はdescribeと同じ。
どのような「状況」を確認したいのか
expect(インスタンス).to be_valid ＃インスタンス機能してるん？
expectのインスタンスが正しく保存されることを判断
expect(X).to include(Y) マッチャ
「Xの中にYという文字列が含まれているかどうか」
マッチャ
expectの中の記述と、結果とのつながりを示す表現。
eqの場合は「XがYに等しくなる」を表現。
テストコードではマッチャを使用して期待通りの結果かどうか判断する。
正しい場合は緑色、正しくない場合は赤色
RSpecのテストコードを実行する際は、bundle exec rspec のコマンド
流れ
保存するデータの作成。
↓
作成したデータが、正しく保存されるかどうかを確認する。
↓
正しく保存されない場合、生成されるエラーメッセージが期待されるものかどうかを確認する。
binding.pry：コードの中に打つことで、一度プログラム処理が止まり、その時点におけるコードの状態をみることができる。確認したい変数の直後に入れるようにします。
なんのパラメータが適応されてるか、わからない時も使える便利マン。
ターミナル実行 bundle exec rspec spec ファイル名
〇〇.valid? 〇〇.errors 〇〇.errors.full_message を活用。
（保存できんの？） ←のエラー表示 ←のエラー文表示
〇〇に自分が調べたい変数をかく、変数だけ実行ならその中身が表示される。
（例：user)
ーテストコードの効率化ー
FactoryBot インスタンス生成をまとめる テストコードで使う
factory :user do ＜spec/factories/users.rb に記述 ＃インスタンスの設定
＃処理
↓
FactoryBot .build(:user) ＜spec/models/user_spec.rb に記述 ＃User のインスタンス生成
before 共通した記述を切り出す
テストコード実行前にFactoryBot .build(:user)を
セットアップする感じ※インスタンス変数にする必要あり。
before do
@user=FactoryBot.build(:user)
Faker ランダムな値の生成 Gem
固定値をランダム化に （メルアド重複などで弾かれるケース考慮）spec/factories/users.rb に編集
追記
contextはどのような「状況」を確認したいのかをdescribeにネストして書く。
be_validを使用して、インスタンスが正しく保存されるか判断できる。
tweets.rb編集時は association :user を追記 （users.rbのFactoryBotとアソシエーションがあることを意味）
TECH EXPERT 16日目 テストコード心構え 事前準備
テストコードまとめ
アプリケーションの挙動はテストコードを実行することで確認できる。
RSpec（アールスペック）：Ruby on Railsでテストコードを書く際、使用することが多いGem。
テストコードを書くことの意義：アプリケーションの品質が担保されるだけではなく、設計を読み解くこともできる。仕様の理解ができるのはでかい。
テストコードは正常系（開発者が意図したユーザー操作）と異常系（開発者が意図しなかったユーザー操作）に大きく分類され、
単体テストコード（モデルや、コントローラーごとに問題がないか）と、結合テストコード（ユーザーがの操作する一連の流れを再現して問題がないか）の2種類がある。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
テストコードで重要なのは
「自身が今アプリケーションの何をテスト確認したいのか把握すること。」
（細かい記述、コードの意味などは調べれば出てくる）
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
事前準備 Rspecの導入
Gimファイル編集
ターミナルでインストール
Rspecの設定 ％ rails g rspec:install コマンド 記述場所生成
.rspecファイルに --format documentation を追加 テストコードの結果をターミナルで可視化。
TECH EXPERT 16日目 GItHub
GItHub まとめ
Git ソースコードのバージョン管理システム。セーブポイントの作成。
GItHub Gitを利用して簡単に複数人で開発ができるツール。
ローカルリポジトリ 自分の箱
リモートリポジトリ 世界の箱
コミット ：ファイルやディレクトリの変更修正を、リポジトリに記録
コミットログ：今まで行ったcommitの履歴が確認できる GitHubDesktop左上History
プッシュ：ローカルリポジトリでのコミットをリモートリポジトリに反映させる操作
例 ユーザー管理が目的でルーティングを編集してコミット
ユーザー管理が目的でコントローラーを編集してコミット。
など細かいコミットをすることで作業の進捗を管理できる。
エラーが起こった際に、どの作業が原因かスムーズに切り分けできる。
いちいちするのは面倒
ある程度まとめて作業をしてから、分けてコミットをすれば効率が良く下記を理解する。
インデックス：変更修正が一時的に保存される場所。 箱 コミットの対象
アド：追加ファイル、変更箇所をインデックスに追加してコミットの対象にすること。
梱包した（アド）数種類の段ボール（インデックス）をコミットで発送するイメージ。
GitHub複数人開発のついて
ごちゃごちゃしてるが
本流とは別に副流、があるので複数人で作業可能。
メンバーからの校正、ローカルまたリモートへの反映、分岐前に戻るが可能。
（プッシュとプル）
プログラマーにおいて一番大事なのはコミュニケーション能力であると
考えさせられた。
ここでのコミュニケーション能力は対人会話能力とかじゃなくて、
自身から発信をして相手の意見を尊重し取り入れる能力でFAです。
ブランチ：リポジトリで管理しているファイルやディレクトリの流れを記録していく場所
メリット
・リポジトリで管理しているファイルやディレクトリの本流に影響を与えずに作業ができること
・ブランチを切ることで目的別に同時並行で作業が行えること
・不具合が発生した場合も対応が容易になること
プルリクエスト：ブランチでのコミット履歴を残すと共に、各コミットにおける変更修正にコメントをつけることができる機能のこと。
プルリクエストの詳細には、What（何を）とWhy（なぜ）を書く マークダウン形式
対人なのでわかりやすさを意識する。
コードレビュー：複数人での開発においては、コードの記述内容に問題がないか、他の開発メンバー等にレビューを依頼すること
LGTM：Looks good to meの略 問題なしという意味。
merge（マージ）：機能実装のために作成したブランチを、リモートリポジトリ上のmasterブランチに統合する作業
pull（プル）：リモートリポジトリの変更をローカルリポジトリに取り込む操作のこと。
git cloneコマンド：リモートリポジトリを自分のパソコンにダウンロードするコマンド。
% git clone https://github.com/username/git-app.git
リモートリポジトリのURLに.gitを加えた文字列指定
他人のものは勝手にプッシュできない。
ブランチ作成忘れの場合
ブランチを作成することを忘れてコードを書き進めてしまった場合、ブランチを作成したら Bring my changes to ブランチ名 を選択する。 引継ぎできる。
stash：現在の作業を一時的に退避したい時、退避した作業を元に戻したい時などに使用するものである。
Leave my changes on master の場合の保留ブランチ
コンフリクトの場合 複数人作成時のファイル矛盾エラー
コンフリクト：あるファイルにおいてブランチごとに情報が異なり辻褄が合わない状況。
マージの際エラー発生→マスターの修正、またどちらかのブランチ記述の削除
まずコンフリクトを起こさないように
・ブランチ作業前にマスターブランチのプルを行う。
・複数人での作業時は打ち合わせ、コミュニケーションをとって作業。
（無闇に同じファイルで作業しない、被りそうな記述箇所は事前に確認）
誤った情報をpushしてしまった場合
解：リモートリポジトリのコミットは打ち消せる。
revert：誤ったcommitを打ち消すこと。GitHubDesktopの「History」から処理。
間違ったコミットはpush前なら undoで削除可能。
✴︎リモートリポジトリの確認方法
$ git remote -v コマンドでURLを確認できる。
TECH EXPERT 15日目②
TECH EXPERT 15日目
紙は嵩張るので。ブログ中心にメモしていこうかと思います。
気付き
自分が今してる作業、作業場所（モデルやらコントロラーやら）
の把握を意識して開発を進めることで
言語化しやすくなる。
部分テンプレート
コードの記述で繰り返してる部分を1つのファイルのまとめる方法
ファイル名 ＿〇〇.html.erb
メリット 管理しやすい 修正が楽
Rubyの繰り返す処理のメソッド化と考えは同じ
ファイル作成後↓
render メソッドで呼び出し
renderメソッドのオプション
partian:ファイル名の指定 ＃どこに有るの 明確化
locals:部分テンプレート内での変数を定義 #この変数使ってね
アソシエーション
モデル同士の関連付け
複数のモデルから情報が必要な場合、下記のメソッドをモデルに記述することで関連ずけ
例：コメント機能 コメントを誰かの投稿に呟く
コメントモデル ユーザーモデル ツイートモデルの 結びつきがいる
has_many メソッド モデル目線から考えて１対多の時に使う
belong_to メソッド モデル目線から考えて多対１の時使う
例 １人のユーザーは多くのツイートを所有する。
ユーザー目線は１対多 ツイート目線は 多対１
ネスト do下に子要素
入子構造 有る記述の中に別の記述を入れる
”あるツイートに対してのコメント”：ツイートの中にコメントが入ってるという親子関係
使わないとモデルとアソシエーションしている別モデルのid情報が返せない
ビジネスロジック
データに関する処理をするプログラム
どのようにデータを処理するのか
どのデータを取得するかなど
意識すべき点は テーブルとのやりとりに関するメソッドはモデルに記述するということ
search アクション doをメソッド後ろに記載
ルーティングの設定時
collection :idがつかない 検索窓フリー検索など
member :idがつく 特定のページを指定
where メソッド ＃データベースからどんなの探すの？
使い方： モデル.where('検索対象となるカラムを含む条件式’）
モデルに記載 ビジネスロジックに関わるから
アプリケーション開発の流れ(全体像）
企画→要件定義→設計→開発→保守、運用
設計{
1 基本設計
要件定義の内容を、開発に必要な内容へまとめること
画面 画面の変わり方など
↓
2 詳細設計
実際に書くべきコードを洗い出す作業
要件定義や基本設計の情報を元に、ユーザーが行う操作(ボタンを押す）に対して行われる処理を全て書き出す
記憶の定着について、クライアントへのアプリケーション開発の視点から
こんにちは frappe（フラッペ） です＾＾
本日は記憶の定着×アプリケーションという発信をいたします＾＾
私が通っているプログラミングスクールでは知識を定着させるため、
繰り返し同様の内容を復習する学習方法がありまして。
「知識の定着」という観点でエビングハウスの忘却曲線というものを
ふと思い出しました。下記画像みたいなやつですね
要約すると 人は何かを学んだときに
「１時間後には半分くらい忘れ、最終的に１ヶ月後に８割くらい忘れる」という
ドイツの心理学者 ヘルマン・エビングハウス氏が発表した、
どれだけ時間と共に記憶した事が頭に残ってるかを示したものですね。
市場顧客の欲求的に知識を定着させたいを悩んでる人は少なからずいるでしょうし
アプリケーションでこれを利用したものは一定の需要あるかなと考えたわけですよ。
（学習後に忘却曲線に伴い、アイフォンに通知が来るとか）
先行研究したら、やはりでできまして笑
「忘却曲線で暗記アプリ - reminDO」をApp Storeで
他にも調べたら多分出てきます。
別視点から着目したいのがこれが 暗記アプリ という点で
メモの事柄を定着させるのは便利ですが（実際アイフォンの通知って目を通しますし）
アウトプットが伴う（例を挙げればクロッキーとか、プログラミングとか）
ものには請求力が足りないかもしれない点です。
考え方としてはこれらのリリースしている時間定着学習アプリがカバーできてない
層を分析できれば、ビジネス的には面白いんですが笑
一旦このアプリをダウンロードして使用後に、また別の記事にて続きをまとめてみましょう。
本日はこの辺りで。
最後までお読みいただきありがとうございます。
