私はPythonでOpenGL 2Dライブラリを作成しています。すべてがうまくいっており、コードベースは着実に成長しています。グラフィックライブラリのテストを書くにはどうすればいいですか？
ここで単体テストを書いて、他の人を修正したり新機能を作ったりしている間に、誤って新しいバグを取り込むことはありません。しかし、私はそれらがどのようにグラフィックスライブラリで動作するか分かりません。
私が考えるいくつかの事：
を比較しかし、両方がいるようです悪いアイデア。グラフィックライブラリをテストする一般的な方法は何ですか？
Iは、コンポーネントレベルのテストのために過去に使用したアプローチがある：
グラハムは述べたように、内部ユニットはグラフィックス呼び出しがなくてもユニットテスト可能です。
これは受け入れテストであり、重要ですが、Graham Reedsが別の答えで述べたように、ユニットテストも必要になります。 –
これらは受け入れテストではなく、これらのテストは単一コンポーネントをテストし、テスト対象ユニットの定義に応じて統合テストか単体テストのいずれかです。グラフィックアルゴリズムがシェーダまたはOPENGL/DirectXコードで記述されている場合、コードはグラフィックスレンダリングプロセスとは別にテスト可能であるとは限りません。これが、これを「ユニット」テストする唯一の方法です。 –
@RadomirDopieralski受け入れテストでは、**正確な位置**、**ホワイトボックス**フロー、**ピクセルフォーマットのすべてのタイプ**、フィルター効果の影響を考慮しないことを確認することになりますシステムテストには既にグラフィックスエンジンの上にアプリケーションが含まれています。 –
さらに分解してください。
グラフィックを作成する呼び出しは、アルゴリズムに依存します - アルゴリズムをテストします。
実際、私の場合は半分しか真実ではありません。ほぼすべての基本的な機能を持っているにもかかわらず、私は1つのアルゴリズム（バッチ処理のためにスプライトをソートする）とシングルトンパターンのようなものを使用します。ほとんどの他のコードは、OpenGL呼び出しを簡単に行うことができます。 – orlp
シングルトンは悪です！私は中古の約12ダースの契約をしました。悪夢をテストしました。 C++では、テストを可能にするために、擬似または実際のロガーなどを引き出すためのテンプレート関数をいくつか作成しました。あなたがPythonでそれを行うことができればDunno。 –
あなたが提案した2つの事柄は、本当の結果があると確信している限り、私には分かりやすいものです。 – lhf