■プログラミング学習
◎テストコード
アプリケーションの機能を実装したら、正しく想定道理に動くかを自分でブラウザを操作して確認をしてきました。しかしそれ以外の確認方法もあります。
それは動作を確認するためのコードを書いて、そのコードを実行し、自動で確認する「テストコード」と呼ばれる方法です。
RspecはRuby on Railsのテストコードを書くために用いられるGemです。
なぜ、テストコードを書く必要があるのか。
ブラウザでの確認ではだめなのか。
◎テストコードを書く意義
・クオリティの担保が出来る
人為的ミスの削減、仕様が変わったときの全部やらなくてよい、チェックリストのログが残る
・仕様を見極めることが出来る
テスト項目を見ることで、仕様の確認ができる。
テストコードは「何を確認したいのか」を意識して作成をしていく。
◎テストコードのパターン
アプリケーションの挙動を確認するときは「うまくいくとき」「うまくいかないとき」
をそれぞれ確認する。
前者を「正常系」、後者を「異常系」と呼びます。
正常系・・「ユーザーが開発者の意図する操作を行ったときの挙動」を確認するテストコードが正常系（詳細は次回以降）
異常系・・「ユーザーが開発者の意図しない操作を行ったときの挙動」を確認するテストコードが異常系に分類されます。
たとえば、必須項目を入力せずに送信されたときに、「必須項目」を入力してくださいというアラート画面がでます。この挙動を確認することは異常系に分類されます。
◎テストコードの種類
テストコードの種類は大きく2つに分類されます。
「単体テストコード」と「結合テストコード」の2つです。
単体テストコード・・モデルやコントローラーなどの機能ごとに問題がないかを確かめます。
結合テストコード・・ユーザーがブラウザで操作する一連の流れを再現して、問題がないか確かめます。
■読書 外資系コンサルの知的生産術～プロだけが知る「99の心得」～ 山口 周
◎アウトプット
アウトプットについての章では、
行動をさせることが目的のため「レス・イズ・モア＝少ないほどいい」
が個人的には、とても大切なことと思いました。
どうしても資料は、色んな情報を詰め込みがちになってしまい、
大切なことに絞ろうと思っていても、文字や情報が増えていってしまうことがあるため
この意識を忘れないようにしたいです。
アウトプットの形は「What」「Why」「How」の要素を備えているかと、状況に応じて、それぞれの説明の割合や順番によって、相手を動かし方が変わるというのも新しい気付きだったため、状況に応じて使い分けをしていく。
そして説得より納得を、納得よりも共感をというのが、相手に動いてもらう上で、とても重要だなと思い、そこは意識していくべきだと思いました。
相手からの質問は質問という名の反対意見や懸念表明であることが多いため、回答をするよりも質問で返して、相手の懸念や反対意見を良質なインプットが得られる可能性があるというのためになりました。
次回は知的ストックを厚くするになります。
