開発者の目を通してテスト：ツール、神話、状況

Evgeny Safronov、上級開発者、DataArt



「テストは、プログラム内のエラーの存在を証明するために使用できますが、エラーがないことを証明するために使用することはできません！」

エドガー・ダイクストラ



テストは、人間の生活のほとんどの分野で適用される、適用され、標準化されたエンジニアリング手法です。 哲学、測定基準、または実践のようなテストは、プログラミングよりもはるかに長く存在します。 たとえば、剣を偽造しました。 それが十分にシャープになったかどうかをテストするために、彼らはそれをテストします。 いくつかの時代では、たとえ生きている人でさえ、たとえば奴隷です。



テストは、プログラム、サブジェクト、またはあらゆる産業開発の操作性のテストです。 どのビジネスでもそうですが、独自の微妙さと哲学を持っています。 おそらく私たちが破壊的に行ったことを見るテスターに​​近いでしょう-開発者によって提案された製品を破壊する方法を最初から考えています。 これは、予測可能性が高く、通常プログラムで異常なことを誤って試みてエラーを見つけるユーザーにとって、あまり一般的ではありません。 開発者はプログラムに対して異なるアプローチを持っていますが、覚えておく必要があります。テスターは私たちが作成したものを壊さなければなりません-これが彼らのパンです。

テストソフトウェアが非常に重要なのはなぜですか？

開発者はテストを通して考えず、創造的に考えます-これは問題の原因になる可能性があります。 プログラムを書くように頼まれるとき、私たちは主に概念、データ構造、それらの記述と相互作用について考えます。 その結果、解決策を提示します-バグがたくさんありますが、既製のものです。 通常、ユーザーが大量の異常な操作を実行した場合、入力データが変更された場合に何が起こるかはほとんどわかりません。



ただし、実際には、小さな変更の結果として最も費用のかかる間違いが発生することが示されています。 コードの記述が不十分な場合は、経験豊富な同僚がそれをやり直すように求めてくるからです。 経験を積むと、断片化が失敗したことにすぐに気付くでしょう。 しかし、エラーが最小限である場合-個別のシンボル、ドット、金融取引のサイン、丸めエラー-あらゆる段階で、それらを見つけることは非常に困難です。





図 1.認証フォームとそれを記入するためのオプションの数。



テストにこのような困難がある理由を見てみましょう。 この図では、3つのフィールドの単純なフォームが表示されています。 最初の2つのフィールドには1〜255文字、3番目のフィールドには1〜20文字を入力できます。 行を空白のままにすることもできます。 以下に、可能な組み合わせの数を示します。これは、宇宙の素粒子の数を大幅に超えています。 これは、考えられるすべてのケースをチェックすることが非現実的であるという説得力のある証拠だと思います。 はい、これを行うことはおそらく不適切です。

プロジェクトエラーの種類

図 2. Steve McConnellの著書「Perfect Code」のデータによると、タイプごとのエラーの分配スキーム。



総量の約25％が構造的誤差に起因しています。 データ構造を作成し、それらを使用して操作の実装を作成する設計段階でも、つまり、これらの構造を保持する何らかの「接着剤」を作成するときにも発生します。 これは根本的なエラーの巨大な層です。



次に、機能の実装などに関連するデータエラーが発生します。アーキテクチャが最後の場所にあることは興味深いことです。 これは、間違ったアーキテクチャを作成したため、原則として最終製品をリリースすることが非常に難しいという事実によって説明できます。





図 3.開発の段階ごとのエラーの分布。 スティーブマッコネルの概要。



構築と設計の段階で、エラーと欠陥の主要な層が考慮されます。 よく知られているパレートルールはここで機能します。欠陥の80％はコードの20％のみにローカライズされています。 原則として、これらはある種のコーナーケースです。 財務ロジックなどの数学的な操作を記述する場合、数値を丸めるときなど、多くのエラーが境界値内にある可能性があります。ほとんどの場合は機能しますが、ほとんどの欠陥はコードの小さなセクションにローカライズされます。



