みんな、みんなテストを書く
最初の赤いストリップを見てからもう3年が経ちました。 テストの作成を開始することになったのは、もはや重要ではありません。 情報を収集し始め、 wiki.agiledev.ru全体を読み直し 、最初のSimpleTestテストを厳launchedに開始しました。 もちろん、これらのテストはひどいもので、アーキテクチャも（現在の理解では）大変でした。 その後、おそらくほとんどの間違いを見つけましたが、素晴らしい時間を過ごしました:)
それから彼はPHPUnitに切り替えました-SimpleTestとどのように違うのか、そしてその中で「だまされている」のは興味深いことでした。
そして、 ライムは嫌です。 なぜSymfonyの連中はそんなにこだわったのですか？ 私はブランチ1を理解しています。*、レガシー、その他すべて。 ただし、2.0はPHPUnitでも起動できます。はい、面白かったです。 私は積極的にテストを書きましたが、コードを書く前に正直にこれを試みました。
それからMartinの本「 Quick Software Development 」が私の手に落ちました（いつものように、偶然、あるいは当然、 Wayを持っている人のために）。
この男は私にajailを感染させ、本当のOOPが何であるかを示し、TDDの方向に良いキックを与えました。 まだアーカイブの
それ以来、私は違ってきました:)中核と自給自足が私に現れました。今では、コードとテストの欠陥を見るために他の人の記事を読む必要はありませんでした。 宮本武蔵のように、先生の助けなしに真実を学ぶことができました。
今、私のコードもたわごとですが、今私はこれを認識しています。
そして、 ケント・ベックのように、私が天国に登ろうとしているとすぐに、そのようなトリックを見せてくれました。 同じフレームワークを使用したテストを通じてテスト用のフレームワークを作成したことがありますか？
そこで、ベック、「テスト感染」という用語に出会いました。 だから、私は伝染しています:)
なぜテストを書いているのですか
それは私が妄想的で、すべてを恐れているからです。 テストを書いたとき、私は確信しています：
1.プログラムは期待どおりに動作します（各プログラマーは常に異なる方法でのみチェックし、常に最も効率的な方法ではありません）。
2.システムの任意の部分に変更を加えることができ、同時に何も壊れません。 または、すぐにそれを見つけて簡単に修正します。
したがって：
- システムの一部を変更し、リファクタリングを実行することを恐れていません。
- 私は常にコードをリファクタリングしています。これは私の仕事の不可欠で必須の部分です。
- コードは、
たわごとをグリースしませんし、変更に抵抗しません。 - 私はいつでも簡単に、素早く、痛みを伴わずに変更を加え、恐れや結果への嫌悪感やプロセスを感じません。
- エラーの数は大幅に削減され、存在するエラーは簡単に診断および修正できます。
- バグのデバッグ、テスト、修正に多くの時間を費やしていません。
- テストしやすいコードを書くと、結果のソリューションのアーキテクチャに大きく影響します。 コードがテストに抵抗する場合、アーキテクチャに問題があることを理解しています。
- 統合の問題？ これは何ですか 私はブランチをマスターに引っ張り、すべてのテストに合格しました。 それだけです
- そして最も重要なこと-私はそのようなコードで作業できることを嬉しく思います。 そして、欠点があれば（そして、それらは常にそこにあります）、コードがテストで覆われているとき、私はいつでもそれを修正することを確信しています。
方法
- システムの価値はテストにあります。なぜなら、テストだけがその動作を記述するからです。 同時に、コードは絶対に何でもかまいません（ただしテストに適しています）。 テストなしのコードは無料で
、デフォルト では嫌でandいです。
- テスト->プロトタイプ->リファクタリング
テスト->プロトタイプ->リファクタリング
テスト->プロトタイプ->リファクタリング
つぶやくときに横目を見たとしても注意を払ってはいけません。
- テストは最初に書く必要があります。 コードの後に書かれたテストは無料で、負担にすぎません。
- 最初にテストを行う必要があります。 これはテストテストです。 テストが失敗しなかった場合、必要なときに落ちるかどうかはわかりません。
- テストはそれらを実行するために書かれています。 彼らが実行しないテスト...しかし、あなたはあなたの時間と
他の誰かの お金を無駄にして、それをまったく必要としますか？
- 私は5分ごとにテストを実行します。一度に1つずつ、グループで、セット全体を実行します。 始める前に、完全なセットを実行します。 各コミットの前に、フルセットを実行します。 約6分間、テストを長時間実行しないと、不安になります。 この間に何も書かなかったとしても、フルセットを実行してから、もう一度実行します。 たぶん私は狂っていますが、今は落ち着いた狂人です。
- テストは非常に迅速に合格するはずです。 5分ごとに起動する方法を教えてください。 コミットの前にテストの完全なセットを実行する必要があることを、傷ついた場所を疑ってこすりながら、開発者にどのように説明できますか？
- 私はバグが大好きで、テスターが大好きです-彼らはそれらを見つけます（バグ）。 その後、新しいテストを作成するか、既存のテストを修正する機会があります。 そしてその後、このバグは二度と起こらないと確信しています。 理想にさらに一歩近づいた。
- 最後に、リファクタリング、リファクタリング、リファクタリング。
まあ、
結論として
参照の小さなリスト：
- ロバートC.マーティン、ジェームズW.ニューカーク、ロバートS.コス「 急速なソフトウェア開発。 原則、例、実践 ”
- wiki.agiledev.ru
- ケントベックエクストリームプログラミング。 テストによる開発 ''
- ケントベックエクストリームプログラミング
- ジェラルド・メサロシュ「 xUNITテストパターン 」
- ビンセント・マッソル、テッド・ハステッド「 JUnit in Action 」
- ボウリングゲームのスコアリングプログラムを作成します。 ルールはここにあります 。
- xUnitテストフレームワークを記述します（最初にテストします）。 単体テストの原理に慣れていない人は、Kent Beckから始めるほうが良いでしょう。 そして、知っている人にとっては、これは痛くないでしょう。