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 ek dokümanlar için GTest proje sitesine göz atın.
Bu kılavuzda örnek olarak Merhaba Dünya GTest kullanılmıştır. Devam etmeden önce kod hakkında genel bir fikir edinmek için kodu okumanızı öneririz.
Kaynak konuma karar verme
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 dizinleri vardır.
Bileşen kaynağınızın kök konumunun <component source
root> olduğunu varsayarsak çoğu bileşenin altında src ve tests klasörleri ve Android.mk gibi bazı ek dosyalar (veya ek .bp dosyalarına bölünmüş) bulunur.
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
\-- ...
Birden fazla test kaynak dizini 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)
\-- 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ı dahil etme. 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!");
}
GTests, TEST makrosu kullanılarak yazılır: İlk parametre test kaydı adı, ikincisi 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ünde, derleme sistemini modül meta verileriyle, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek bir yapılandırma dosyası bulunmalı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 fazla özelleştirme gerektiren daha karmaşık durumlar için araçlarla ilgili talimatları uygulayın.