プロトタイピング/ベータ版の準備中にユニットテストを行う必要がありますか？
どうしても必要な業界向けのWebアプリケーションを開発しています。業界のコンサルタントと協力して、2か月でプロトタイプを迅速に開発しました。プロトタイプは、彼らが相談する会社でテストする予定です。ソフトウェアは、テストする4〜8人の従業員で使用されます。
プロトタイプは、コンサルタントと協力して業界の要件を使用可能なソフトウェアに変換する際に常に変化しています。私は昨夜の会議で、TDDを実行した場合、テストとコードが破棄されていたため、約8時間を無駄にしていた4つの機能/懸念を固めました。
これまでの私のプロセスは：
- 従業員が現在のオペレーティングソフトウェアで何をしているかを調べる
- 何を変更する必要があるか、何が非効率的かなどについてコンサルタントに聞いて、新しいソフトウェアの潜在的な機能についてメモを取ります。
- 迅速にプロトタイプを作成しますテストは書かれていません（非常に成功しています。コンサルタントとベータ版の従業員は全員、これを使用し始めることに興奮しています。
- コンサルタントからフィードバックを受け取り、必要に応じて調整を行う
- 1〜4を繰り返す
これはうまくいきましたが、私がずっとテストを書いていたのではないかと思っています。私は約200時間の開発を完了し、おそらく約150時間のテスト（複雑な業界ルールをテストする必要があります！）を行うことになりますが、開発作業を現状にほとんど追いつけていません。
特に要件が変化しているため、ベータ前のテストは非常に時間のかかるものだったように思えます。ほとんどの機能は正常に動作しましたが、特に業界ルールに関連するいくつかのマイナーな点が変更されました。だから、最初はうまくいかなかったもののテストを書くのに時間を費やしていたとしたら、かなりの時間の無駄だったでしょう...
プロトタイピングが完了するまでテストを書くのを待っていて、コンサルタントだけでなくそれをテストしている従業員からもフィードバックが得られるベータ版に移行しますか？または私は大きな間違いをしましたか？
私はテストなし、開発主導のテスト、そして実際のred-green-refactor TDDでプロジェクトに取り組んできました。あなたが説明するのは、実際のTDDを試す前に書いたかもしれません。
プロトタイプを2か月ですばやく開発しました。プロトタイプは、彼らが相談する会社でテストする予定です。ソフトウェアは、テストする4〜8人の従業員で使用されます。
プロトタイプのソースコードはベータ版の前に破棄されますか？もしそうなら、少なくともコードベースの単純な部分については、TDDを回避するのに正しかったかもしれません-そのような prototype のポイントは、何かが実行可能であることを学習または証明することです。そうでない場合、あなたは レガシーコード を記述しており、何も壊さずに変更を加えることの難しさが、ソフトウェアの複雑さとともに非常に速く上昇することがわかります。これは、私がこれまでに見たすべての非TDDコード、および多くのDDTコードに当てはまります。
私は昨夜の会議で、TDDを実行した場合、テストとコードが破棄されていたため、約8時間を無駄にしていた4つの機能/懸念を固めました。
これは一般的なストローマンの議論です。まず、TDD以外の作業に費やされた労力は、TDDの作業と同等ではありません。あなたはこれについて私を信頼しなければなりません。自動テストを簡単に作成できる非TDDコードは見たことがありません。第二に、実際のTDDからの私の結論は、単に機能を記述するよりも、テストおよびを記述する方が速いということです。
私は約200時間の開発を完了し、おそらく約150時間のテスト（複雑な業界ルールをテストする必要があります！）を行うことになりますが、開発作業を現状にほとんど追いつけていません。
繰り返しますが、私の経験では、TDDを実行している場合は、要件が変更されている場合でも、速度が高くなります。
特に要件が変化しているため、ベータ前のテストは非常に時間のかかるものだったように思えます。
繰り返しますが、これは、機能を記述する時間とテストを記述する時間を単純に合計した場合の典型的なビューです。しかし、私の経験では、DDTは次のようになります。
- 時間単位でコードを書く
- 0.5から2単位の時間でテストを書く
アプリケーションは、次の機能を実装するために変更するのが1ユニット難しくなっています。 TDDは次のようになります。
- 時間単位でテストを書く
- 0.1〜0.5時間単位でコードを記述します。これで、何を変更する必要があるか、またその方法を正確に把握できるようになります。
- 0.1-0.2時間単位でリファクタリング
これで、アプリケーションの変更が0.2単位難しくなりました。これらの数値は、レガシーアプリケーションのテストを開始した場合とは大きく異なりますが、アプリケーションのテスト済みの部分で変更するまでの時間は著しく改善されているはずです。
裏側では、実際のTDDは難しいです。それを実証するには熟練したメンターが必要です。保守不可能な一連のテストに到着します。正直言って、これはプログラマーとして学んだ最も難しいことだと言えると思います。私はまだ学習を終えていません。特に、テストで大量のコンテキストを回避することは困難です。
早期のテストは重要ですが、すべてをテストする必要はありません。また、多くのコードはTDDスタイルの単体テストではうまく機能しません。
- プロトタイプの場合、後でそのコードを破棄する限り、一時的にベストプラクティスを無視しても問題ありません。
- 一部のコードは非常に単純ですが、アプリケーションの中心にあるため、問題が含まれているとすべてが壊れます。そのための明示的なテストも不要です。
- また、単独でテストすることが本当に難しいものもあります。次に、単体テストの作成に時間を無駄にしないでください。これは、多くの場合、ビジネスロジックまたはGUIの場合です。
したがって、効率的なテストの大部分は、何をテストしないかを知ることです。
テストキャプチャ要件
しかし、自動化されたテストケースには非常に重要な2つの役割があります。それらは、システムが要件を満たしていることだけ検証ではなく、これらの要件の説明–自動的に検証できる説明。現在、要件をどのように追跡していますか？システムがこれらの要件を満たすことをどのように保証していますか？ドメインの専門家が手動ですべてをテストすることは時間の無駄です。
BDDによる簡単なテスト
行動主導型開発は、私が知っている最も官僚的で最も効果的な方法です。 BDDはTDDのようなワークフローを提案しますが、単体テストのレベルではなく、問題ドメインのレベルで行います。
ドメインの専門家と話し合って、システムに必要な動作を理解します。関係者全員が理解できるプレーンテキスト形式でこれを書き留めます。具体的な例に取り組みます。システムにいくつかの入力を提案し、システムがどのように反応するかをドメインの専門家に尋ねます。
これらの平文メモを機械可読形式に編成し、それらの通訳を作成します。このインタープリターは各シナリオを実行し、システムの応答を検証します。
ドメインの専門家が読みやすい、便利な形式を使用します。私はアドホック形式、YAMLファイル、キュウリ機能ファイルなどを使用しました。私が管理している開発者指向のプロジェクトでは、Makefileを使用して各シナリオを説明しています。
テストランナーがいくつかの要件を確認できない場合でも問題ありません。現時点ではこれらを手動でチェックする必要がありますが、すべての要件を同じ場所に保持することは依然として良いことです。
シナリオを選択し、TDDループを使用して実装します。またはしないでください。自分に合ったワークフローを使用してください。
このアプローチの威力は、これらの自然言語のシナリオがテストスイートであり、要件のドキュメントでもあることです。そして、テストランナーは、テストを実装の選択から切り離します。 howを変更すると、これらの要件が満たされます。要件は同じままなので、すべてのテストを破棄する必要はありません。代わりに、テストランナーを更新するだけで済みます。
テストとテストランナーの分割により、ほとんどのテストケースはかなりコンパクトになります。
初期のテストで労力を節約
問題を早期に発見できるほど、その問題を修正する方が安くなります。
開発の初期段階では、設計は依然として流動的であり、必要な変更に容易に対応できます。
その欠陥から発生する可能性のある損傷を制限します。時間とユーザーが無駄にした他のリソース。新しいコードは、そのコードのコンテキストに没頭しているため、デバッグも簡単です。
主題の専門家をより効率的に使用します。あなたの専門家から翌日のフィードバックを得る：良い。テストから同じ分のフィードバックを得る：はるかに良いです。
もちろん、テストではエキスパートを置き換えることはできません。一方、テストではverifyシステム（既知の要件への適合性を確認）、人間の判断を使用してシステムを検証できます（実際にビジネスニーズに対応していることを確認します）。
テストファーストのアプローチでは、コードが記述されるとすぐに実装の欠陥にフラグが付けられます。それより速くなることは不可能です。これにより、欠陥のコストが最小限に抑えられます。
逆説的に、コードと一緒にテストを作成すると、以下のいずれかの作成コストも削減されます。
- テストの作成には設計作業が含まれます。何をすべきか、そしてどのようにすべきかについてすでに明確な考えがある場合、そのコードを書く方がはるかに簡単です。
- テスト容易性は重要ですが、忘れがちな設計上の制約です。テストと一緒にコードを記述する場合、それらのテストを記述する方がはるかに簡単です。
初期のテストは、最初にコードを書くよりも速く、かなり後でテストします。しかしもちろん、市場投入までの時間が総コストの最小化よりも重要である場合、テスト作業の一部を延期する（=技術的負債を積み上げる）ことは正当な決定です。
プロトタイプは小さく、すばやく、破棄する必要があります。
プロトタイプ（スパイク）は、実行可能性調査が迅速に行われる場合に最適です。プロトタイプの結果は一部のソフトウェアではなく、特定のアプローチが機能するかどうかの知識です。
複雑な要件を持つ複数月のプロジェクトがあります。それはもはやプロトタイプではありません。代わりに、それをアルファ品質のプロジェクトと呼びましょう。このアルファソフトウェアを使用可能な製品に変換する計画は何ですか？
最初から再起動する場合、書き換えによってすべての要件が正しく満たされていることをどのように確認しますか？あなたが考え出したすべての細部をどのように引き継ぎますか？しかし、書き換えは数か月の作業を「捨てる」ことを意味するので、これは起こりそうにありません。
コードを段階的にリファクタリングする場合、それをプロトタイプとして扱うのは誤りでした。さて、 それは過去にあります 。しかし、リファクタリングが安全であり、要件を満たし続けることをどのように確認しますか？テストはそれを助けるでしょう。
したがって、とにかくテストが必要であり、コードと一緒にテストを作成することがテストを作成する最も安価な方法であるという前提の下で–はい、間違いを犯した可能性があります。
良いニュースは、今でもいくつかのテストを書き始めるのに良い時だということです。これで船外に行かないでください。まだ細部に至るまで綿密な単体テストを作成しないでください。プロジェクトのこのフェーズでは、コードカバレッジメトリックを考慮しないでください。ただし、今後は、新機能やビジネスルールの変更について高レベルのテストを実行してください。