また、最新の Android SDK ツールは、リンクされたライブラリ プロジェクトを含むアプリケーションのテストをまだ適切にサポートしていないようです。
次の設定のプロジェクトがあります。
TestLib (android ライブラリ プロジェクト) ← TestMain (android プロジェクト) ← TestMainTest (android 単体テスト プロジェクト)
これらすべてのプロジェクトを Eclipse で作成し、 etandroid update (test-/lib-)project ...
を生成するために使用しました。build.xml
アル。
問題は、TestMain (InheritAddition.java
私の例では) に TestLib ( Addition.java
) のクラスから継承するクラスがあり、単体テスト () でこのクラスを参照したい場合に発生しますInheritAdditionTest.java
。
TestLib
public class Addition {
public int add2(int o1, int o2) {
return o1 + o2;
}
}
TestMain
public class InheritAddition extends Addition {
public int sub(int p1, int p2) {
return p1 - p2;
}
}
TestMainTest
public class InheritAdditionTest extends AndroidTestCase {
public void testSub() {
Assert.assertEquals(2, new InheritAddition().sub(3, 1));
}
}
コマンド ラインでビルドすると、結果は次のようになります。
W/ClassPathPackageInfoSource(14871): 原因: java.lang.NoClassDefFoundError: org/test/main/InheritAddition W/ClassPathPackageInfoSource(14871): ... 26 件以上 W/ClassPathPackageInfoSource(14871): 原因: java.lang.IllegalAccessError: 検証済みクラスのクラス参照が予期しない実装に解決されました W/ClassPathPackageInfoSource(14871): dalvik.system.DexFile.defineClass(ネイティブ メソッド) で W/ClassPathPackageInfoSource (14871): dalvik.system.DexFile.loadClassBinaryName (DexFile.java:195) で W/ClassPathPackageInfoSource (14871): dalvik.system.DexPathList.findClass (DexPathList.java:315) で W/ClassPathPackageInfoSource (14871): dalvik.system.BaseDexClassLoader.findClass (BaseDexClassLoader.java:58) で W/ClassPathPackageInfoSource (14871): java.lang.ClassLoader.loadClass (ClassLoader.java:501) で W/ClassPathPackageInfoSource(14871): java.lang.ClassLoader.loadClass(ClassLoader.java:461) で W/ClassPathPackageInfoSource(14871): ... 26 件以上 W/dalvikvm(14871): 予期しない DEX によって解決されたクラス: Lorg/test/main/InheritAddition;(0x41356250):0x13772e0 ref [Lorg/test/lib/Addition;] Lorg/test/lib/Addition;(0x41356250):0x13ba910
私は日食のために働くいくつかの回避策を見つけました:
これでうまくいきますが、ANT で動作するソリューションを探しています (より正確には、両方で同時に動作するソリューションを探しています)。
サンプル プロジェクトはライブラリ jar を使用しないため、文書化されたアプローチ (build.xml を変更してメイン プロジェクトの jar をクラス パスに含めることによる) はここでは適用できません (また、この特定の問題は SDK ツールで修正されていると思います)。 r16)。
to の依存関係をどうにかしTestMainTest
てTestLib
( を変更してproject.properties
) 削除し、代わりにビルド スクリプトをハックして、それらのビルドされた jar をクラス パスに配置します (したがって、-compile
ターゲットを変更するものに置き換えます。のクラスパスjavac
)。私は android SDK ツールチェーンの変更に対応しようとしてきた長い歴史があるため、これは、a) かなり複雑であり、b)build.xml
ツールチェーンが変更されるたびに (かなり頻繁に) を常に変更する必要があるため、実際には私のお気に入りのオプションではありません。
そのため、スレッジハンマーを使用せずにそのようなセットアップを機能させる方法のアイデアを探しています。完全に明らかな何かが欠けているのかもしれませんが、私にとってこのユースケースはかなり標準的であり、なぜこれがすぐにサポートされないのか理解するのに苦労しています.