tdd - 個人の開発者が TDD を使用すべき理由は何ですか?

Question

私は多くの経験を持つ契約プログラマーです。私は、クライアントに雇われて、何らかの形のソフトウェアプロジェクトを自分で、通常は何もないところから行うことに慣れています。これは、ほとんどの場合、白紙の状態であることを意味します。すぐに始められるように、開発したライブラリを持ち込むことができますが、それらは常にオプションです。(そして、契約で適切な IP 条項を取得することに依存します) 多くの場合、ハードウェアプラットフォームを指定または設計することさえできます... したがって、ここでは深刻な自由について話しています。

特定のコードの自動化されたテストを構築するための用途を見ることができます: 自明以上の機能を持つライブラリ、多数の参照を持つコア機能など。そのコードを自動的にテストして、コードを壊していないことがわかるようにすることは、ますます価値があります。

しかし、私の状況では、それ以上のことを正当化するのは難しいと思います. 役に立つとわかったものは採用しますが、やみくもにフォローするつもりはありません。

「メンテナンス」で行うことの多くは、実際には小さな設計変更です。この場合、テストによって何も救われなかったので、テストも変更する必要があります。反復性の高い、スタブ優先の設計アプローチは、私にとって非常にうまく機能します。より大規模なテストで実際にそれほど多くの時間を節約できるとは思えません。

趣味のプロジェクトを正当化するのはさらに困難です... 通常、週末から 1 か月程度の期間のものです。エッジケースのバグが問題になることはめったにありません。

このような質問を読んで、最も投票された回答は、その投稿者の経験/意見では、5人未満の人がいる場合、TDDは実際に時間を無駄にしていると言っているようです(TDDの一定レベルの能力/経験を前提としても)。ただし、それはメンテナンスではなく、初期開発時間をカバーしているようです。プロジェクトのライフサイクル全体で TDD がどのように機能するかは明確ではありません。

TDD は、業界全体の製品の品質を向上させるという価値ある目標に向けた良い一歩になると思います。しかし、理想主義だけでは、もはや私をやる気にさせる効果はありません。

TDD は、大規模なチーム、または信頼できないプログラマーが少なくとも 1 人含まれる任意の規模のチームで良いアプローチになると思います。それは私の質問ではありません。

実績のある唯一の開発者が TDD を採用するのはなぜですか?

単独の開発者や非常に小規模なチームに焦点を当てた TDD で (正式に行われたかどうかにかかわらず) あらゆる種類の指標について聞きたいです。

それができない場合は、あなたの個人的な経験談もいいでしょう。:)

裏付けとなる経験のない意見を述べることは避けてください。これをイデオロギー戦争にしないようにしましょう。また、より大きな雇用オプションの引数をスキップします。 これは単に効率の問題です。

score 19 · Accepted Answer

やみくもに従うつもりはありません。

それが正しい姿勢です。私は常にTDDを使用していますが、他の人ほど厳密には守っていません。

TDD を支持する (私の考えでは) 最良の議論は、最終的にプロジェクトのリファクタリングおよびメンテナンスフェーズに到達したときに実行できる一連のテストを取得できるということです。これが TDD を使用する唯一の理由である場合は、方法論にやみくもに従うのではなく、いつでもテストを作成できます。

私が TDD を使用するもう 1 つの理由は、テストを書くことで自分の API について前もって考えさせられるからです。クラスを作成する前に、そのクラスをどのように使用するかを考えざるを得ません。この高いレベルでプロジェクトに頭を悩ませることは、私にとってうまくいきます。これを行うには他にも方法があります。同じことを行う他の方法 (たくさんあります) を見つけた場合は、自分に合った方法を続けてください。

score 14 · Accepted Answer

ソロで飛ばすとさらに便利だと思います。周りにアイデアをぶつけたり、ピアレビューを行ったりする人がいないため、コードが堅固であるという保証が必要になります。TDD/BDD はその保証を提供します。ただし、TDD は少し議論の余地があります。他の人は、私が言っていることに完全に同意しないかもしれません。

EDIT：正しく行えば、テストを書くと同時にソフトウェアの仕様を実際に生成できることを付け加えておきます。これは BDD の大きな副作用です。しっかりとしたコードと仕様をすべて自分で作成している場合は、スーパー開発者のように見せることができます。

