iOSDC Japan 2016の発表資料です。 https://iosdc.jp/2016/c/node/84
![ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方](https://cdn-ak-scissors.b.st-hatena.com/image/square/75fb5ef442f0a9061a4ef0fa2b34339abd56ee6a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F97aef176b1694ed4b51aa549cb6045e6%2Fslide_0.jpg%3F6718772)
こんにちは皆さん 以前にPHPerもテストコード書こうぜ!みたいな記事を書いたわけですが、いざテスト書こうとするといろんな問題に突き当たります。 特に大きな問題は可読性だったりしますが、この可読性の問題を大幅に解決してくれたのが、Laravelのテストでした。 Laravelのユニットテスト テストの「可読性」問題 テストの可読性は大きな課題です。 というのも、テストというのは仕様と実装があっていることを確かめるものであるため、テストの可読性が低い<=>テストが何の仕様を確認しているかわからない状態では、そのテストの存在意義に疑問符がつくでしょう。もちろん、そんな状態では仕様変更が発生しても、どの箇所のテストを直せばわからなくなり、「結果としてテストコードが邪魔」になるというジレンマを生み出してしまいます。 また、可読性が低いということは、書きにくいということと同義ですので、「テストを書く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く