PHP
テストコードについて学んだほうが良いのか
自分が思ったやつとか思い出したやつとかは【補】
-
テストコード書くと工数が減るってほんと？？
- そもそも工数が減ると聞いたことが無い
- 不具合減る
-
コストかかるよね
-
あとから効いてくる
-
【補】Economics of Test Automation (xUnit Test Patterns)
-
-
そもそもテストしやすいコードを書こう
- テストの工数削減に効いてくる
- 設計能力の向上も見込める
- 【補】テストコードのリファクタ
-
-
仕様変更時などにありがたみがある
-
ケースによりありがたみが変わる
-
お硬いB2B: そもそも直させてもらえるまでが長い
- あまりありがたみがない
-
B2C: 契約とか結んでなくてもユーザが困ってるから直す
- 何度も回すのでありがたみがある
-
-
-
ちょっとずつ積み上げ
- いきなりドカッと書くのは無理
-
どこまで書く
-
結局プロジェクトによる
- レイヤードアーキテクチャでレイヤー切りまくり？
- M・V・C？
-
ユニットテストは書かず、結合テストのみという選択
- カバレッジは見る
-
-
テストコードはエンジニアの不安を解消する
- 一歩一歩仕様を固めていく
- テスト書けるのはエンジニアとして結構レベル高い
- エッジケースは自動テストが有用
-
テストをしない理由
-
対象機能の重要度が低い
- 非常に軽微で、かつ全然使われていない画面
- 対象機能への改修がない
- スピード重視
-
-
内外どちらから書く
- unit/featureどちらも同じくらい
Laravelはできるけど、PHPのOOPがわからない
-
クラスをどう切ってどう置くの
- F/Wに乗っかる
-
クラス切るときとかにテスト必要だよね
- テスト書かないリファクタはNG
-
SOLID原則勉強しよう
-
クラスが永遠に増え続けるのどうするの
- 巨大なクラスよりはよいのでは
-
人手が少ないとつらい
- IDE(PHPStorm)の力があればそんなにつらくない
-
-
やりすぎてもいけない
-
勘と経験
- 元も子もない…
- 痛い目を見て覚える
-
-
先人の「痛い目」の追体験としてのデザインパターン
- 勉強するうえでも、経験と照らすと腹落ちしやすい
-
OOPもデザインパターンも手段にすぎない
- 目的にならぬよう
- その手段が解決しようとしているものは何なのか？
Laravel
- 参加してないので「まとめ」のみ聞いた
コード保守に秩序をもたらすには
- みんなが「俺の設計が最高」と言う
-
民主主義
- メリットとデメリットで比較衡量して多数決
フルスクラッチノーF/Wべた書きPHPをLaravelに移行したい
- そもそもOOPじゃない、とか
-
まず仕様をテストコードで表現することから始める
- 外部仕様(E2Eテスト)はseleniumとかで
- いきなりがっつり書くのは大変なので並行運用できるとよい
LaravelのAPI開発何を気をつける
-
既存の複雑なDBをEloquentにしていくのはつらい
- DBリファクタリング
-
テストデータどう作る
-
Factory
-
パターンたくさん
- そもそも全部テストする必要あんの
- FactoryにFactoryを重ねる？？(よくわからない)
-
-
フロント
-
Vue.js
- 別repo?