単体テストと統合テスト：どうすれば反射になりますか

私のチームのすべてのプログラマーは、単体テストと統合テストに精通しています。私たちは皆それで働いてきました。すべてのテストが書かれています。私たちの中には、自分のコードに対する信頼感が向上したと感じている人もいます。

ただし、何らかの理由で、ユニット/統合テストを作成することは、チームのどのメンバーにとっても反射になりませんでした。実際のコードと同時にユニットテストを書いていないとき、私たちの誰も実際に気分が悪いことはありません。その結果、私たちのコードベースはユニットテストによってほとんど発見されず、プロジェクトはテストされずに本番に入ります。

それに伴う問題は、もちろん、プロジェクトが本番環境にあり、すでに正常に動作している場合、ユニット/統合テストを追加するための時間や予算を獲得することは事実上不可能であることです。

私のチームのメンバーと私はすでにユニットテスト（の値に精通している1、2）それは私たちの自然なワークフローにユニットテストをもたらす助けていないようです。私の経験では、単体テストやターゲットカバレッジを必須にすると、テストの品質が低下し、チームメンバーの速度が低下します。これは、これらのテストを作成するための自己生成の動機がないためです。また、圧力が緩和されるとすぐに、単体テストは記述されなくなります。

私の質問は次のとおりです。チーム内でダイナミック/モメンタムを構築し、自然にそれらのテストを作成および維持したい人を導くのに役立つ実験方法はありますか？

実際のコードと同時にユニットテストを書いていないとき、私たちの誰も実際に気分が悪いことはありません。

これが対処する必要があるポイントです。チームの文化は、スプリント中（または使用する時間の単位）にテストを記述しないことが、値をハードコーディングするのと同じくらいコード臭になるように変更する必要があります。その多くは仲間からのプレッシャーを伴います。誰も本当に標準以下と見なされることを望みません。

テストを自分で行います。あなたがそれらをしないとき、目に見える自分をbeります。「良い」プログラマーが単体テストを書いていたら、そのバグをどこで見つけたかを指摘してください。誰も悪いことを望んでいない。この望ましくない振る舞いは悪いものであり、人々はそれに従うようにします。

チーム全体で同じことを実際に望むようにすることは非常に困難です。多くの場合、何かの価値を見ることだけでは、人々が染み込んだ行動を変えるように促すのに十分ではありません。変化を大切にし、それを特に望んでいる人でさえ、無意識のうちにそれと戦う責任を負うこともあります。

問題は、実際には個人の動機付けの1つであり、チームの動機付けそのものではありません。最終的に理解したと感じた何かの結果として、または平均的なプログラマーがすべてを投げ入れてプロセスを完全に変更させる新しいツールまたは他の主観的な理由のために、明確な瞬間があなたに届く時が来ます。あなたの仕事-あなたがそれ以外の選択をした場合-は、あなたまたはチームが、個々のチームメンバーの明確さの引き金となるものを見つける方法があるかどうかを確認することです。

個人的には、DotNetでBDDのStoryQフレームワークを発見しただけで、無視しやすくなり、テストファーストとテスト同時「バリア」を完全に乗り越えました。後で、Visual StudioのNCrunchを見つけたときに、選択を再確認しました。戦いの半分は、アイデアを売ることではなく、習慣に根本的な変化をもたらすために必要な労力を単純に下げることである場合があります... しかし、これらの同じ個人的なトリガーは、同時に、または実装コードの後でさえもテストコードの多くをまだ書いている私の同僚のアプローチを揺るがすには十分ではありませんでした。

また、変更の理由が適切である場合でも、何かを違う方法で学習するために必要な努力に対する固有の恐怖、不信、または不快な見方のために、物事の遂行方法を変更することをためらうことがあります。テストプラットフォーム全体が特定の方法で動作するようにツール化されている場合、特に古いテストと新しいテストが存続期間にわたって共存する必要がある場合、物事の実行方法を変更し、ツールを変更する可能性を正当化するのは難しい場合がありますプロジェクト-作成したすべてのテストを書き換える必要はありません。奇妙なことは、これが新しいテスト方法論を採用する唯一の方法であり、それ自体が賢明な変化をより良く受け入れることをそれ自体により難しくしていると人々が感じることです。

