Android platform geliştirme konusunda yeniyseniz sıfırdan yepyeni bir GTest ikili dosyası (bazen "yerel" test olarak da adlandırılır) eklemeyle ilgili bu eksiksiz örneği, ilgili tipik iş akışını göstermek için yararlı bulabilirsiniz. C++ için GTest çerçevesi hakkında daha fazla bilgi edinmek isterseniz GTest proje sitesindeki ek dokümanlara göz atın.
Bu kılavuzda örnek olarak Merhaba Dünya GTest kullanılmıştır. Devam etmeden önce kodu baştan sona okumanızı öneririz.
Kaynak konumu belirleyin
Ekibiniz genellikle kodda kontrol edilecek ve test eklenecek yerlerle ilgili yerleşik bir düzene sahiptir. Çoğu ekibin tek bir git deposu vardır veya bir deposu diğer ekiplerle paylaşır ancak bileşen kaynak kodunu içeren özel bir alt dizine sahiptir.
Bileşen kaynağınız için kök konumunun <component source
root> konumunda olduğu varsayılırsa çoğu bileşenin altında src ve tests klasörleri ile Android.mk gibi bazı ek dosyalar bulunur (veya ek .bp dosyalarına bölünmüştür).
Yepyeni bir test eklediğiniz için muhtemelen src bileşeninizin yanında tests dizinini oluşturmanız ve içeriği doldurmanız gerekir.
Bazı durumlarda, farklı test paketlerini tek bir ikili dosyaya paketlemeniz gerektiğinden ekibinizin tests altında başka dizin yapıları olabilir.
Bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekir.
Bunu açıklamak için tek bir tests klasörü içeren bileşenler için tipik bir dizin taslağını aşağıda bulabilirsiniz:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
Aşağıda, birden fazla test kaynak dizini olan bileşenlere ilişkin tipik bir dizin ana hatları verilmiştir:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
Yapıdan bağımsız olarak, tests dizinini veya yeni oluşturulan alt dizini, örnek gerrit değişikliğindeki native dizininde bulunanlara benzer dosyalarla doldurursunuz. Aşağıdaki bölümlerde her dosyayla ilgili ayrıntılı bilgi verilmektedir.
Kaynak kodu
Örnek için Merhaba Dünya GTest'e bakın.
Bu örneğin kaynak koduna buradan ulaşabilirsiniz:
#include <gtest/gtest.h>
GTest için başlık dosyası ekleyin. Include dosyası bağımlılığı, makefile'de BUILD_NATIVE_TEST kullanılarak otomatik olarak çözülür.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest'ler TEST makrosu kullanılarak yazılır: İlk parametre test durumunun adı, ikinci parametre ise test adıdır. Test ikili program adıyla birlikte, sonuç kontrol panelinde aşağıdaki hiyerarşiyi oluştururlar:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTest ile test yazma hakkında daha fazla bilgi için GTest belgelerine bakın.
Basit yapılandırma dosyası
Her yeni test modülünün, derleme sistemini modül meta verileri, derleme süresi bağımlılıkları ve paketleme talimatlarıyla birlikte yönlendirmek için bir yapılandırma dosyası olmalıdır. Çoğu durumda, Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması başlıklı makaleyi inceleyin.
Karmaşık yapılandırma dosyası
Bunun yerine Trade Federation'ı kullanmak için Android'in test aracı Trade Federation için bir test yapılandırma dosyası yazın.
Test yapılandırması, test sınıfını sağlamak için özel cihaz kurulumu seçenekleri ve varsayılan bağımsız değişkenler belirtebilir.
Yerel olarak derleme ve test etme
En yaygın kullanım alanları için Atest'i kullanın.
Daha ağır özelleştirme gerektiren daha karmaşık durumlar için araç talimatlarını uygulayın.