score 12 · Accepted Answer

さて、私の番です...私は自分でTDDを行います（非スパイク/実験的/プロトタイプコードの場合）。

Think before you jump : コードを作成し始める前に、何をしたいのかを考えさせます。ここで私は何を達成しようとしているのでしょうか..「この作品をすでに持っていると仮定すると..どのように機能すると期待できますか?」オブジェクトのインターフェイスイン設計を奨励します。
変更しやすい : 自信を持って変更できます。回帰テストは瞬時に行われます
より良いデザインが生まれる: デザイン活動に労力を費やさなくても、より良いデザインが生まれることを発見しました。test-first + リファクタリングにより、最小限のメソッドで疎結合の最小限のクラスが作成されます..オーバーエンジニアリングはありません.. YAGNI コードはありません。クラスには、より優れたパブリックインターフェイス、小さなメソッドがあり、読みやすくなっています。これは一種の禅のことです..「理解した」ときにのみ、それを達成したことに気づきます。
デバッガーはもはや私の松葉杖ではありません。私は自分のプログラムが何をするかを知っています..自分のコードを何時間もかけてステップ実行する必要はありません。最近では、デバッガーを 10 分以上使用すると、精神的なアラームが鳴り始めます。
時間通りに帰宅するのに役立ちますTDD 以降、コード内のバグの数が著しく減少していることに気付きました..アサートが xUnit タイプの AT ではなく、コンソールトレースのようなものであったとしても。
生産性 / フロー: 完了に向けて次の個別のステップを特定するのに役立ちます... 雪だるま式に転がり続けます。TDD は、私がリズム (または XPers がフローと呼ぶもの) にすばやく入るのに役立ちます。単位時間あたりの質の高い仕事の量が以前よりも多くなっています。赤、緑、リファクタリングのサイクルは、一種の永久機関に変わります。
ボタンを押すだけで自分のコードが機能することを証明できる
練習すれば完璧です。TDD の時間が増えたので、ドラゴンの学習と発見が速くなりました。不協和音かもしれません..でも、最初にテストに行かなくても、TDD のおかげでより良いプログラマーになったと感じています。リファクタリングの機会を見つけることは第二の性質になっています...

これ以上思いついたら更新します..これは、最後の2分間の反省で思いついたものです。

score 6 · Accepted Answer

私は契約プログラマーでもあります。私が単体テストを愛する 12 の理由は次のとおりです。

score 3 · Accepted Answer

TDD に関する私の最高の経験は、 pyftpdlibプロジェクトを中心にしています。開発の大部分は元の作者によって行われ、私はいくつかの小さな貢献をしましたが、基本的には単独のプロジェクトです。プロジェクトのテストスイートは非常に徹底しており、FTPd ライブラリのすべての主要機能をテストします。変更をチェックインするか、バージョンをリリースする前に、すべてのテストがチェックされ、新しい機能が追加されると、テストスイートも常に更新されます。

このアプローチの結果、これは私がこれまでに取り組んだ唯一のプロジェクトであり、新しいリリース後に致命的なバグが発生したり、主要な機能を壊すような変更がチェックインされたりすることはありませんでした。コードは非常にしっかりしており、私はプロジェクトの存続期間中に開かれたバグレポートの数がいかに少ないかということに一貫して感銘を受けてきました. 私 (および元の著者) は、この成功の多くを、包括的なテストスイートと、すべての主要なコードパスを自由にテストできる機能のおかげだと考えています。

論理的な観点からは、記述したコードはすべてテストする必要があり、TDD がなければ手動でテストすることになります。pyftpdlib とは対照的に、バグの数と重大な問題の頻度で最悪のコードは、開発者と QA が手動で新しい機能を試すことによってのみテストされている/されていたコードです。時間の不足や見落としのために、物事はテストされません。古いコードパスは忘れられ、最も古い安定した機能でさえ機能しなくなり、メジャーリリースでは重要な機能が機能しなくなります。手動テストは、検証とテストのランダム化にとって非常に重要ですが、私の経験に基づくと、手動テストと慎重に構築された単体テストフレームワークの両方が不可欠であると言えます。2 つのアプローチ間のカバレッジのギャップは小さく、

