Android platformu geliştirme konusunda yeniyseniz, sıfırdan yepyeni bir GTest ikili dosyası (bazen "yerel" test olarak da adlandırılır) eklemeye yönelik bu eksiksiz örneği, söz konusu tipik iş akışını göstermek için yararlı bulabilirsiniz. C++ için GTest çerçevesi hakkında ek bilgi için, ek belgeler için GTest proje sitesine bakın.
Bu kılavuz, örnek olarak Hello World GTest'i kullanır. Devam etmeden önce kabaca anlamak için kodu baştan sona okumanızı öneririz.
Bir kaynak konumuna karar verme
Tipik olarak ekibiniz, kodu teslim etmek için yerleşik bir yer modeline ve testler eklenecek yerlere zaten sahip olacaktır. Çoğu takımın tek bir git havuzu vardır veya diğer takımlarla bir tane 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ğunu varsayarsak, çoğu bileşenin altında src ve tests klasörleri ve Android.mk (veya ek .bp dosyalarına bölünmüş) gibi bazı ek dosyalar bulunur.
Yepyeni bir test eklediğinizden, muhtemelen src bileşeninizin yanında tests dizini oluşturmanız ve onu içerikle doldurmanız gerekecektir.
Bazı durumlarda, farklı test paketlerini bireysel ikili dosyalara paketleme ihtiyacı nedeniyle ekibiniz tests altında daha fazla dizin yapısına sahip olabilir. Ve bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekir.
Örnek olarak, burada tek bir tests klasörüne sahip bileşenler için tipik bir dizin taslağı 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)
\-- src (test source)
\-- foo_test.cpp
\-- ...
ve birden fazla test kaynağı dizinine sahip bileşenler için tipik bir dizin taslağı:
\
<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 dizinde bulunanlara benzer dosyalarla dolduracaksınız. Aşağıdaki bölümlerde her bir dosyanın ayrıntıları açıklanacaktır.
Kaynak kodu
Örnek için Hello World GTest'e bakın.
Bu örneğin kaynak kodu burada açıklanmıştır:
#include <gtest/gtest.h>
Başlık dosyası GTest için içerir. Dahil etme dosyası bağımlılığı, makefile'da 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: ilk parametre test durumu adıdır ve ikincisi test adıdır. Test ikili 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, yapı sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme yönergeleri ile yönlendirmek için bir yapılandırma dosyası olmalıdır. Çoğu durumda, Soong tabanlı Blueprint dosya seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırmasına bakın.
Karmaşık yapılandırma dosyası
Bunun yerine Trade Federation'ı kullanmak için Android'in test donanımı Trade Federation için bir test yapılandırma dosyası yazın.
Test konfigürasyonu, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan argümanları belirtebilir.
Yerel olarak oluşturun ve test edin
En yaygın kullanım durumları için Atest kullanın.
Daha fazla özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.