実施していない会社で単体テストを実装する

私の会社のソフトウェア開発責任者は「辞任」（解雇）しましたが、現在、当社の開発慣行の改善を検討しています。これから作成されるすべてのソフトウェアに単体テストを実装したいと考えています。

開発者からのフィードバックはこれです：

• テストは価値があることを知っています
• ただし、仕様は常に変更されるため、時間の無駄になります。
• そして、あなたの締め切りは非常に厳しいので、とにかくテストするのに十分な時間がありません

CEOからのフィードバックは次のとおりです。

• 私たちの会社に自動化されたテストをしてもらいたいのですが、それを実現する方法がわかりません
• 大きな仕様書を書く時間がない

開発者はどのように仕様を入手しますか？口コミまたはPowerPointスライド。明らかに、それは大きな問題です。私の提案はこれです：

• また、開発者に一連のテストデータと単体テストを提供しましょう
• それが仕様です。それが望むものについて明確で定量的であるかどうかは、管理者次第です。
• 開発者は、必要と思われる他の機能は何でも配置でき、テストでカバーする必要はありません

さて、あなたがこのような状況にあった会社にいたことがあれば、どのように問題を解決しましたか？このアプローチは合理的ですか？

単体テストとシステム/受け入れテストの2種類のテストを組み合わせているようです。前者は低レベルで動作し、小さなコード（通常は個別のメソッド）をテストします。通常、これらのコードはプログラムの奥深くにあり、ユーザーには直接見えません。後者は、ユーザーに表示されるプログラム全体を、はるかに高い粒度でテストします。したがって、後者のみがシステム仕様の任意の形式に基づくことができます。

2つの問題を分離することで、改善された開発プロセスへの移行を開始しやすくなります。ソフトウェアがどのように高レベルで指定されているか（指定されていないか）に関係なく、できるだけ早く単体テストの作成を開始します。開発者がメソッドを作成または変更するたびに、具体的な何かを実行します。これは単体テストが可能です（また、そうすべきです）。私の経験では、高レベルの要件を変更しても、通常、これらの低レベルのコードブロックに劇的な影響はありません。コードは、破棄または完全に書き換えるのではなく、ほとんどの場合再配置する必要があります。その結果、既存の単体テストのほとんどは正常に動作し続けます。

単体テストを有効にするための重要な条件の1つは、締め切りを前もって管理者が決定するのではなく、開発者による作業の見積もりに基づいていることです（開発者は適切な単体テストの作成に必要な時間を見積もりに含める必要があります）。または、期限が固定されている場合、配信の範囲は交渉可能である必要があります。特定の数の開発者が特定の時間内に特定の量の質の高い作業のみを提供できるという基本的な真実を変えることはできません。

これと並行して、要件を明確にして文書化し、それらを高レベルの受け入れテストに変える最良の方法について議論を開始します。これは継続的な改良のより長いプロセスであり、組織全体でより良い安定した状態に到達するのに数年かかることがあります。あなたの説明から1つ確かに思えます：前もって大きな仕様文書を書くことで常に変化する要件を修正しようとしてもうまくいかないでしょう。代わりに、より機敏なアプローチに移行することをお勧めします、頻繁なソフトウェアリリースとユーザーへのデモンストレーション、およびユーザーが実際に何を望んでいるかについての多くの議論を行います。ユーザーはいつでも要件について自分の考えを変更する権利を持っています-ただし、各変更にはコスト（時間とお金）がかかります。開発者は各変更要求のコストを見積もることができます。これにより、ユーザー/製品所有者は情報に基づいた決定を下すことができます。「確かに、この機能の変更は素晴らしいことでしょう...しかし、それがこの他の重要な機能のリリースを遅らせ、これだけの費用がかかる場合は、今のところバックログに入れましょう」

ユーザーが受け入れテストケースを定義し、テストデータを作成できるようにすることは、ユーザーをさらに関与させ、ユーザーと開発者間の相互信頼を構築するための優れた方法です。これにより、両当事者は、具体的で、測定可能で、テスト可能な受け入れ基準に焦点を合わせ、通常よりもはるかに詳細にユースケースを検討する必要があります。その結果、ユーザーはリリースごとに開発の現在のステータスを直接確認でき、開発者はプロジェクトのステータスに関するより具体的で具体的な測定フィードバックを得ることができます。ただし、これにはユーザーからのより大きなコミットメントと新しい操作方法が必要であり、これを受け入れて学ぶのは難しい場合があることに注意してください。

移行の経験

長年、私は自分のコードの単体テストを書くのに十分な時間がないという誤解を受けていました。私がテストを書いたとき、それらは肥大化した、重いものであり、それが必要だとわかったときにのみユニットテストを書くべきだと考えるように促しました。

最近、テスト駆動開発を使用するように勧められましたが、完全な啓示であることがわかりました。ユニットテストを書かない時間はないと確信しています。

私の経験では、テストを念頭に置いて開発することで、よりクリーンなインターフェース、より焦点を絞ったクラスとモジュール、そして一般的にテスト可能なコードがよりソリッドになります。