score 2 · Accepted Answer

あなたが唯一の開発者であるかどうかは関係ありません。アプリケーションの観点から考える必要があります。すべてのアプリケーションが適切に動作する必要があり、すべてのアプリケーションが維持される必要があり、すべてのアプリケーションのバグが少ない必要があります。もちろん、TDD アプローチが適していない特定のシナリオもあります。これは、締め切りが非常に早く迫っていて、単体テストを実行する時間がないときです。

とにかく、TDD はソロやチーム環境に依存しません。それは全体としてアプリケーションに依存します。

score 2 · Accepted Answer

私はそれほど多くの経験を持っているわけではありませんが、テストに対する非常に対照的なアプローチを見た経験があります。

あるジョブでは、自動テストはありませんでした。「テスト」は、アプリケーションをいじって、頭に浮かんだことを何でも試して、壊れていないかどうかを確認することで構成されていました。言うまでもなく、完全に壊れたコードが本番サーバーに到達するのは簡単でした。

私の現在の仕事では、多くの自動テストと完全な CI システムがあります。コードが壊れると、すぐにわかります。それだけでなく、仕事をしているうちに、コードでどの機能が機能しているか、まだ機能していないかがテストによって実際に文書化されます。既存の機能を壊しても見過ごされないことを知っているので、新しい機能を追加できることに大きな自信が持てます。

したがって、私にとっては、チームの規模ではなく、アプリケーションの規模に大きく依存します。アプリケーションのすべての部分を追跡できますか? すべての要件？アプリケーションが動作していることを確認するために実行する必要があるすべてのテスト? それを証明するテストがない場合、アプリケーションが「機能している」と言うのはどういう意味ですか?

ちょうど私の$ 0.02。

score 2 · Accepted Answer

テストにより、システムを壊していないという確信を持ってリファクタリングできます。最初にテストを書くことで、テストはシステムの動作を定義することができます。テストで定義されていない動作は、定義上、副産物であり、リファクタリング時に変更できます。最初にテストを書くことも、設計を良い方向に導きます。テスト容易性をサポートするには、コードを簡単にテストできるようにするために、クラスを分離し、インターフェイスを使用し、適切なパターン (たとえば、制御の反転) に従う必要があることがわかります。後でテストを作成すると、システムに期待されるすべての動作をテストでカバーしたとは言えません。また、設計が原因で (テストを念頭に置いて開発されていない可能性が高いため) テストが難しいものもあり、テストを軽視したり省略したりしたくなることがあります。

私は通常、単独で作業し、主に TDD を行います。そうでない場合は、単純に、自分の慣習に従っていないか、TDD を行うための適切な方法 (Web インターフェースなど) をまだ見つけていない場合です。 .

score 1 · Accepted Answer

TDD はテストではなく、コードを書くことです。そのため、1 人の開発者にも多くのメリットがあります。多くの開発者にとって、より堅牢なコードを書くことはマインドシフトです。たとえば、どのくらいの頻度で「このコードは失敗するのでしょうか?」と考えます。TDDなしでコードを書いた後？多くの開発者にとって、この質問に対する答えはありません。TDD の実践者にとっては、オブジェクトや文字列が null かどうかを確認してから何かを行うようにするという考え方に変わります。これは、特にそれを行う (コードを壊す) ためのテストを作成しているためです。

もう 1 つの主な理由は、変化です。顧客と接するときはいつでも、彼らは決心しているようには見えません。唯一の定数は変化です。TDD は、壊れる可能性のある他のすべての領域を見つけるための「セーフティネット」として役立ちます。小さなプロジェクトであっても、これにより、デバッガーで貴重な時間を浪費することを防ぐことができます。

何度も言いますが、TDD は何よりもコードを書くことであると言うだけで、単独の開発者としての使用を正当化するのに十分だと思います。

score 1 · Accepted Answer

「一人の開発者」または「趣味」プロジェクトの TDD のオーバーヘッドが費用を正当化しないというあなたの指摘の妥当性に同意する傾向があります。

ただし、ほとんどのベストプラクティスは、長期間にわたって一貫して適用される場合に関連性があり、有用であることを考慮する必要があります。

