別のコードバージョンに対してテストする必要があります
作業中のAPIのテストを作成して、開発中にAPIが破損しないことを確認する必要があります。これまでのところ、カムアウトするソリューションは次のとおりです。
- 同じDBで実行されている「prod」コードと「devel」コード（本番データベースのダンプを使用）。
- 独自のDBで実行される「prod」コードと「devel」コード。
どちらのソリューションでも、両方のコードで得られる結果を比較するために、スタンドアロンアプリケーションが必要です。したがって、JSON、XML、またはAPIで使用されるその他の形式を区別できるものを作成する必要もあります。
私によると、これは考えすぎです。 APIコードプロジェクトに含まれる、正常に合格する単純な機能テストを作成する方がよいと思います。開発を進めながら、テストを実行して、以前のように失敗したものを修正します。
私の解決策は、いくつかの理由で効率的ではないとして同僚によって却下されました：
- 実際のデータが必要です。
- テスト用のデータセットを作成することは不可能です。
- 何かを変更するたびにテストを書き直したくありません。
- 何千ものURLをランダムに生成する必要があります。
- pHPUnitで何ができるかできないかわかりませんが、bashで書かれたものはより最適化されるか、Python=マルチスレッド（！？）.
私には、これはまったく意味がないように見え、テストの目的を完全に逃しています。まず、データベーススキーマはかなり単純です。少数の列を持つ非正規化テーブルのスコアであり、それらの多くはブール型です。したがって、関連するデータセットを作成することは、私には非常に簡単に見えます。
第二に、私は（私は間違っているかもしれませんが）テストはあなたのコードがどんな可能な状況でも何をすることになっているのかを決定することだと思います。それらのケースの1つをテストするために、いくつかの「ハードコードされた」（少なくともランダムに生成されたものではない）URLを書く必要はありません。
第3に、コードの動作が変わるときにテストを書き換えると、ISが必要になり、それ自体がメリットになります。自然なもののように見えるため、回避するものではありません。
最後に、私の考えは、私が知っている独学の限り、彼らが私に書いてほしいテストの種類について聞いたことがないという事実によっても動かされます。私にとって、これは、さらに具体的なソリューションを必要とする本当に具体的な何かについて話していること（ただし、APIはかなり単純で、ほとんどが読み取り専用です）、または私たちが間違っていることの手がかりです。上司から最も信頼されている同僚は、テストに精通していないようです...彼らが「ユニットテスト」と呼んでいるものが、実際には統合と機能テストの中間にあることを明確にしようとしたことで非難されました。スモークフレーバー（ええ、本当に）、そして私たちがどの目的のために何をテストしたいのかを明確にする必要があること、または私たちがプライベートメソッドをテストすることになっていないこと。彼は怒りを込めて、彼のテストはうまくいき、私は「理論が多すぎる」ので、「かばん語を愛する人々」は役に立たないので聞くべきではないと答えました...とはいえ、私は単に彼を信頼していません。この点は少なくとも！
本当に最良の解決策であるテストを書かなければならなかった人はいますか？なんで最高だったの？私は自分の視点をより明確にしたり、「基本的な解決策」を最初に試す「力」よりも上司を捕まえようとするべきですか？
ありがとうございました、
あなたが説明する種類のテストは確かに存在します。これは回帰テストの特別な形式であり、そのため、開発バージョンが製品バージョンと同じように動作することを確認します。つまり、後方の非互換性を導入しないようにします。
これは、動作が完全に一致することを保証するために、既存のソフトウェアの書き換えまたはクローン作成を行うときに最もよく使用されます。たとえば、 Samba チームには、このバリエーションがあります。テストマシンには2つのネットワークカードがあり、1つのネットワークカードはWindowsサーバーに接続され、もう1つのネットワークカードはSambaサーバーに接続されます。テストマシンは、ランダムに同一のコマンドを両方のマシンに送信し、回答を比較します。応答の違いを検出すると、バックトラッキング検索を開始して、異なる応答を生成する最も単純なコマンドシーケンスを見つけ、そのシーケンスを2つの応答と一緒にデータベースに記録して、人間が確認できるようにします。で。
したがって、この種のテストの典型的な使用例は、テスト対象のバージョンが実際に know していない場合です。 rewriteの場合）またはそれが他の誰かに属しているため（Windowsの場合との互換性を図ろうとしているSamba内）。
Merb フレームワークは、受け入れテストを使用して、パブリックAPI（つまり、アプリケーションが信頼できるAPI）とセミパブリックAPI（つまり、Merb内部が信頼できるAPI）を定義し、それらをプライベートAPIと区別しました。 （予告なく変更することが許可されています）。これらのテストは異なるディレクトリに分けられており、リリースサイクル中にこれらのテストで実行できることについて明確なルールがありました。たとえば、パブリックディレクトリ内のテストを削除または変更することはできません。メジャーリリースを行わない限り、新しいテストを追加するだけです。 （または、逆に解釈します。パブリックディレクトリのテストを変更または削除すると、パブリックAPIで後方互換性のない変更が行われるため、新しいメジャーバージョンが必要になります。）
このようなものは、状況により適しているように聞こえます。顧客向けのパブリックAPIを説明する一連の受け入れテスト、開発者向けの内部APIを説明する一連の受け入れテスト、そしてもちろん、機能の個々のスライスに対する機能テスト、単体テスト個々の行動単位については、行動単位間の個々の通信ポイントの統合テスト。
パブリックAPIテストは、回帰テストとしても使用できます。新しいバージョンをリリースするときは、古いバージョンと新しいバージョンのテストを実行して、何かが壊れているかどうか、何が壊れているかを確認できるため、文書化するか（意図した非互換性の場合）、修理する。