本当に、何かが再帰的になる唯一の方法は、自分がそれを行う方法に過度に集中する必要があることに気がつかなくなるまで、何度も何度もそれを強制することです。時々、チームでこれを行う唯一の方法は、少し厳しいと思われるポリシーを設定すること、ペアプログラミングとコードレビュー、およびチームメンバーがお互いをバックアップし、文字通り変更を強制できるようにする他の方法を練習することです発生する動作で。しかし、そのような戦略が実際に成功するためには、必要に応じてそのような措置を受け入れ、プロセスに参加するために、個々のチームメンバー全員からの堅実で正直なコミットメントが必要です... 。

実際のコードと同時にユニットテストを書いていないとき、私たちの誰も実際に気分が悪いことはありません

「同時に」とはどういう意味かわかりませんが、実際のコードの前にそれらを書くのはどうですか？

人間がコードの後に​​単体テストを書くことを望まない理由は、心理的な観点から容易に理解できます。その時点でコードはすでに機能しているのに、なぜ地球上でテストする必要があるのでしょうか？退屈で、一見役に立たないと思われ、テストを書かないことは危険ではないため、ある種の怠inessが自動的に発生します。その結果、私は長期間にわたってテスト後のアプローチを続けた多くのチームを知りません。

しかし、私の経験では、テストファースト（TDDスタイル）は、少なくとも2つの即時、具体的、エンドルフィン放出の利点があるため、すぐに夢中になります。

• これは、具体的な実行可能要件に直面してコードを設計し、リファクタリング時に設計をより良くするのに役立ちます。これは、すでに機能しているものを単にダブルチェックするよりもはるかに目的があり、満足です。

• TDDサイクルは頻繁に「緑色のバー」の瞬間で区切られ、すぐに成功する味を楽しむことができます。常にあなたの心を満足させ、次の機能を実装する準備を整えます。

だから、テストを書かなかったときにあなたのチームを気分が悪くさせようとはしません。代わりに、私は彼らがそうするように彼らが気分が良くなるようにします。TDDはこれを行う1つの方法です。

最初に、テストの作成と実行が簡単であることを確認し、現在のプロジェクトでフレームワークをセットアップし、そのセットアップ手順を将来のプロジェクトに簡単に含める必要があります。

こうすることで、プログラマがデバッグしようとしている新機能を単体テストする場合、テストを適切に実行するために何十ものフープをジャンプする必要がなくなります。

厄介なことをすればするほど、それを習慣化する可能性は低くなります

私がやったことの1つは、文化の変化を促進するのにある程度成功したことです。「ユニットテストキュレーション」セミナーを毎週開催することです。これの公式の目的は、ユニットテストスイートを高速で最新の状態に保つことですが、より重要な目的は、人々に立ち寄って質問し、テストを練習するための低圧力の方法を与えることです。テストに1時間または1週間だけを費やすこともできるという事実は、これが重要であるというメッセージも送信します。

この方法で文化の変化を少し受けて、それを「反射的に」実行するための障壁を取り除き始めると思います。人々は逆境の最初の兆候で古い習慣に戻る傾向があります-このような会議は一気に解決することはありませんが、文化の変化を開始し、実際にないことから生じる障壁を取り除くと思いますあなたが何をしているかを知る。

すべてが自然に何かをしたいプログラマーのグループを持つことは、（特に大規模なグループについて話しているときは）ユートピーです。

単体テストと統合テストは標準のものです。ワークフローの標準を作成し、チームの各メンバーがそれを尊重する必要があります。標準は、QAの専門家の助けを借りて作成する必要があります。プログラマは標準を尊重する必要があります。できることは、標準をきれいにし、理解しやすく、従うことです。

それはあなた自身のコードへの信頼と使いたいということではなく、良いものを作るために誰もが使用するコーディングとテストの標準が必要なことであり、プログラマはこれを理解する必要があります。

あなたが最初から人々を標準に従うようにすると、それは反射になり、それが続きます。単体テストなしではコードをコードベースに配置できないというルールにすることで、人々はそれをしなければならないと確信するでしょう。プロジェクトリポジトリには、さらに制限的なルールがあります。たとえば、企業は実際にユニットをコーディングする前に（モジュール仕様を作成するとき）ユニットテストを行いますが、これは非常に良い方法です。プログラマーがプロジェクト/コードベースにコードを配置すると、コードはテストモジュール全体で実行され、ユニットテストがパスしない場合、作業に戻ります。

現時点で標準とルールを追加するのが難しい場合は、少なくとも将来のプロジェクトに追加することを考えてください。