たとえば、TDD は、最初の単体テストを作成してから 5 分以内ではなく、長期的にはテスト/バグ修正の時間を節約します。

あなたは契約プログラマーです。つまり、現在のプロジェクトが終了すると離れ、おそらく別の会社で別のプロジェクトに切り替えることになります。現在のクライアントは、アプリケーションを維持およびサポートする必要があります。サポートチームと一緒に作業するための優れたフレームワークを残していないと、彼らは立ち往生してしまいます。TDD は、プロジェクトを持続可能にするのに役立ちます。コードベースの安定性が向上するため、経験の浅い他の人がコードベースを変更しようとして大きなダメージを与えることができなくなります。

同じことが趣味のプロジェクトにも当てはまります。あなたはそれにうんざりしていて、誰かにそれを渡したいと思うかもしれません. あなたは商業的に成功するかもしれません (Craiglist を考えてみてください)。

適切なプロセスへの投資は、経験を積んだだけであっても、必ず報われます。しかし、ほとんどの場合、新しいプロジェクトを開始したときに、それを適切に行うことに決めたことに感謝するでしょう。

何かをするときは、他の人を考慮しなければなりません。先を考え、成長を計画し、持続可能性を計画する必要があります。

それをしたくない場合は、カウボーイコーディングに固執してください。この方法ははるかに簡単です.

PS 同じことが他のプラクティスにも当てはまります。

コードにコメントを付けず、理想的なメモリを持っている場合は問題ありませんが、コードを読んでいる他の誰かはそうではありません。
顧客との話し合いを文書化しないと、他の誰かがあなたが下した重要な決定について何も知ることができません

等無限に

score 1 · Accepted Answer

TDD を使用すると、頭の中で問題をより明確に定義できます。これにより、必要な機能だけを実装することに専念できます。また、コード自体を記述する前に「クライアント」を記述しているため、より優れた API を作成するのにも役立ちます。何かを壊すことを心配することなくリファクタリングすることもできます。

score 1 · Accepted Answer

適切な単体テストのセットがなければ、何もリファクタリングしません。

最初に単体テストを行い、2 番目にコードを記述する完全な TDD は行いません。私は CALTAL -- Code A LIttle, Test A Little -- 開発を行っています。通常、コードが最初に実行されますが、常にではありません。

リファクタリングが必要だと分かったときは、十分なテストがあることを確認してから、完全な自信を持って構造をハックします頭の中で計画します。もう一度テストに合格する必要があります。

重要な部分をリファクタリングします。既存の一連のテストに合格する。

その後、何かを忘れていたことに気付き、新しいものに関する CALTAL の開発に戻りました。

すると、削除し忘れたものが表示されますが、それらは本当にどこでも使用されているのでしょうか? それらを削除して、テストで失敗したものを確認してください。

昨日、大規模なリファクタリングの途中で、まだ正確な設計ができていないことに気付きました。しかし、テストには合格する必要があったため、最初のリファクタリングが完了する前に、リファクタリングを自由に行うことができました。(うわー!) そして、変更を検証するための一連のテストがあったため、すべてうまく機能しました。

単独飛行の場合、TDD は私の副操縦士です。

score 0 · Accepted Answer

製品を納品するときに、クライアントはソースコードを所有していますか？単体テストで製品を提供することが付加価値をもたらすことを彼らに納得させることができれば、あなたはあなたのサービスをアップセルし、より良い製品を提供していることになります。クライアントの観点からは、テストカバレッジは品質を保証するだけでなく、テストがUIから機能を分離するため、将来のメンテナがコードをより簡単に理解できるようにします。

score 0 · Accepted Answer

動機付けられた利己心。

私の場合、個人開発者は中小企業の所有者に変換されます。(表向きは) 生活を楽にするために、かなりの量のライブラリコードを作成しました。これらのルーチンとクラスの多くはロケット科学ではないため、コードを確認し、いくつかのスポットテストとメソッドへのデバッグを行って、メソッドが正しく動作することを確認することで、(少なくともほとんどの場合) 適切に動作することを確信できます。そうだと思います。もしそうなら、ブルートフォース。人生は素晴らしい。

