testing - アプリケーションの最終的なパッケージ製品にシステム テスト ケースを含めると、肥大化やリスクの増加につながりますか?

Question

特定の条件を検出し、一連のユニット、機能、およびシステム テストを実行する %postinstall セクションを含む rpm ファイルをパッケージ化しています。コード自体が診断に使用するのと同じ環境変数のいくつかを使用しているため、内部構造の一部が公開されているというプッシュバックを受けています。考え？

更新: テストを自動的に実行したり、その存在をエンド ユーザーに公開したりする予定はありません。テスト パッケージは、スイートがインストールされたすべてのマシンで簡単に利用できるようにすることを提案しています。これにより、パッケージの最終的なサイズが約 3% 増加し、適切に実行するには非常に多くの内部知識が必要になります。

プログラム自体は、他のユーザーが使用できるライブラリであり、API で公開されています。物事がどのように機能するかについての内部知識は問題ではありません。私の主な動機は、適切なテスト リソースが不足していることと、ターゲット環境に大きなばらつきがあることです。一部のテストは非常に単純です (すべての適切な機能がコンパイラから利用可能であることを確認するために configure が行うことと似ています)。他のテストはより複雑で、ライブラリが提供する必要がある基本的な機能を証明します。

Answer 1

インストールごとに実行されるという苦情を避けたい場合は、少なくともRPMの％checkルールを使用してください。

人々が「リバースエンジニアリング」について心配しているように聞こえます。では、ソフトウェアはプロプライエタリですか？これがあなたの問題の核心になっているようです。とにかく、テストスイートはパッケージ化されたソフトウェアから分離されているのが一般的です。

ただし、非現実的ではありません。ユーザーが自分のシステムでテストを実行して結果を提供できるようにすることは、ユーザーとのコラボレーション関係の優れた側面です。残念ながら、あなたは独自のビジネスモデルに反対しています。

おそらく、テストと診断を切り詰めたり書き直したりすることで妥協し、あまり多くを明らかにすることなく、適切な量の適合性を証明することができます。私はあなたがこれまでに書いたもののテストと診断を捨てることから後退しません。

徹底したテストシステムに同梱されているソフトウェアパッケージにユーザーが満足し、自信を持ってくれること、そしてこれらがソフトウェアの内部を明らかにすることへの恐れを上回っていることを、本当に主張する必要があります。