手動テストを使用するか単体テストを使用するかに関係なく、テストをコードの50％でカバーすることにより、潜在的な欠陥の50％を防ぐことができたと言うことはできません。 たとえば、100個の単体テストを作成した場合、製品の最終品質が2倍になったとは言えません。 テストのプリズムを考えない開発者が最も軽いケースをチェックするからです。 必要なフォームには、標準名、姓、およびログイン名が入力されています-開発者はさらに先に進みます。 フィールドの1つが空の場合、または長さが255文字の名前が実際に入力された場合、彼はケースをチェックしない可能性が非常に高いです。 彼は、非標準文字、小文字と大文字の組み合わせを実験しません。



テストは、最も一般的な品質管理手法です。 剣を使用して例を思い出した場合、実際の戦闘で使用する前に、間違いなくそれをより長く体験するように依頼してください。 さらに良いことに、生産段階で鍛冶屋に同意すれば、彼は武器を鍛造する金属もテストします。 したがって、プログラムの品質を向上させるために、テストの量を増やし、同時にベストプラクティスを使用することをお勧めします。 努力に比例して、製品の品質が向上します。



開発者、テスター、マネージャー、顧客など、誰でも製品をテストできます。 小規模なプロジェクトでは、マネージャーまたは開発者がテスターの役割を実行できる場合があります。 ただし、ここでも4つの役割はすべて非常に重要です。プロセスの各参加者は、それぞれの観点からオブジェクトを確認します。 開発者-コードの仕組みのプリズムを通して。 彼は最初から、インターフェースを破る方法に関するほとんどの情報を持っています。 テスターに​​とって、エラーを見つけて製品を破壊することは直接的な作業です。 顧客はテストをまったく異なる方法で見ます。つまり、より少ないテストを書いて、より少ないお金を払うだけでなく、結果として高品質の製品を得る方法に興味があります。 しかし、マネージャーは最も興味深い役割を担っており、通常、彼は自分の実践からのケースに頼ることができます。 ただし、原則として、開発者、テスター、および顧客の間の橋渡しとして機能し、その主なタスクは製品を提示することです。 しかし、出力で製品の品質を管理するのはマネージャーです。

白黒ボックスのテスト

開発者は自分のコードをホワイトボックスと見なしているため、ホワイト、グレー、ブラックボックスの分析という形でのテスト分類は興味深いものです。 しかし、テスターと顧客はプログラムをブラックボックスと見なします。プログラムがどのように機能するかを完全には理解しておらず、重要な機能と動作する必要がある機能のみを知っています。



一部の製品がバスケットに入らないために、オンラインストアのWebサイトのバグは、開発者にとって小さな問題です。 何かをコミットおよびコミット解除し、1か所で変数を変更するだけで十分です。すべて正常に機能します。 テスター、特に顧客にとって、このようなバグは顧客にとって適切な製品を購入できないため、重要です。



しかし、最も興味深いボックスは灰色です。 私がスマートテスターと呼んでいるのは、コードと製品のしくみに深く関わっている人たちです。 彼らは、展開とデータベースとの通信がどのように行われるかに関心があります。

開発者はどのテストを書いていますか？

• 単体テスト。 ほとんどの開発者は手動テストを使用します。 何かをした場合、まず、それが実際に機能することを確認し、入力データと変数を確認して、何らかのフィードバックを得る必要があります。 単体テストは単体テストの一種です。つまり、各コードが正しく機能するかどうかを確認する必要があります。
• 機能テスト。 彼らの助けを借りて、個々の機能、モジュールのバンドルなどをチェックします。
• 統合テスト。 これらを使用すると、2つのモジュールが連携して動作するかどうかを確認できます。
• エンドツーエンドのテスト。 クライアントの観点から、また最初から最後まですべての機能を確認します。 宅配便の仕事に責任を負えないと仮定します。 しかし、あなたが書いたオンラインストアで顧客が製品を選択して支払いできることを確認できます。 そして、商品の出荷準備ができているという事実。

図 4.単体テストのピラミッド。



