Android platform geliştirmeye yeni başladıysanız sıfırdan yeni 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 faydalı bulabilirsiniz. C++ için GTest çerçevesi hakkında daha fazla bilgi edinmek isterseniz ek belgeler için GTest proje sitesine bakın.
Bu kılavuzda örnek olarak Hello World GTest kullanılmıştır. Devam etmeden önce kodu okuyarak kabaca anlamanızı öneririz.
Kaynak konumuna karar verme
Genellikle ekibiniz, kodda check-in yapılacak ve test eklenecek yerler konusunda önceden belirlenmiş bir düzene sahiptir. Çoğu ekip, tek bir Git deposuna sahiptir veya diğer ekiplerle ortak bir depo kullanır ancak bileşen kaynak kodunu içeren özel bir alt dizine sahiptir.
Bileşen kaynağınızın kök konumunun <component source
root> olduğu varsayıldığında, çoğu bileşenin altında src ve tests klasörleri, ayrıca Android.mk gibi bazı ek dosyalar (veya ek .bp dosyalarına bölünmüş) bulunur.
Yepyeni bir test eklediğiniz için büyük olasılıkla tests dizinini bileşeninizin src yanına oluşturmanız ve içeriğini doldurmanız gerekir.
Bazı durumlarda, farklı test paketlerinin ayrı ikili dosyalar halinde paketlenmesi 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.
Örnek olarak, tek bir tests klasörü olan bileşenler için tipik bir dizin ana hattı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
\-- ...
Ayrıca, birden fazla test kaynağı dizini içeren bileşenler için tipik bir dizin ana hattı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 bir dosya daha ayrıntılı olarak açıklanmaktadı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>
GTest için başlık dosyası ekleme. Dosya bağımlılığını dahil etme, 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: İlk parametre test durumu 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 verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirmek için 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 koşum takımı Trade Federation için bir test yapılandırma dosyası yazın.
Test yapılandırmasında, test sınıfına sağlanacak özel cihaz kurulumu seçenekleri ve varsayılan bağımsız değişkenler belirtilebilir.
Yerel olarak derleme ve test etme
En yaygın kullanım alanlarında Atest'i kullanın.
Daha fazla özelleştirme gerektiren daha karmaşık durumlarda enstrüman talimatlarını uygulayın.