18

Web 開発における単体テストの使用についてお聞きしたいと思います。単体テストのアイデアは素晴らしいですが、Web アプリケーションのコンテキストで本当に価値があるのでしょうか? 私の質問の 2 番目の部分は、TDD についてです。実際のコードの前に統合テストを作成する場合、このアプローチを「テスト駆動開発」と呼ぶことができますか?

1.前提

定義により、単体テストは 1 つのサービス レイヤーのみでコードをテストする必要があります。テストが複数のレイヤーにわたってコードをテストする場合、統合テストがあります。

2. 引数

2.1 アルゴリズムなし

Web アプリケーションには多くのアルゴリズムはありません。これは、すべてのメソッドが挑戦的でデバッグが困難なことを行う 3D 物理エンジンを構築するようなものではありません。Web アプリケーションは、主に HTML の統合と生成に関するものです。

Web アプリケーションの最大の課題は次のとおりです。 - クリーンなコード (どのソフトウェアにも共通する問題ですが、テストできません) - データの一貫性 - 統合 (プログラミング言語、ファイル システム、構成ファイル、Web サーバー、キャッシング システム、データベース、検索エンジン、外部 API - これらすべてのシステムは、要求に応じて連携する必要があります)

Web アプリのすべてのクラスの単体テストを作成する場合は、(ほとんどの場合) テストを行います: 配列の入力、文字列の連結、および言語のネイティブ関数。

2.2 コスト

Web アプリは統合がすべてであるという理由だけで、常に複数の依存関係があります。多くの異なるクラスをモックする必要があり、小さなテストを作成するだけでも実際には大きな仕事になる場合があります。さらに悪いことに、それはテストだけではありません。ソフトウェアはテスト可能である必要があります。これは、ほぼすべてのクラスに依存関係を注入できる必要があることを意味します。2 つのクラス (またはシステム) 間に追加のレイヤーを作成せずに依存関係を挿入できるとは限りません。コードが複雑になり、作業コストが高くなります。

3. 統合テスト

Web 開発のすべてが統合である場合、それをテストしてみませんか? 反論は少ない。

3.1 統合テストで「何かが壊れている」と表示されるが、どこに問題があるかは表示されない

コードを「UnitTestable」にしてより複雑にするのに必要な時間と比較して、統合テストが失敗したときにバグを見つけるのにどれくらいの時間がかかりますか (これは主観的なものだと思います)。私の経験では、問題の原因を見つけるのに時間はかかりませんでした。

3.2 単体テストはどの環境でも実行できるが、統合テストでは難しい

はい、データベースなしで統合テストを実行する場合。通常、データベースがあります。各テストの後にデータを修正してクリーンアップする限り、問題はありません。トランザクション データベースは、このタスクに最適です。トランザクションを開き、データを挿入し、テストし、ロールバックします。

3.3 統合テストは保守が難しい

私のテストはすべてうまく機能し、問題は一度もなかったので、それについてコメントすることはできません。

4. 優れた単体テストを作成する!

議論全体は、「ユニットテストを正しく作成すれば、問題はありません」と攻撃することができます. それは統合テストでも同じではないでしょうか? 統合テストを作成する方が簡単な場合は、それに固執して正しく作成しないのはなぜですか?

誤解しないでほしいのですが、私は単体テストに反対しているわけではありません。それは完璧なアイデアであり、私は皆にお勧めします. 私は理解しようとしています: それは本当に Web 開発に適していますか? 感想や体験談をお聞きしたいです。

4

3 に答える 3

5

これは非常に良い質問であり、より多くの開発者が自問すべき質問です。

これが Web 開発だけに当てはまるとは思いませんが、議論のベースとなる良い例だと思います。

テスト戦略を決定するとき、あなたが提起したポイントは非常に有効です。商業の世界では、コスト (時間の観点から) がおそらく最も重要な要素です。テスト戦略を現実的に保つために、私は常にいくつかの簡単なルールに従います。

  • 単体テストが重要で、単体テスト可能な「ライブラリ」 (Auth、Billing、Service Abstractions など)
  • 可能であれば、単体テストモデルがあると仮定します（そして、実際に可能であるべきです！）
  • アプリケーションの重要なエンドポイントの統合テスト (完全にアプリに依存します)