時間が経つにつれて、このライブラリは成長し、さまざまな顧客のより多くのプロジェクトで使用されます。テストにはさらに時間がかかります。特に、私が (できれば) バグを修正していて、(さらにうまくいけば) 他の何かを壊していない場合。そして、これは私のコードのバグだけではありません。機能を追加する際には注意が必要です (顧客はより多くの「もの」を要求し続けます)。または、新しいバージョンのコンパイラ (Delphi!)、サードパーティコード、ランタイム環境、またはオペレーティングシステムに移行したときにコードが引き続き機能することを確認する必要があります。

極端に言えば、新しい (課金対象の) プロジェクトに取り組むよりも、古いコードのレビューにより多くの時間を費やすことができました。これをソフトウェアの安息角と考えてください (テストされていないソフトウェアが倒れる前に、どのくらいの高さまでスタックできるか:)。

TDD のような手法により、より思慮深く設計され、(顧客が入手する前に) 徹底的にテストされ、今後のメンテナンスが少なくて済むメソッドとクラスが得られます。

最終的には、メンテナンスに費やす時間が減り、より収益性が高く、より興味深く (ほとんど何でも)、より重要なこと (家族など) に費やす時間が増えることになります。

score 0 · Accepted Answer

私はこの質問にすぐに答えるつもりです. :)

幸運にも長期にわたるプロジェクトに参加している場合は、たとえば、スタックを上に移動する前に、最初にデータ層を作成し、次にビジネス層を作成したい場合があります。その後、クライアントがデータ層の再作業を必要とする要件の変更を行った場合、データ層の一連の単体テストにより、メソッドが望ましくない方法で失敗しないことが保証されます (新しい要件を反映するようにテストを更新すると仮定します)。）。ただし、ビジネスレイヤーからもデータレイヤーメソッドを呼び出している可能性が高く、複数の場所で呼び出している可能性があります。

ビジネス層のメソッドに 3 つの呼び出しがあり、変更するのは 2 つだけだと仮定しましょう。数か月前にコード化されました。このレベル (およびそれ以上) の単体テストは、壊れた前提を見つけるように設計されている必要があります。

この非常に単純化された例が、TDD についてもう少し考えさせるのに十分であり、TDD の使用を検討するきっかけになることを願っています。もちろん、それでも要点がわからず、何千行ものコードを追跡する能力に自信がある場合は、TDD を開始する必要があるとは言えません。

score 0 · Accepted Answer

最初にテストを作成することのポイントは、それによって、行っている要件と設計上の決定が強制されることです。コードを変更するときは、それらがまだ強制されていることを確認したいと思います。また、コンパイラや実行時エラーが発生することなく、何かを簡単に「壊す」ことができるようにしたいと考えています。

自分のコードに高い信頼性を持たせたいので、テストファーストのアプローチをとっています。確かに、テストは優れたテストである必要があり、そうでなければ何も強制しません。

私が取り組んでいるかなり大きなコードベースがいくつかあり、多くの重要なことが進行中です。X が発生してはならないときに突然 X が発生するような変更を加えるのは簡単です。私のテストは、人間のテスターが気付かなかったかもしれない重大な (しかし微妙な) エラーを犯すことを何度か防いでくれました。

テストが失敗した場合は、それらと製品コードを調べて、それが正しいことを確認する機会です。場合によっては、設計が変更され、テストを変更する必要があります。100 回のテストのうち 99 回をパスするものを書くこともあります。合格しなかったその 1 つのテストは、(ある意味で) 同僚がコードをレビューして、自分が構築すべきものをまだ構築していることを確認するようなものです。

score 0 · Accepted Answer

方法論としての TDD は、「変更を行うときにテストを行う」だけではなく、チームやプロジェクトのサイズに依存しないと思います。指摘された動作がどのように実装されるかについて実際に考え始める前に、コード/アプリケーションが何をするかについての期待に注意することです。TDD の主な焦点は、記述されたコードのテストを実施することだけではなく、テストをグリーンにする (そして後でリファクタリングする) ことだけを行うため、コードの記述を減らすことです。

あなたが私のようで、実装方法を考えずにアプリケーションの一部/全体が何をするかを考えるのが非常に難しいと思うなら、コードの後にテストを書いて、コードがテスト。

