社内勉強会のメモ。全然まとまってないけど。
自動テスト
テストを作成することで永久に動作確認ができる
TDD（テスト駆動）
テストの話になると出てくる概念。
「まずは動作確認をするべき」
問題点
- めんどくさい
- モチベーションが上がらない
「ではなぜモチベーションが上がらないのか？」
実装しているタイミングで永久に動く動作確認を作成することは不可能。
<= テストには「寿命」がある
∴実装しているタイミングでテストを頑張る必要はない
コードカバレッジ
=> 完璧にしていくと、疲弊していく
ではどうするか？
BDD
「ふるまい」受け入れ仕様
コード全てに対してテストを書く必要はないが、モジュール単位での動作確認を作成するということは必要
全てにやるのではなく、仕様をかなえるために必要な箇所で要所要所取り入れていこう
例
API->parr、JSON
Page->html、parr
module->引数を与えた時にどういうreturnが帰ってくるのか（ユニットテストと近い関係）
理想と現実
コードカバレッジなどを考慮して完璧を目指すのではなく、BDDのように必要なぶんだけ作成することが現実的。
設計に比べて仕様はまだ安定的であるはず。
=> BDDは仕様に重点をおいているので比較的ラク
phpでBDDするには？
behat/phpspe/codeception
なぜ仕様のテストをするだけなのに、独自のツールが必要なのか？？
受け入れテスト
テストと仕様を紐づける
BDDのテストは仕様そのものなのではないか？
それならテストのコードは読みやすくなければいけない
phpunitを使ったテスト
基本的に assert というのを使う。
- 期待するJSONが返ってくるか
- ステータスが返ってくるか
など
behatなどを使うとどうなる？
shouldBeなど、英語など自然言語に近い書き方
（phpunitはプログラミングっぽい感じ）
「読みやすいコードを書く」というのがコンセプトとなっている
個人的には入らないと思う
読みやすさはなんとかしようぜ
LaravelもBDDをサポートしている
phpunitでどうすればみやすくかけるか？
- シナリオ
- なんども使うものはメソッドにしたりして工夫
など。
codeception等のドキュメントを見てみると参考になる。
「テストには3種類あるのか」など
- どういうテストを用意してあげたらいいのか
- どういう名前のテストを作れば良いのか
E2E
End to End
実際にブラウザを叩いて...
バックエンドにおけるE2Eテスト
JSON、html
client <=> server
※JSはまた全く別物の内容になる
JSの世界でのE2Eテスト
codeとブラウザの話
JSの場合はブラウザで叩く必要がある
「〜のあとにAPIが飛ぶ」とかを試すならduskを使うといい
Jsdom...バーチャルDOMをつくる
LaravelでtestUnitを作ってみよう
$this->assertTrue(true);
を最後の一文に追加して、いろんなモジュール検証のコードを書いてみよう。
テストの中が空っぽだとエラーになるので、この1ぶんだけ追加しておいてあげる。
assert関数はめちゃくちゃあるので、全てassertTrueを使い回すのがラク
$this->assertTrue(is_integer($price));
$this->assertTrue($price === 5200);
それかphp7以上なら、標準の assert() を使ってもいい
assert($price === 5200);
phpのassertはテストの時だけ動くようにする、みたいな設定ができる
（Herokuなんかは標準でOFFになっているはず）
<= バリデーションエラーなど、絶対にエラーを返さないといけないものなんかはassertではなくちゃんとコードで書くべき