これら 3 つのポイントを明確にしたら、コストの制約を考慮して、意味のある方法で他の意味のあることをテストし続けることができます。

単体テストと統合テストは相互に排他的ではありません。単体テストが可能な美しいライブラリを構築する場合を除き、両方を行う必要があります。

于 2013-03-08T12:52:39.810 に答える
3

簡単な答えはイエスです。単体テストは、統合テストと同様に価値があります。個人的にはTDDはあまり得意ではありませんが、最初に考えてからコードを作成する必要があるため、デザインが大幅に改善されることに気づきました。それは少なくとも私にとってはかけがえのないことですが、それに慣れるのにも多くの時間がかかります。これが、広く誤解されている主な理由だと思います。

あなたのポイントを見てみましょう：

アルゴリズムなし（しかし、あなたが意味することはほとんどありません）：

コメントで述べられているように、それはアプリケーションによって異なります。これは実際にはTDDとは何の関係もありません。アルゴリズムが少ないことは、それらをテストしないことを主張するものではありません。さまざまな状態が多数ある、いくつかの異なるケースがある場合があります。それらが意図したとおりに機能することを知っておくといいと思いませんか？

費用

確かにそれは費用がかかります、そしてそれが小さなプロジェクトであるならば、あなたまたはあなたの開発者がそれに慣れていないならばあなたはTDDから何の価値も得ないかもしれません。それからまた、小さなプロジェクトはそれを始めるためのものかもしれません、それであなたは次のより大きなプロジェクトのためにスピードを上げています。これはあなたが自分でしなければならない計算です。私たちはプログラマーであり、経済学者ではありません。

統合テスト

それもテストしてください！

統合テストでは「何かが壊れている」と書かれていますが、どこにあるかはわかりません

申し訳ありませんが、これはわかりません。

メンテナンスが難しい

維持するのが難しい場合、あなたはそれを間違っています。コードを変更するときは、最初にテストを記述し、実装前にテストを変更してください。開発中にテストに失敗することは、TDDの必須事項です。実際、それについて私を引用しないでください。それは、TDDについての私の限られた理解にすぎません。

これはユニットテストについての非常に良い引用だと思います

単体テストは、説明的ではなく、規範的である必要があります。言い換えれば、単体テストは、コードが何をするのかを定義する必要があり、コードが何をするのかを事後に説明するのではありません。

つまり、統合テストと単体テストは2つの異なるものです。TDDは開発の方法論であり、統合テストは、ユーザーの視点から期待どおりに機能するアプリケーションの検証です。

編集 コミュニティウィキは、統合テストについて次のように述べています。

統合テストでは、すべての入力モジュールはすでに単体テストされたモジュールです。これらのモジュールはより大きな集合体にグループ化され、統合テスト（統合テスト計画で定義）がそれらの集合体に適用されます。統合テストが成功すると、統合システムはシステムテストの準備が整います。

ですから、実際には最初から何が悪かったのかを理解integration testingしていますが、最後の段落を除いて、私の答えはそれほど遠くないと思います。

于 2013-03-08T11:38:06.087 に答える
0

統合テストは、単体テストに比べて実行に時間がかかります。

「...統合に関しては常に複数の依存関係があります」->他のユニットを完了せずに依存ユニットでコーディングしている場合、まだ統合テストを行うことはできません。この時点でコードが機能していることを確認したい場合は、単体テストを実行できます。

チームの各メンバーが独自の依存ユニットを開発している場合、必要なユニットがまだ他のメンバーによって開発されているため、まだ統合テストを実行できません。しかし、少なくとも、リポジトリにコミットする前に単体テストを実行すれば、コードが機能していることを確認できます。

于 2013-03-08T11:49:26.130 に答える