Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O teste depende de fatores como o tipo de app, a equipe de desenvolvimento, a quantidade de código legado e a arquitetura usada. As seções
a seguir descrevem o que um iniciante pode querer considerar ao planejar o que
testar no app.
Organização de diretórios de teste
Um projeto típico no Android Studio contém dois diretórios que contêm testes,
dependendo do ambiente de execução. Organize seus testes nos seguintes
diretórios, conforme descrito:
O diretório androidTest precisa conter os testes executados em dispositivos reais ou
virtuais. Esses testes incluem testes de integração, testes completos e
outros em que a JVM sozinha não pode validar a funcionalidade do app.
O diretório test precisa conter os testes executados na máquina local,
por exemplo, testes de unidade. Ao contrário do que foi descrito acima, esses podem ser testes executados em uma
JVM local.
Testes de unidade essenciais
Ao seguir a prática recomendada, use testes de unidade nos
seguintes casos:
Testes de unidade para ViewModels ou apresentadores.
Testes de unidade para a camada de dados, especialmente repositórios. A maior parte da camada de dados precisa ser independente de plataforma. Isso permite que os testes duplos
substituam módulos de banco de dados e fontes de dados remotas em testes. Consulte o guia sobre
como usar testes duplos no Android.
Testes de unidade para outras camadas independentes de plataforma, como a camada Domain, para casos de uso e interativos.
Testes de unidade para classes de utilitários, como matemática e manipulação de strings.
Testar casos extremos
Os testes de unidade precisam se concentrar nos casos normal e de borda. Casos extremos são cenários incomuns
que testadores humanos e testes maiores provavelmente não capturam. Os exemplos
incluem:
Simular armazenamento total ao salvar em um arquivo.
Objeto recriado no meio de um processo, como uma atividade quando
o dispositivo é girado.
Testes de unidade a serem evitados
Alguns testes de unidade precisam ser evitados devido ao baixo valor deles:
Testes que verificam a operação correta do framework ou da biblioteca, não o seu código.
Pontos de entrada de framework, como atividades, fragmentos ou serviços, não
podem ter lógica de negócios, portanto, o teste de unidade não pode ser uma prioridade. Os testes de unidade para
atividades têm pouco valor, porque cobririam principalmente o código do framework
e exigem uma configuração mais complexa. Testes de instrumentação, como testes de interface,
podem abranger essas classes.
Testes de interface
Existem vários tipos de teste de interface que podem ser usados:
Os testes de interface da tela verificam interações importantes do usuário em uma única tela. Eles
realizam ações como clicar em botões, digitar formulários e verificar estados
visíveis. Uma classe de teste por tela é um bom ponto de partida.
Testes de fluxo do usuário ou Testes de navegação, que abrangem os caminhos mais comuns. Esses
testes simulam um usuário se movendo por um fluxo de navegação. Eles são testes simples,
úteis para verificar falhas no tempo de execução na inicialização.
Outros testes
Há testes mais especializados, como de capturas de tela, testes de desempenho
e testes macacos. Você também pode categorizar testes por finalidade, como
regressões, acessibilidade e compatibilidade.
Leia mais
Para testar em isolamento, muitas vezes é necessário substituir as dependências
do objeto em teste por dependências falsas ou simuladas, chamadas de "Teste duplo"
em geral. Continue lendo sobre isso em Como usar testes duplos no Android.
Se você quiser aprender a criar testes de unidade e interface, confira os codelabs
Como testar.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-27 UTC."],[],[],null,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