ユニットテストがないレガシーコードを操作し、手動で何かをテストする必要があるたびに、「このコードにすでにユニットテストがある場合、これは非常に高速になる」と考え続けます。結合テストの高いコードに単体テスト機能を追加しようとするたびに、「分離された方法で記述されていれば、これは非常に簡単になる」と考え続けます。

私がサポートする2つの実験ステーションの比較と対照。1つはしばらく前から存在し、多くのレガシーコードがありますが、もう1つは比較的新しいものです。

古いラボに機能を追加する場合、多くの場合、ラボに降りて、必要な機能の意味と、他の機能に影響を与えずにその機能を追加する方法を理解するために多くの時間を費やします。コードは、単にオフラインテストを許可するように設定されていないため、ほとんどすべてをオンラインで開発する必要があります。オフラインで開発しようとした場合、合理的なものよりも多くのモックオブジェクトが作成されます。

新しいラボでは、通常、デスクでオフラインで開発し、すぐに必要なもののみをモックアウトし、その後ラボで短時間を費やして、拾わない残りの問題を解決することで、機能を追加できます-ライン。

私のアドバイス

あなたがうまくスタートを切っているように、あなたがいることを確認する必要があり、任意の時間は、あなたの開発ワークフローに大きな変更を加えることしようとしているようで、誰もがその意思決定に関与している、そして理想的にすることをほとんどの人がそれに買ってきました。あなたの質問から、あなたはこれが正しいようです。人々がそのアイデアに熱意を持っていない場合、失敗するか、悪意を生むかの運命にあります。

説得力のあるビジネスケースを提示できない限り、システム全体の単体テストと仕様の徹底的な実装はお勧めしません。上で述べたように、システムがテストを念頭に置いて設計されていない場合、システムの自動テストを作成するのは非常に困難です。

代わりに、私は小さく始めてボーイスカウトルールを使用することをお勧めします：

キャンプ場は、見つけたときよりも常にきれいにしておきます。

このコードベースに何かを実装しているときに、既存の動作をテストし、古い動作から新しい動作に移行するために必要な特定のテストを特定できる場合、仕様の変更を文書化し、ユニットテストの実装を開始しましたシステム。

触れないモジュールは単体テストを取得しませんが、触れていない場合は、使用中に既に完全にテストされており、変更する必要がないか、使用されていない可能性があります。

あなたが避けたいのは、開発者の努力の全量を浪費することです。これは、決して必要とされないテストを書くことです（YAGNIは、本番コード* 8 'と同じようにテストコードでも同様に動作します）。結局のところ、テストは役に立たないと考えています。

概要

小規模から始めて、テストの信頼性を段階的に高め、テストがチームにとって最も有益なタイミングと場所でテストを開発することでビジネス価値を獲得します。

最初に行うことは、テストではなく、全体的なプロセスを正しく行うことに集中します。何をすべきかを完全に理解していなければ、何もテストする必要はありません！

そのため、最初に仕様を記述し、変更されない（まあ、すぐにではない）仕様を文書化しました。あなたはそれらを成し遂げるのを見なければなりません。ユーザーが仕様をアップロードしたり、直接入力したりできるWebサイトをお勧めします。また、それをバグトラッカーとプロジェクトの進行に関するガイドにリンクすることもできます。

チャンスは、それがあなたが本当に必要なすべてです。内部に単体テストを追加でき、管理者は開発者が単体テストを行っていることを知る必要がありません。ある意味では、それが本来の方法です。

それでもシステムテストを行う必要がありますが、それもプロジェクト管理Webサイトにリンクできます。リリースされると、テストチームは（それがローテーションの別の幸運な開発者であっても）確認するために使用したテストで更新できますすべてが一緒にハングアップします。

「口コミ」の仕様を取得することに慣れている場合、これが一晩で変わるとは正直に思いません。そうすれば、戦いはほぼ完全にこの動作を変えるでしょう-そして、あなたはこれに抵抗するでしょう。「xをやる」と言っていて、それをすべて書き留める必要があるユーザー（またはBAまたはPMまたは誰でも）は、うまく反応しません。あいまいな仕様文書を書いて、それらを明確にするでしょう。口コミの更新。ユニットテストを忘れて、開発ライフサイクルに伴う大きな問題から始めましょう。

最初の問題：「開発者に一連のテストデータと単体テストを提供する」ためには、まずそれらの単体テストを作成する必要があります。これは開発者の仕事です。ユニットテストも仕様を置き換えるものではありません。仕様は、ユニットテストよりも高い抽象化レベルを持つことを目的としています。

2番目の問題：最大の単体テストのカバレッジが必要なようです。この場合、はい、要件が絶えず変化する状況でテストとコードの両方を書くのに時間とお金がかかりすぎます。代わりに、コードのどの部分が重要であるかを決定し、それらの部分のみを単体テストします。多くの場合、変化する要件は製品の重要な部分に影響を与えません。顧客（またはCEOなど）は通常、このパネルを右に移動するか、このタイトルの色を赤から緑に変更することを求めます。誰も気にせず、集中的なテストを必要としません。一方、顧客はハッシュアルゴリズムをSHA512からSHA256に変更したり、セッションの保存方法を変更したりすることは決してありませんが、最もテストが必要な部分です。