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. Konuyu tam olarak anlamak için kodu okumanızı öneririz gözden geçirin.
Kaynak konuma karar verme
Genellikle ekibinizin kontrol etmesi gereken yerlerle ilgili belirli bir kalıbı vardır ve testlerin ekleneceği yerlerdir. Çoğu ekip tek bir Git deposuna sahiptir ya da bir alt dizini diğer ekiplerle paylaşabilirsiniz ancak bileşen kaynak kodu.
Bileşen kaynağınız için kök konumunun <component source
root> konumunda olduğu varsayıldığında çoğu bileşenin altında src ve tests klasörleri, bazıları ise
Android.mk gibi ek dosyalar (veya .bp ek olarak bölünmüş)
dosyalar).
Yepyeni bir test eklediğiniz için muhtemelen
tests dizininizi src bulun ve içerikle doldurun.
Bazı durumlarda, ekibinizin tests altında başka dizin yapıları olabilir.
farklı test paketlerini ayrı ikili programlara paketleme ihtiyacından dolayı.
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
\-- ...
Burada, birden fazla test kaynağı olan bileşenler için tipik bir dizin dizinler:
\
<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ı ne olursa olsun, sonunda tests dizini veya
native klasöründekilere benzer dosyaların bulunduğu, yeni oluşturulan alt dizin
dizinini içermelidir. Aşağıdaki bölümlerde her dosyanın ayrıntıları açıklanmaktadır.
Kaynak kodu
Hello World GTest'e bakın inceleyebilirsiniz.
Bu örneğin kaynak kodu burada belirtilmiştir:
#include <gtest/gtest.h>
GTest için başlık dosyası ekleyin. Dahil etme dosyası bağımlılığı otomatik olarak
oluşturma dosyasında BUILD_NATIVE_TEST kullanılarak çözülmüştür.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest'ler TEST makrosu kullanılarak yazılır: İlk parametre test durumudur
ikincisi de test adıdır. Test ikili adıyla birlikte
aşağıdaki hiyerarşiyi görürsünüz:
<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 Shortg tabanlı Blueprint dosya seçeneği yeterli olacaktır. 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 derleyip test edin
En yaygın kullanım alanlarında Kabul et.
Daha ağır özelleştirme gerektiren daha karmaşık durumlarda araç talimatlarına bakın.