「テスト駆動開発」読書会 Vol.2の資料です。
前回のTDD読書会vol1 資料
1章辺り、各自5分黙読。
その後、10分ディスカッションタイムをとった。
Francクラスがコピペになったとしても、テストを通すことを優先。
テスト実行結果
[hamuhamu@hamuhamu-no-MacBook-Air] % make test
phpunit --configuration phpunit.xml test/
PHPUnit 6.3.0 by Sebastian Bergmann and contributors.
... 3 / 3 (100%)
Time: 157 ms, Memory: 10.00MB
OK (3 tests, 6 assertions)
テストが十分にない又は全くないコードに対してTDDを行うことも今後あるだろう。
十分な量のテストがない場合、テストによって守られていないコードのリファクタリングを行わざるをえない。
テストがないまま、リファクタリングを続けてしまうとコードを破壊してしまう。
テストがない場合は、リファクタリングのためにテストコードを書く。
リファクタリングの前にテストを書く。
レガシーコード改善ガイド
試行リファクタリング
理解を深める
参考資料: レガシーコードの触り方
コード中にassertを埋め込む
[hamuhamu@hamuhamu-no-MacBook-Air] % make test
phpunit --configuration phpunit.xml test/
PHPUnit 6.3.0 by Sebastian Bergmann and contributors.
.F. 3 / 3 (100%)
Time: 233 ms, Memory: 10.00MB
There was 1 failure:
1) App\MoneyTest::testEquality
Failed asserting that true is false.
/Users/hamuhamu/Test_Driven_Development_By_Example/test/MoneyTest.php:29
FAILURES!
Tests: 3, Assertions: 9, Failures: 1.
make: *** [test] Error 1
不安に思ったことをテストにするのは大事。
[hamuhamu@hamuhamu-no-MacBook-Air] % make test
phpunit --configuration phpunit.xml test/
PHPUnit 6.3.0 by Sebastian Bergmann and contributors.
... 3 / 3 (100%)
Time: 205 ms, Memory: 10.00MB
OK (3 tests, 9 assertions)
- 悩みをテストで表現
- 完璧ではないが、まずまずのやり方でテストを通す
- さらなる設計は、本当に必要なときまで先延ばしにした
TDDをやっていてもバグを防げない。
バグの混入率は、TDDをやっていれば多少減る。
テストを書く人と、コードを書く人が同じなので、TDDのテストはバグがないことを保証するテストではない。
テストを後回しにしたい場合は @disabled
を使用する。
PHPUnitだと、markIncomplete。
TODOは、もっと具体的に書いたほうがよい。(通貨の概念)
利用者のコード(テストコード)から、サブクラスのDollarを使っている箇所が消えた。
対応通貨が増えるほど、Moneyにファクトリが増えていってデカくなりそう。 Moneyクラスの責務が大きい。
Moneyがファクトリメソッドを持っているので、DollarがFrancを生成できてしまう。 それでいいのか?
Money::dollar(5)::franc(1);
親が子を知っている状態なので、よくなさそう。
・今回と同じスタイル同じペースで第3回も行う
・写経してきてコードを見せ合うといったことをしてもいい(希望者がいれば時間をとります)
では、まさしくこれのための書籍というのがMikado Methodというのがあるのでオススメです。簡易な資料はこれとか。 https://www.slideshare.net/KyonMm/wewlcjp/30
人が違ったとしてもバグがないことは保証できないかと思います。