「最初にテスト」がどのように機能するかはわかりません。いつ、なぜこのアプローチをとるかについての議論を聞きたいです。
1行の実装を書く前に、テストを書いてモックを作成することをお勧めすることがよくあります。とはいえ、すべての状況に当てはまるわけではないと思わざるを得ません。たとえば、プロトタイプを作成していて、すべてがどのように機能するかまだわからないとします。そのため、必要だと思われる各ステップの例を見つけて、コードに挿入し始めます。最後に、私は自分の理論の証明を手に入れましたが、それほど長くはかかりませんでした. これは本質的に「私のテスト」です。これは単体テストではありませんが、テストです (ほとんどの場合、コンソール アプリです)。
これが私の仕事のやり方です。やりたいことを考えて、やってみようと思います。それが機能する場合は、最終的に戻って単体テストを作成し、回帰をトラップできるようにします。これはあなたが「やるべきこと」とは違うのですか？
包括的なルールは次のとおりです。最もリスクの高い項目を最初に実行します。
最初にテストケースを実行することは、暗黙のうちに、コーディングの最も危険な部分は、作成されているオブジェクトのインターフェイスと動作の誤解と誤解であると主張することです。
多くのプロジェクトでは、これが正しい可能性が高く、TDD はそのような場合に非常に適しています。
ただし、多くのプロジェクトではそうではなく、そのような場合に TDD を適用するのは適切ではありません。
使いやすさが最大のリスクである場合は、単体テストをいじるのをやめて、UI のプロトタイピングを行ってください。
最大のリスクがパフォーマンスである場合は、最初にいくつかのパフォーマンス プロトタイプを作成し、インターフェースについては心配しないでください。
このリストは続きます。
危険な項目を最初に行うことには、多くの利点があります。
多くのリソースが浪費される前に、必然的に失敗するプロジェクトは早期に終了します。
問題が発生しているが救済可能なプロジェクトは、プロジェクト管理の焦点を早期に得ます。
組織のビジネス側は、失敗のリスクが低いプロジェクトを高く評価します。不必要に早期にキャンセルされる可能性は低くなります。
「実装の1行を書く前に、テストを書いてモックを作成することをお勧めすることがよくあると聞きます。....私は最終的に戻って単体テストを作成します...これはあなたが「想定している」こととは異なりますか？」
あなたはあなた自身の質問への答えから始めたので、あなたは本当にその質問をしているのではありませんか？
人々が自分の質問に答える理由はたくさんあります。時々、それは議論の方法です。
それは人々が「私は議論しているのではなく、なぜこれがそんなに間違っているのかを尋ねているだけだ」と言うことを可能にします。
目標は最初にテストすることです。仕組みは次のとおりです。
プロトタイプを作成しているとしましょう。すべてがどのように機能するかはまだわかりません。
しかし、私は1つのことを知っています。それがすることになっていること。
それが何をすべきかについての具体的な例を書き留めてください。具体的で具体的なインプットとアウトプット。
それがテストケースです。私が最初にやった。これを単体テストとして形式化できますか？おそらくそうではありません。しかし、私は受け入れテストケースから始めました。
これで、問題を細かく分割できます。
だから私は私が必要だと思う各ステップの例を見つけ始めます。
必要だと思うものの例ごとに、ステップから何が入り、何が出るかを書き留めます。
これらはテストケースです。私は最初にそれらをしました。多くの場合、それらを単体テストとして形式化できます。
テストが終わったら、各ステップの例に戻り、コードにスローします。
テストしてからコーディングしました。コーディングの前にすべてのテストを行ったわけではありません。私は最初にテストを行いましたが、クレイジーなすべてのテストをノーコードで行う方法ではありませんでした。私はそれを少しずつコードを少しずつテストする方法で行いました。しかし、すべてが最初にテストされました。
これは簡単です。答えはプロトタイピング中です。この段階では、建物のシステムを十分に理解していないため、正しくテストすることはできません。また、プロトタイプ コードは使い捨てコードにする必要があるため、この段階でテストを行っても実際のメリットは得られません。しかし、プロトタイピングから得た理解は、生産に入った後に効果的なテストを行うのに役立ちます。
そうです、プロトタイプの後にテストを行う場合、あなたのアプローチは正しいです
使い捨てのプロトタイプを作成している場合でも、プロトタイプが実際に何をするかを考えて、それが機能することを確認するテストから始めると便利です。プロトタイプをテストできることを確認することで、ソリューションへのアプローチ方法も形作られます。
その後、コードが破棄されても、まだテストがあります。
試作品のテストから始めるのも大変ですが、なんとかできたときはいつも嬉しかったです。
スパイク/プロトタイプをテストしないというあなたのアプローチは問題ないと思います. しかし、2つのアイデア：
プロトタイプが完成し、何をすべきかがわかったら、それを破棄して最初にテストを再実装するか、既に記述したコードのテストを記述します。
単体テストでより多くの練習をした場合、コンソール アプリを作成するよりも、テストでプロトタイプを作成する方が速いことに気付くかもしれません。テストと別のクラスをアイデアで作成するという意味ではありません。テストメソッドでコードを使用して探索することを意味します。私はこれを何度もやりましたが、とても満足しています。新しい API や新しい言語を学習しているときでも、テストは実験を試すための最速のフィードバック サイクルを提供してくれます。次に、コードが機能するようになったら、それを別のメソッド/クラスに抽出して、実際のシステムの一部にすることができます。
コードの「ストーリー」をまだ構築しているときは、最初にテストを書くのはあまりうまくいきません。インターフェイスがどのように見えるかわからない場合、テストを作成するのは困難です。テストを考えずに、クラスとインターフェースを具体化するためのスタブコードを書くかもしれません。しかし、私はできるだけ早くテストに取り掛かるようにしています。デザインを作成するときにテストするものをメモしておくと便利だと思います。その後、デザインがさらに固まったら、メモに戻って最初にテストを行います。これは通常、実装と単体テストのコードが一緒に成長することを意味します。
「それを行う正しい方法」は1つではありません。ただし、テスト駆動開発（TDD）があなたのケースに役立つと思います。最初にテストを作成すると、APIの形成に役立ち、コードがよりクリーンになることがわかりました。最初にテストを作成するときは、実装（「どのように行うべきか」）を考える前に、コードがどのように呼び出されるか（インターフェース、または「これは何をすべきか」）を最初に考えます。
たとえば、CRMモジュールを作成することを想像してください。あなたは最初にすべきことは最もお金を使った顧客を獲得することだと思うかもしれません。したがって、テストを作成します。
Assert.AreEqual（Customer1、crm.GetMostValuableCustomer（）、 "期待どおりではない最も価値のある顧客"）;
次に、次のようなものを続けます。
Assert.AreEqual（new Customer [] {Customer1、Customer2、Customer3}、crm.GetCustomerByValue（）、 "GetCustomersByValue（）が期待どおりではありません"）;
つまり、重要なのは、コードを別の観点から考えることです（プロデューサーとしてではなく、コンシューマーとして）。よりクリーンなコードを書くのに役立つと信じており、後で戻って回帰テストを作成する必要はありません。もっと良い例があればいいのにと思いますが、この方法で作業することが実際にプロトタイピングの段階でどのように役立つかがわかるといいのですが。