O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Direcionando um exemplo de aplicativo

Essa categoria de teste de instrumentação não é muito diferente da segmentada para aplicativos Android normais. Vale a pena notar que o aplicativo de teste que inclui a instrumentação precisa ser assinado com o mesmo certificado que o aplicativo que está direcionando.

Observe que este guia pressupõe que você já tenha algum conhecimento no fluxo de trabalho da árvore de origem da plataforma. Caso contrário, consulte https://source.android.com/source/requirements. O exemplo abordado aqui está escrevendo um novo teste de instrumentação com o pacote de destino definido em seu próprio pacote de aplicativos de teste. Se você não estiver familiarizado com o conceito, leia a introdução aos testes da plataforma .

Este guia usa o seguinte teste para servir como uma amostra:

  • frameworks / base / pacotes / Shell / testes

É recomendável navegar pelo código primeiro para obter uma impressão aproximada antes de continuar.

Decidindo sobre um local de origem

Como o teste de instrumentação terá como alvo um aplicativo, a convenção é colocar o código-fonte do teste em um diretório de tests sob a raiz do diretório de origem do componente na árvore de origem da plataforma.

Veja mais discussões sobre a localização da fonte no exemplo de ponta a ponta para testes de instrumentação automática .

Arquivo de manifesto

Assim como um aplicativo regular, cada módulo de teste de instrumentação precisa de um arquivo de manifesto. Se você nomear o arquivo como AndroidManifest.xml e fornecê-lo ao lado de Android.mk para o seu módulo de teste, ele será incluído automaticamente pelo makefile do núcleo BUILD_PACKAGE .

Antes de prosseguir, é altamente recomendável acessar primeiro a Visão geral do manifesto do aplicativo .

Isso fornece uma visão geral dos componentes básicos de um arquivo de manifesto e suas funcionalidades.

A versão mais recente do arquivo de manifesto para a alteração de gerrit de amostra pode ser acessada em: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

Um instantâneo está incluído aqui por conveniência:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>
 

Algumas observações selecionadas no arquivo de manifesto:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">
 

O atributo package é o nome do pacote do aplicativo: este é o identificador exclusivo que a estrutura do aplicativo Android usa para identificar um aplicativo (ou, neste contexto: seu aplicativo de teste). Cada usuário no sistema pode instalar apenas um aplicativo com esse nome de pacote.

Como esse é um pacote de aplicativos de teste, independente do pacote de aplicativos em teste, um nome de pacote diferente deve ser usado: uma convenção comum é adicionar um sufixo .test .

Além disso, esse atributo do package é o mesmo que o ComponentName#getPackageName() retorna e também o mesmo que você usaria para interagir com vários comandos sub da pm via adb shell .

Observe também que, embora o nome do pacote normalmente esteja no mesmo estilo que o nome de um pacote Java, ele realmente tem muito pouco a ver com isso. Em outras palavras, seu pacote de aplicativos (ou teste) pode conter classes com qualquer nome de pacote, embora, por outro lado, você possa optar pela simplicidade e ter seu nome de pacote Java de nível superior em seu aplicativo ou teste idêntico ao nome do pacote de aplicativos.

 <uses-library android:name="android.test.runner" />
 

Isso é necessário para todos os testes de instrumentação, pois as classes relacionadas são empacotadas em um arquivo de biblioteca jar da estrutura separada, portanto, requerem entradas adicionais do caminho de classe quando o pacote de teste é chamado pela estrutura do aplicativo.

 android:targetPackage="com.android.shell"
 

Isso define o pacote de destino da instrumentação para com.android.shell.tests . Quando a instrumentação é chamada por meio do comando am instrument , a estrutura reinicia o processo com.android.shell.tests e injeta o código da instrumentação no processo para execução do teste. Isso também significa que o código de teste terá acesso a todas as instâncias de classe em execução no aplicativo em teste e poderá manipular o estado depende dos ganchos de teste expostos.

Arquivo de configuração simples

Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de compilação com metadados do módulo, dependências em tempo de compilação e instruções de empacotamento. Na maioria dos casos, a opção de arquivo Blueprint baseada em Soong é suficiente. Consulte Configuração simples de teste para obter detalhes.

