Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Test etmeniz gerekenler; uygulama türü, geliştirme ekibi, eski kodun miktarı ve kullanılan mimari gibi unsurlara bağlıdır. Aşağıdaki bölümlerde, yeni başlayanların uygulamasında neleri test edeceğini planlarken neleri göz önünde bulundurabileceği özetlenmektedir.
Test dizinlerinin düzenlenmesi
Android Studio'daki tipik bir proje, yürütme ortamına bağlı olarak testleri içeren iki dizin içerir. Testlerinizi aşağıdaki dizinlerde açıklandığı şekilde düzenleyin:
androidTest dizini, gerçek veya sanal cihazlarda çalışan testleri içermelidir. Bu testler arasında entegrasyon testleri, uçtan uca testler ve uygulamanızın işlevselliğini JVM'nin tek başına doğrulayamaması nedeniyle diğer testler yer alır.
test dizini, yerel makinenizde çalıştırılan testleri (ör. birim testleri) içermelidir. Yukarıdakilerin aksine, bunlar yerel bir JVM üzerinde çalışan testler olabilir.
Temel birim testleri
En iyi uygulamayı uygularken aşağıdaki durumlarda birim testlerini kullandığınızdan emin olmalısınız:
ViewModels veya sunucular için birim testleri.
Veri katmanı, özellikle de depolar için birim testleri. Veri katmanının çoğu platformdan bağımsız olmalıdır. Böylece test çiftleri, testlerde veritabanı modüllerini ve uzak veri kaynaklarını değiştirebilir. Android'de test çiftleri kullanma ile ilgili kılavuza bakın
Kullanım alanları ve etkileşimcilerde olduğu gibi, Alan katmanı gibi platformdan bağımsız diğer katmanlar için birim testleri.
Dize manipülasyonu ve matematik gibi yardımcı sınıfları için birim testleri.
Uç Durumları Test Etme
Birim testleri hem normal hem de uç durumlara odaklanmalıdır. Uç durumlar gerçek kişilerin ve daha büyük testlerin yakalayamadığı nadir senaryolardır. Örnekler şunları içerir:
Negatif sayılar, sıfır ve sınır koşulları kullanan matematik işlemleri.
Olası tüm ağ bağlantısı hataları.
Bozuk veriler (ör. bozuk JSON JSON)
Dosyaya kaydederken dolu depolama alanı simüle ediliyor.
Bir işlemin ortasında yeniden oluşturulan nesne (ör. cihaz döndürüldüğünde gerçekleşen bir etkinlik).
Kaçınılması Gereken Birim Testleri
Bazı birim testlerinde değerleri düşük olduğundan bu testlerden kaçınılmalıdır:
Kodunuzu değil, çerçevenin veya kitaplığın doğru çalıştığını doğrulayan testler.
Etkinlikler, parçalar veya hizmetler gibi çerçeve giriş noktalarının iş mantığı olmaması gerekir. Bu nedenle, birim testi öncelikli olmamalıdır. Aktivitelere ilişkin birim testleri, çoğunlukla çerçeve kodunu kapsadıkları ve daha karmaşık bir kurulum gerektirdiği için çok az değere sahiptir. Kullanıcı arayüzü testleri gibi enstrümanlı testler
bu sınıfları kapsayabilir.
Kullanıcı arayüzü testleri
Uygulamanız gereken birkaç tür kullanıcı arayüzü testi vardır:
Ekran kullanıcı arayüzü testleri, tek bir ekrandaki kritik kullanıcı etkileşimlerini kontrol eder. Düğmeleri tıklama, formlara yazma ve görünür durumları kontrol etme gibi işlemler gerçekleştirirler. Ekran başına bir test sınıfı iyi bir başlangıç noktasıdır.
Kullanıcı akış testleri veya gezinme testleri; en yaygın yolları kapsar. Bu testler, gezinme akışında hareket eden bir kullanıcıyı simüle eder. Bunlar basit testlerdir ve başlatma sırasında çalışma zamanı kilitlenmelerini kontrol etmek için yararlıdır.
Diğer testler
Ekran görüntüsü testleri, performans testleri ve maymun testleri gibi daha özel testler mevcuttur. Testleri, regresyonlar, erişilebilirlik ve uyumluluk gibi amaca göre de kategorilere ayırabilirsiniz.
Daha fazla bilgi
Tek başına test yapmak için çoğu zaman test edilen kişinin bağımlılıklarını, genel olarak "İkili test" adı verilen sahte veya sahte bağımlılıklarla değiştirmeniz gerekir. Android'de test ikililerini kullanma başlıklı makalede bu konu hakkında okumaya devam edin.
Birim ve kullanıcı arayüzü testlerinin nasıl oluşturulacağını öğrenmek istiyorsanız Codelab testlerini inceleyin.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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)."]]