あなたの質問が、テストファースト (TDD) やテストアフター (優れたコーディング?) に関するものではない場合、本番環境にとどまるコードを作成する開発者にとって、単独であれ大規模なチームであれ、テストは標準的な方法であるべきだと思います。 3か月以上。私の経験では、元の作成者でさえ、この 20 行の複雑で、非常に最適化されているが、まばらに文書化されたコードが実際に何をするのかを真剣に考えなければならない期間です。テスト (コード全体のすべてのパスをカバーする) がある場合は、考えることが少なくなり、数年後でもエラーが少なくなります...

score 0 · Accepted Answer

プロジェクト、特に大規模なプロジェクトのソロ開発者として、あなたはかなり薄く広がる傾向があると感じています.
大規模なリファクタリングの最中に、何らかの理由でプレリリーステスト中に表示されなかったいくつかの重大なバグが突然検出されました。この場合、すべてを落として修正する必要があり、2週間かけて髪を引き裂いた後、最終的に以前に行っていたことに戻ることができます.
1 週間後、あなたの最大の顧客の 1 人が、このクールな新しい光沢のある機能が絶対に必要であることに気付きました。
3 か月経った今、リファクタリングしているコードが何をするはずだったかはおろか、そもそもなぜリファクタリングを始めたのかさえ覚えていません。少なくとも、リファクタリングされたコードがまだ本来の機能を実行していることを示しているため、これらの単体テストを適切に作成してくれたことに感謝します。
泡立てて、すすぎ、繰り返します。

..過去 6 か月間の私の人生の物語。:-/

score 0 · Accepted Answer

最終的にこのプロジェクトは他の開発者に引き継がれる可能性があるため、単独の開発者は自分のプロジェクトで TDD を使用する必要があります (実績は関係ありません)。または、より多くの開発者を連れてくることができます。

新しい人は、テストなしでコードを操作するのに非常に苦労するでしょう。彼らは物事を壊します。

score 0 · Accepted Answer

ここにいくつかのミームと私の反応があります：

「TDD によって、どのように失敗するかを考えさせられたので、より優れたプログラマーになりました」

十分な経験があれば、障害モードに非常に関心を持つことは、いずれにせよ自然にプロセスの一部になるはずです。

「アプリケーションは正しく動作する必要があります」

これは、完全にすべてをテストできることを前提としています。最初に機能コードを正しく記述したときよりも、すべての可能なテストを正しくカバーすることはできません。「アプリケーションはより適切に機能する必要がある」というのは、より適切な議論です。それには同意しますが、それは理想主義的であり、私が望んでいるほどモチベーションを高めるには十分具体的ではありません. メトリクス/逸話はここで素晴らしいでしょう。

「<library component X> でうまくいきました」

私は質問で、これらの場合に価値があると言いましたが、逸話に感謝します.

「次の開発者を考える」

これはおそらく私にとって最良の議論の 1 つです。ただし、次の開発者も TDD を実践しない可能性が非常に高く、その場合、TDD は無駄になるか、負担になる可能性さえあります。裏口伝道とは、そこに相当するものです。ただし、TDD 開発者が本当に気に入ると確信しています。

廃止された必須の方法論で行われたプロジェクトを継承した場合、どれだけ感謝するでしょうか? RUP、誰か？TDD が誰もが思っているほど優れていない場合、TDD が次の開発者にとって何を意味するかを考えてください。

「リファクタリングはずっと簡単です」

リファクタリングは他のスキルと同じであり、反復開発には確かにこのスキルが必要です。新しいデザインが長期的に時間を節約できると思うと、かなりの量のコードを捨てる傾向があり、非常に多くのテストも捨てられるように感じます。どちらがより効率的ですか? 知らない。

...

私はおそらく、ある程度の TDD を新しい人に勧めるでしょう... しかし、ブロックの周りにすでに数回来ている人の利点にはまだ問題があります. おそらく、自動化されたテストをライブラリに追加し始めるでしょう。それをやった後、私はそれを一般的に行うことにもっと価値があると思うかもしれません.

tdd - 個人の開発者が TDD を使用すべき理由は何ですか?

21 に答える 21

Related

Reference