ピラミッドの基礎-単体テスト-プロジェクトには多数の単体テストがあることが望ましいです。 次に、モジュールの統合テスト、受け入れテスト、特定の機能の直接UIテストが行​​われます。

最初

FIRSTは、テストが満たさなければならない要件を記述するための方法論です。 まず第一に、モジュール式ですが、原則として、これらの特性は自動テストに外挿できます。 その作成者は有名な叔父のボブであり、多くのプログラミングの作者です。

• スピード（高速）。 テストは高速である必要があり、誰も低速のテストを実行しません。 30人のテスターのチームでさえ、それらを実行するのに十分な時間がありません。
• 独立 テストは独立している必要があります。前のテストの実行に依存する要素はありません。
• 繰り返し可能 テストはいつでも実行でき、その動作は予測可能である必要があります。
• 証拠（自己検証）。 テストの動作は、特にプログラムを作成する人にとって明白でなければなりません。
• 適時性（タイムリー）。 テストは、本当に必要なときに作成する必要があります。

図 5. TDDプロセスのスキーム。



2つの基本的なユニットテスト方法は、TDDとBDDの概念に似ています。 BDDアプローチはTDDに基づいており、TDDに存在する小さな欠陥を排除することを目的としています。 BDDテストの構文は、ビジネス指向であり、顧客にとって理解しやすく、一般に技術者としてはそれほど一般的ではありません。 TDDは、物事を正しく行う方法に関するものです。 BDDは、正しいことを行う方法に関するものです。

TDDプロセスはどのようなものですか？

最初に行うことは、まだ作成されていないコードのテストを作成することです。 したがって、機能しないことがわかります。 それが機能するためには、コードを記述する必要があります。 その後、結局のところ、コードを記述してテストを実行し、テストが機能することを確認します。 次に、テストを変更します（要件の指定、境界条件のチェックの追加など）。 その後、テストは機能しなくなり、再びコードを変更する必要が生じます。 このプロセスは、テストが最終的な基準を明確に満たし、直面する課題を満たすまで、ループアップされます。 二次方程式を解く場合、タスクは二次方程式の根を見つける関数を書くことだと仮定します。 テストを作成し、実数に基づいてうまく機能すると仮定します。 しかし、ユーザーが包括的なソリューションを見つけたい場合、何もうまくいかず、テストは失敗し、修正が必要になります。 したがって、このスキームは開発者の血中にある必要があります。機能がすべての要件を満たすまで、それに取り組む必要があります。

TDDはどのように見えますか？

