Penanganan opsi terletak di jantung pendekatan modular Federasi Perdagangan. Secara khusus, opsi adalah mekanisme di mana Pengembang, Integrator, dan Pelari Uji dapat bekerja sama tanpa harus menduplikasi pekerjaan satu sama lain. Sederhananya, implementasi penanganan opsi kami memungkinkan Pengembang untuk menandai anggota kelas Java sebagai dapat dikonfigurasi, di mana nilai anggota tersebut dapat ditambah atau diganti oleh Integrator, dan selanjutnya dapat ditambah atau diganti oleh Test Runner. Mekanisme ini bekerja untuk semua tipe intrinsik Java, serta untuk semua tipe intrinsik Map s atau Collection s.
Catatan: Mekanisme penanganan opsi hanya berfungsi untuk kelas yang mengimplementasikan salah satu antarmuka yang disertakan dalam Test Lifecycle , dan hanya jika kelas itu dipakai oleh mesin siklus hidup.
Pengembang
Untuk memulai, pengembang menandai anggota dengan anotasi @Option . Mereka menentukan (minimal) name dan nilai description , yang menentukan nama argumen yang terkait dengan Opsi itu, dan deskripsi yang akan ditampilkan di konsol TF saat perintah dijalankan dengan --help atau --help-all .
Sebagai contoh, katakanlah kita ingin membuat tes telepon fungsional yang akan memanggil berbagai nomor telepon, dan akan menerima urutan nada DTMF dari setiap nomor setelah tersambung.
public class PhoneCallFuncTest extends IRemoteTest {
@Option(name = "timeout", description = "How long to wait for connection, in millis")
private long mWaitTime = 30 * 1000; // 30 seconds
@Option(name = "call", description = "Key: Phone number to attempt. " +
"Value: DTMF to expect. May be repeated.")
private Map<String, String> mCalls = new HashMap<String, String>;
public PhoneCallFuncTest() {
mCalls.add("123-456-7890", "01134"); // default
}
Hanya itu yang diperlukan bagi Pengembang untuk menyiapkan dua titik konfigurasi untuk pengujian itu. Mereka kemudian dapat pergi dan menggunakan mWaitTime dan mCalls seperti biasa, tanpa terlalu memperhatikan fakta bahwa mereka dapat dikonfigurasi. Karena bidang @Option disetel setelah kelas dibuat instance-nya, tetapi sebelum metode run dipanggil, hal itu menyediakan cara mudah bagi para pelaksana untuk menyiapkan default untuk atau melakukan beberapa jenis pemfilteran pada bidang Map dan Collection , yang sebaliknya ditambahkan- hanya.
Integrator
Integrator bekerja di dunia Konfigurasi, yang ditulis dalam XML. Format konfigurasi memungkinkan Integrator untuk menetapkan (atau menambahkan) nilai untuk setiap bidang @Option . Misalnya, Integrator ingin menentukan pengujian latensi rendah yang memanggil nomor default, serta pengujian jangka panjang yang memanggil berbagai nomor. Mereka dapat membuat sepasang konfigurasi yang mungkin terlihat seperti berikut:
<?xml version="1.0" encoding="utf-8"?>
<configuration description="low-latency default test; low-latency.xml">
<test class="com.example.PhoneCallFuncTest">
<option name="timeout" value="5000" />
</test>
</configuration>
<?xml version="1.0" encoding="utf-8"?>
<configuration description="call a bunch of numbers; many-numbers.xml">
<test class="com.example.PhoneCallFuncTest">
<option name="call" key="111-111-1111" value="#*#*TEST1*#*#" />
<option name="call" key="222-222-2222" value="#*#*TEST2*#*#" />
<!-- ... -->
</test>
</configuration>
Pelari Uji
Test Runner juga memiliki akses ke titik konfigurasi ini melalui konsol Trade Federation. Pertama dan terpenting, mereka akan menjalankan Perintah (yaitu, konfigurasi dan semua argumennya) dengan run command <name> instruksi (atau singkatnya run <name> ). Di luar itu, mereka dapat menentukan daftar argumen apa pun yang merupakan bagian dari perintah, yang dapat menggantikan atau menambahkan bidang yang ditentukan oleh Objek Siklus Hidup dalam setiap konfigurasi.
Untuk menjalankan uji latensi rendah dengan many-numbers telepon banyak angka, Test Runner dapat menjalankan:
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
Atau, untuk mendapatkan efek serupa dari arah yang berlawanan, Pelari Tes dapat mengurangi waktu tunggu untuk tes many-numbers :
tf> run many-numbers.xml --timeout 5000
Pemesanan Opsi
Anda mungkin memperhatikan bahwa opsi call yang mendasari implementasi adalah Map sehingga setelah --call berulang-ulang pada baris perintah, semuanya akan disimpan.
timeout opsi , yang memiliki implementasi dasar long , hanya dapat menyimpan satu nilai. Jadi hanya nilai terakhir yang ditentukan yang akan disimpan. --timeout 5 --timeout 10 akan menghasilkan timeout yang berisi 10.
Dalam hal List atau Collection sebagai implementasi yang mendasarinya, semua nilai akan disimpan, dalam urutan yang ditentukan pada baris perintah.
Opsi Boolean
Opsi tipe dasar boolean dapat disetel ke true dengan meneruskan nama opsi secara langsung, misalnya --[option-name] dan dapat disetel ke false menggunakan sintaks --no-[option-name] .