Arquivo de configuração complexo

Para testes mais complexos, você também precisa escrever um arquivo de configuração de teste para o equipamento de teste do Android, a Trade Federation .

A configuração de teste pode especificar opções especiais de configuração do dispositivo e argumentos padrão para fornecer a classe de teste.

A versão mais recente do arquivo de configuração para a amostra de alteração de gerrit pode ser acessada em: frameworks / base / packages / Shell / tests / AndroidTest.xml

Um instantâneo está incluído aqui por conveniência:

 <configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>
 

Algumas observações selecionadas no arquivo de configuração de teste:

 <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
 

Isso informa ao Trade Federation para instalar o ShellTests.apk no dispositivo de destino usando um target_preparer especificado. Existem muitos preparadores de destino disponíveis para desenvolvedores na Federação do Comércio e eles podem ser usados ​​para garantir que o dispositivo seja configurado corretamente antes da execução do teste.

 <test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
 

Isso especifica a classe de teste da Federação de Comércio a ser usada para executar o teste e passa no pacote no dispositivo a ser executado e a estrutura do executor de teste que é JUnit neste caso.

Veja aqui mais informações sobre as configurações do módulo de teste

Recursos do JUnit4

O uso da biblioteca android-support-test como executor de testes permite a adoção de novas classes de teste no estilo JUnit4, e a mudança de amostra de gerrit contém um uso muito básico de seus recursos.

O código-fonte mais recente para a amostra de alteração de gerrit pode ser acessado em: frameworks / base / packages / Shell / tests / src / com / android / shell / BugreportReceiverTest.java

Embora os padrões de teste geralmente sejam específicos para as equipes de componentes, existem alguns padrões de uso geralmente úteis.

 @SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
 

Uma diferença significativa no JUnit4 é que os testes não precisam mais herdar de uma classe de teste básica comum; em vez disso, você escreve testes em classes Java simples e usa anotação para indicar determinadas configurações e restrições de teste. Neste exemplo, estamos instruindo que essa classe deve ser executada como um teste do Android JUnit4.

A anotação @SmallTest especificou um tamanho de teste para toda a classe de teste: todos os métodos de teste adicionados a essa classe de teste herdam essa anotação de tamanho de teste. configuração da classe pré-teste, desmontagem pós-teste e desmontagem pós-teste: semelhante aos métodos setUp e tearDown no JUnit4. Test anotação de Test é usada para anotar o teste real.

     @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...
 

O @Before anotação é usado em métodos de JUnit4 para efectuar a configuração de teste pré. Embora não seja usado neste exemplo, também há @After para desmontagem pós-teste. Da mesma forma, os @BeforeClass e @AfterClass anotações são podem ser usados em métodos de JUnit4 para executar a configuração antes de executar todos os testes em uma classe de teste, e desmontagem depois. Observe que os métodos de instalação e desmontagem no escopo da classe devem ser estáticos.

Quanto aos métodos de teste, diferentemente da versão anterior do JUnit, eles não precisam mais iniciar o nome do método com test . Em vez disso, cada um deles deve ser anotado com @Test . Como de costume, os métodos de teste devem ser públicos, declarar sem valor de retorno, sem parâmetros e podem gerar exceções.

         Context context = InstrumentationRegistry.getTargetContext();
 

Como os testes JUnit4 não exigem mais uma classe base comum, não é mais necessário obter instâncias Context via getContext() ou getTargetContext() pelos métodos da classe base; em vez disso, o novo executor de teste os gerencia via InstrumentationRegistry onde as configurações contextuais e ambientais criadas pela estrutura de instrumentação são armazenadas. Por meio dessa classe, você também pode ligar para:

  • getInstrumentation() : a instância para a classe Instrumentation
  • getArguments() : os argumentos da linha de comando passados ​​para um am instrument via -e <key> <value>

Construa e teste localmente

Para os casos de uso mais comuns, use o Atest .

Para casos mais complexos que exigem personalização mais pesada, siga as instruções da instrumentação .