suite('#factorial()', function() { test('equals 1 for sets of zero length', function() { assert.equal(1, factorial(0)); }); test('equals 1 for sets of length one', function() { assert.equal(1, factorial(1)); }); test('equals 2 for sets of length two', function() { assert.equal(2, factorial(2)); }); test('equals 6 for sets of length three', function() { assert.equal(6, factorial(3)); }); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例はJavaScriptで記述されていますが、構文的にはPHPまたはJavaのように見えると思います。 すべてがかなり明白です。 テストを開くと、どのポイントがテストされていないかを簡単に言うことができます。 すばやく簡単に何かを追加できます。 したがって、関数が正しく機能しているかどうかを確認してください。



BDDはTDDに非常に似ていますが、説明の文言が開発とあまり関係のない人（マネージャーまたはビジネスアナリスト）に少し適している点が異なります。

 describe('#factorial()', function() { it('should return 1 when given 0', function() { factorial(0).should.equal(1); }); it('should return 1 when given 1', function() { factorial(1).should.equal(1); }); it('should return 2 when given 2', function() { factorial(2).should.equal(2); }); it('should return 6 when given 3', function() { factorial(3).should.equal(6); }); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

単体テスト機能

• 原子性と単純さのために、ユニットテストを使用すると、開発者は多くのテストを十分迅速に作成できます。
• コードの一部（モック、スタブ、スパイ）を分離する必要があります。 モジュール方式では、個々の小さなセクションをそれぞれテストします。これらのセクションが他のセクションと接続されている場合は、個別にテストする必要があります。
• 重要な点は、コードの動作方法を理解している場合にのみテストを記述できることです（ホワイトボックステスト）。 多くの言語には単体テストツールがありますが、JavaScriptには膨大な数の言語しかありません。 主に、BDDスタイルの記述のテストに焦点を当てています。 たとえば、JSとjQueryの開発の初期段階で作成されたQUnitなどのサービスがあり、TDDアプローチに引き寄せられています。 誰でも好きなものを選ぶことができます。カルマとジャスミンは英語圏のコミュニティでは一般的です。 私は、開発段階で直接効果的な、非常に生産的なものであるモカが好きです。

図 6.単体テストツール。



QUnitはjQuery開発者のライブラリであり、アサートメカニズムを使用して、TDDスタイルで単体テストを記述できます。 qunit.test、テストの名前、およびテストする内容を記述し、コードが表示されるはずの別のファイルで実行すると、コードが機能することを確認できます。



Mochaは、TDDおよびBDD形式でテストを作成できるテストフレームワークです。 原則として、作業でTDDアプローチを完全に実装するために、他のツールと組み合わせて使用​​されます。 つまり、目的の形式でテストを実行および記述できます。たとえば、別のライブラリ（ほとんどの場合、Chai）がアサートチェックの処理を担当します。



Sinonは、モック、スタブ、スパイを作成するためのツールであり、現代の成功したプロジェクトで非常によく使用されます。 開発者が単体テストの作成中に遭遇する多くの典型的な問題を多く助け、解決する関数とモジュールのセットが含まれています。



Jasmineは、最も一般的なAngular Javascriptフレームワークのエコシステムで実際に標準になった人気のあるBDDライブラリです。

神話

• テストは長くて費用がかかります。 実際、バランスを見つけて、なぜそれが必要なのかを顧客に説明する必要があります。 ライブラリをテスト付きの財務データでカバーしない場合、もちろん3日前にサービスをリリースします。 しかし、顧客はテストの失敗の結果として生じる可能性のあるリスクを理解し、受け入れなければなりません。 原則として、モジュールのスムーズな操作がどれほど重要であるかは、顧客が非常によく理解しています。
• テストの作成は退屈で退屈です。 しかし、あなたの歯を磨くこともあまりエキサイティングではありません、そして私たちは毎日それをします。 あなたがこの儀式に慣れているからです。 開発者の生活の中で、まったく同じ立場でテストを受ける必要があります。 たぶん、あなたは思考を少し再構築して、テストのプリズムを通しても含めて、あなたのプログラムを見てください。
• テストは100％コードでカバーできます。 エラーが見つからなかったとしても、これは最終的にいくつかのバグがポップアップしないことを意味しません。 ただし、テストを作成すると、最終製品が機能する可能性が大幅に高まります。 あなたが歯を磨いた場合、これは彼らが決して脱落しないという意味ではありません。 しかし、この衛生手順の利点を疑う人はいません。

プロジェクトの状況

• 顧客は、プロジェクトで単体テストを作成するという考えをサポートしていません。 そのような状況では、作成された製品が必要な品質レベルを満たすように、バランスを探して交渉する価値があります。 テストを書くことを要求される意識的なクライアントもいます。
• 2番目のポイント-テストはメトリックの存在についてのみ記述され、テストの「純度」には十分な注意が払われません。 「何もすることがないとき-これはまれですが、それも起こります-テストを書きます」とマネージャーは言います。 開発者は同意しますが、ケーススタディを考慮せずにテストを作成しますが、以前のテストを単に複製します。 誰もこれらのテストを必要としませんが、カバレッジは拡大しており、お金は落ちています。 最後にのみ、故障した製品を入手する可能性がすべてあります。
• コードを書くよりもずっと後にテストを書く-実際、これも悪い。 たとえば、3年前に、独自のコードのテストを書くことは本当に可能だとは思いません。 コードがどのように機能したか、個々のモジュールの動作の基本条件を理解することは、決して簡単ではありません。