O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Como direcionar um exemplo de aplicativo

Esta categoria de teste de instrumentação não é muito diferente daqueles direcionados aos aplicativos Android regulares. É importante notar que o aplicativo de teste que incluiu a instrumentação precisa ser assinado com o mesmo certificado do aplicativo ao qual se destina.

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 coberto aqui é escrever um novo teste de instrumentação com pacote de destino definido em seu próprio pacote de aplicativo de teste. Se você não estiver familiarizado com o conceito, por favor leia a introdução de testes de Plataforma .

Este guia usa o seguinte teste para servir de exemplo:

  • frameworks / base / packages / Shell / tests

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

Decidir sobre um local de origem

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

Veja mais discussões sobre localização de origem no exemplo end-to-end para testes de auto-instrumentação .

Arquivo de manifesto

Assim como um aplicativo normal, 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 Android.mk para o seu tmodule teste, ele vai ficar incluído automaticamente pelo BUILD_PACKAGE makefile núcleo.

Antes de prosseguir, é altamente recomendável que passar pela App Manifest Overview primeiro.

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 mudança 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 para sua 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 sobre o arquivo de manifesto:

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

O package atributo é o nome do pacote do aplicativo: este é o identificador único que usa o framework de aplicações Android 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 este é um pacote de aplicativos de teste, independente do pacote de aplicativo em teste, um nome de pacote diferente deve ser utilizado: uma convenção comum é adicionar um sufixo .test .

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

Observe também que, embora o nome do pacote seja normalmente do mesmo estilo de um nome de pacote Java, na verdade, ele tem muito poucas coisas a ver com ele. Em outras palavras, seu pacote de aplicativo (ou teste) pode conter classes com quaisquer nomes de pacote, embora, por outro lado, você possa optar pela simplicidade e ter o nome do pacote Java de nível superior em seu aplicativo ou teste idêntico ao nome do pacote do aplicativo.

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

Isso é necessário para todos os testes de Instrumentação, uma vez que as classes relacionadas são empacotadas em um arquivo de biblioteca jar de estrutura separado, portanto, requer entradas de caminho de classe adicionais quando o pacote de teste é chamado pela estrutura de aplicativo.

android:targetPackage="com.android.shell"

Isso define o pacote de destino da instrumentação para com.android.shell . Quando a instrumentação é invocado via am instrument de comando, o quadro é reiniciado com.android.shell processo e código injeta instrumentação para o processo de 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 pode ser capaz de manipular o estado dependendo 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 construção com metadados do módulo, dependências de tempo de compilação e instruções de empacotamento. Na maioria dos casos, a opção de arquivo Blueprint baseada em Soong é suficiente. Veja simples configuração de teste para mais detalhes.

Arquivo de configuração complexo

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

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

Versão mais recente do arquivo de configuração para a mudança gerrit amostra pode ser acessado em: estruturas / base / pacotes / Shell / testes / AndroidTest.xml

Um instantâneo está incluído aqui para sua 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>

Alguns comentários selecionados sobre o 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 à 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 Trade Federation 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 Trade Federation a ser usada para executar o teste e passa no pacote no dispositivo a ser executado e na estrutura do executor de teste que é JUnit neste caso.

Olhe aqui para mais informações sobre o módulo de teste Configs

Recursos JUnit4

Utilizando android-support-test biblioteca como corredor de teste permite adoptation de novas classes de teste de estilo JUnit4, ea mudança gerrit amostra contém algum uso básico de suas características.

Código-fonte mais recente para a mudança gerrit amostra pode ser acessado em: frameworks / Base / packages / Shell / testes / src / com / android / shell / BugreportReceiverTest.java

Embora os padrões de teste sejam geralmente específicos para 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 de base comum; em vez disso, você escreve testes em classes Java simples e usa anotações para indicar certas configurações e restrições de teste. Neste exemplo, estamos instruindo que esta classe deve ser executada como um teste Android JUnit4.

O @SmallTest anotação especificado um tamanho de teste para toda a classe de teste: todos os métodos de ensaio adicionados a esta classe de teste herdam esta anotação tamanho teste. pré configuração de teste de classe, pós teste de lágrima para baixo, e teste post lágrima classe para baixo: semelhante ao setUp e tearDown métodos em JUnit4. Test anotação é usado 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é. Apesar de não ser usado neste exemplo, há também @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 configuração e desmontagem do escopo da classe devem ser estáticos.

Quanto aos métodos de ensaio, ao contrário da versão anterior do JUnit, eles não são mais necessários para iniciar o nome do método com o test , em vez disso, cada um deles deve ser anotado com @Test . Como de costume, os métodos de teste devem ser públicos, não declarar nenhum valor de retorno, não aceitar parâmetros e podem lançar exceções.

        Context context = InstrumentationRegistry.getTargetContext();

Porque o JUnit4 Ensaios que já não necessitam de uma classe de base comum, que não é mais necessário para obter Context casos através getContext() ou getTargetContext() através de métodos de classe de base; em vez disso, o novo corredor de teste administra-los via InstrumentationRegistry onde configuração contextual e ambiental criado por quadro instrumentação é armazenado. Por meio desta aula, você também pode ligar para:

  • getInstrumentation() : o exemplo para a Instrumentation classe
  • getArguments() : os argumentos de linha de comando passados para am instrument via -e <key> <value>

Construir e testar localmente

Para a maioria dos casos de uso comum, empregar Atest .

Para os casos mais complexos que exigem personalização mais pesado, siga as instruções de instrumentação .