Pengujian Aplikasi-Aplikasi Berorientasi Objek

19.4 Metode-metode Pengujian Berorientasi Objek

Arsitektur perangkat lunak berorientasi objek menghasilkan serangkaian

subsistem berlapis yang mengenkapsulasi kelas-kelas yang berkolaborasi. Masing-

masing elemen sistem ini (subsistem dan kelas) menjalankan fungsi-fungsi yang

membantu memenuhi kebutuhan sistem. Hal ini diperlukan untuk meguji sistem OO di

berbagai tingkat yang berbeda dalam upaya untuk menemukan kesalahan-kesalahan

yang mungkin terjadi ketika kelas-kelas saling berkolaborasi dan subsistem

berkomunikasi diseluruh lapisan arsitektur.

Metode perancangan use case untuk perangkat lunak berorientasi objek terus

berkembang. Namun, keseluruhan pendekatan untuk merancang use case OO telah

disarankan oleh Berard [Ber93]:

1. Setiap test case harus diidentifikasi secara unik dan secara eksplisit terkait dengan

kelas yang diuji.

2. Tujuan pengujian harus dinyatakan

3. Daftar langkah pengujian harus dikembangkan untuk setiap pengujian dan harus

berisi :

a. Dafta keadaan tertentu dari kelas yang diuji.

b. Daftar message dan operasi yang akan dikerjakan sebagai imbas dari

pengujian.

c. Daftar eksepsi yang dapat terjadi saat kelas diuji.

d. Daftar kondisi eksternal (yaitu perubahan dalam lingkungan eksternal untuk

perangkat lunak yang harus ada sehingga penguijan dapat dilakukan dengan

benar).

e. Informasi tambahan yang akan membantu memahami dan menerapkan

pengujian.

Tidak seperti rancangan use case konvensional, yang dikendalikan oleh

pandannga perangkat lunak input-proses-output atau detail algoritma dari modul

individu, pengujian berorientasi objek berfokus pada perancangan urutan operasi yang

tepat untuk menjalankan keadaan-keadaan dari suatu kelas.

19.4.1 Implikasi Perancangan Test Case dari Konsep OO

Oleh karena kelas berkembang melalui kebutuhan dan model perancangan, kelas

menjadi sasaran perancangan test case. Karena atribut-atribut dan operasi-operasi

dienkapsulasi, maka pengujian operasi-operasi diluar kelas umumnya tidak produktif.

Meskipun enkapsulasi merupakan konsep perancangan penting untuk OO, enkapsulasi

dapat menciptakan kendala kecil saat pengujian. Sepeti dituliskan oleh Binder [Bin94],

“Pengujian membutuhkan pelaporan mengenai keadaan konkret dan abstrak dari

sebuah objek”. Namun, enkapsulasi dapat membua informasi tersebut menjadi sulit

untuk diperoleh. Kecuali operasi built-in disediakan untuk melaporkan nilai untuk atribut-

atribut kelas, gambaran sepintas mengenai keadaan objek dapat sulit diperoleh.

Pewarisan juga dapat memberikan Anda tantangan tambahan selama

perancangan test case. Saya telah mencatat bahwa setiap konteks kegunaan baru

perlu diuji kembali, bahkan sekalipun penggunaan ulang (reuse) telah dicapai. Selain

itu, pewaisan ganda (multiple inheritance) memperumit pengujian karen meningkatkan

jumlah konteks dimana pengujian perlu dilakukan [Bin94a]. Jika subkelas yang

diinstansiasi dari superkelas digunakan dalam ranah masalah yang sama, maka ada

kemungkinan bahwa rangkaian test case yang berasal dari superkelas dapat digunakan

saat pengujian subkelas tersebut dilakukan. Namun, jika subkelas digunakan dalam

konteks yang sama sekali berbeda, maka kemampuan test case superkelas untuk

diaplikasikan menjadi kecil dan serangkaian pengujian baru harus dirancang.

19.4.2 Kemampuan Apliasi Metode Perancangan Test Case Konvensional

Metode pengujian kotak putih (white-box testing) yang diuraikan dalam Bab 18

dapat diterapkan untuk operasi yang didefinisikan bagi suatu kelas. Jalur dasar (basis

path), pengujian perulangan (loop testing), atau teknik alur data dapat membantu

memastikan bahwa setiap pernyataan dalam operasi telah diuji. Namun, struktur

ringkas mengenai berbagai operasi kelas menyebabkan beberapa orang berpendapat

bahwa upaya yang diterapkan pada pengujian kotak putih ,mungkin lebih baik

diarahkan lagi ke pengujian suatu tingkat kelas.

Metode pengujian koatak hitam adalah tepat untuk sistem OO karena pengujian

ini ditujukan untuk sistem yang dikembangkan dengan menggunakan metode rekayasa

perangkat lunak konvensional. Seperti yang dicatat pada Bab 18, use case dapat

memberikan masukan yang berguna dalam merancang pengujian kotak hitam dan

pengujian berbasis state.

19.4.3 Pengujian bebasis kesalahan

Objek pengujian berbasis kesalahan (fault-based testing) dalam sistem OO

adalah untuk merancang pengujian yang memiliki kemungkinan besar untuk

menemukan kesalahan yang masuk akal. Karena produk atau sistem harus sesuai

dengan kebutuhan pelanggan, perancangan awal yang dibutuhkan untuk melakukan

pengujian berbasis kesalahan dimulai dengan model analisis. Penguji mencari

kesalahan yang masuk akal (yaitu, aspek pelaksanaan sistem yang dapat

menyebabkan cacat program). Untuk menentukan apakah kesalaha ini ada, test cast

dirancang untuk menjalankan perancangan atau kode program.

Tentu saja, efektifitas dari teknik ini bergantung pada bagaimana penguji melihat

sebuah kesalahn masuk akal. Jika kesalahan nyata dalam sistem OO diangggap tidak

masuk akal, maka pendekatan ini benar-benar tidak lebih baik daripada teknik

pengujian acak. Namun, jika model analisis dan perancangan dapat memberikan

wawasan tentang apa yang mungkin salah, maka pengujian berbasis kesalahan dapat

menemukan sejumlah besar kesalahan yang signifikan dengan usaha yang dikuluarkan

relative kecil.

Pengujian integrasi mencari kesalahan-kesalahan yang masuk akal dalam

pemanggilan operasi atau koneksi pesan. Tiga jenis kesalahan yang ditemui dalam

konteks ini adalah hasil yang tak terduga, operasi/pesan yang digunakan salah, dan

invokasi yang salah. Untuk menentukan kesalahan masuk akal saat fungsi(operasi)

dipanggil, maka perilaku operasi harus diperiksa.

Pengujian integrasi diterapkan atribut maupun operasi “perilaku” sebuah objek

ditentukan oleh nilai-nilai yang atributnya diterapkan. Pengujian harus menjalankan

atribut untuk menentukan apakah nilai-nilai yang terjadi adalah tepat untuk jenis

perilaku objek yang berbeda.

Penting untuk dicatat bahwa pengujian integrasi berupaya untuk menemukan

kesalahan di objek klien, bukan pada server. Dinyatakan dalam istilah-istilah

konvensional, focus pengujian integrasi adalah untuk menentukan apakah ada

kesalahan dalam kode untuk pemanggilan, bukan kode untuk dipanggil. Operasi

panggil digunakan sebagai suatu petunjuk, suatu cara untuk menemukan persyaratan

pengujian yang menjalankan kode untuk pemanggilan.

19.4.4 Test Case dan Hierarki kelas

Pewarisan tidak meniadakan kebutuhan akan pengujian menyeluruh terhadap

semua kelas turunan. Pada kenyataannya, sebenarnya pewarisan mempersulit proses

pengujian. Perhatikan situasi berikut. Sebuah kelas Base berisi operasi inheriterd() dan

redefined(). Kelas Derived mendefinisikan kembali redefined() untuk berfungsi dalam

konteks local ada sedikit keraguan bahwa Derived::redefined() harus diuji karena

merupakan perancangan dan kode baru. Tetapi, apakah Derived::inherited() harus diuji

ulang?.

Jika Derived::inherited() memanggil redefined() dan perilaku redefined() telah

berubah, maka Derived::inherited() mungkin salah menangani perilaku baru. Oleh

karena itu, diiperlukan pengujian yang baru meskipun perancangan dan kode tidak

berubah. Akan tetati, penting untuk dicatat bahwa hanya sebagian dari semua

pengujian untuk Derived::inherited() yang harus dilakukan. Jika bagian perancangan

dan kode untuk inherited() tidak bergantung pada redefined() (yaitu tidak memanggil

kode itu ataupun tidak memanggil kode lain yang secara tidak langsung

memanggilnya), maka kode tersebut tidak perlu diuji ulang dikelas turunan.

Base::redefined() dan Derived::redefined() adalah dua operasi yang bebeda

dengan spesifikasi dan implementasinya yang berbeda masing-masing akan memiliki

persyaratan pengujian yang berasal dari spesifikasi dan implementasi. Persyaratan

pengujian tersebut memicu kesalahan yang masuk akal: kesalahan integrasi, kesalahan

kondisi, keslahan batas, dan sebagainya. Tetapi operasi –operasi tersebut mungkin

sama. Rangkaian persyaratan pengujian mereka akan tumpang tindih. Semakin baik

perancangan OO, semakin besar tumpang tindihnya. Pengujian baru perlu dilakukan

hanya untuk persyaratan Derived::redefined() yang tidak dipenuhi oleh pengujian

Base::redefined().

Singkatnya pengujian Base::redefined() diterapkan terhadap objek dari kelas

Derived. Masukan pengujian mungkin cocok untuk kelas induk maupun kelas turunan,

tetapi hasil yang diharapkan mungkin berbeda dengan hasil pada kelas turunan

19.4.5 Perancangan Pengujian Berbasis Skenario

Pengujian berbasis kesalahan mengabaikan dua jenis utama kesalahan berikut

ini, yaitu (1) Spesifikasi yang tidak tepat dan (2) Interaksi antara subsistem. Ketika

kesalahan yang berkaitan dengn spesifikasi yang tidak tepat maka produk tidak

mengerjakan apa yang diinginkan pelanggan. Mungkin melakukan sesuatu yang

salahatau mungkin menghilangkan fungsi yang penting. Tetapi dalam keadaan yang

lain, kualitasnya (Kesesuaian dengan persyaratan) rendah. Kesalahan yang

berhubungan dengan interaksi subsiste terjadi ketika perilaku sebuah sistem

menciptakan situasi-situasi (misalnya event, aliran data) yang menyebabkan subsistem

lain gagal.

Pengujian berbasis scenario berkonsentrasi pada apa yang dikerjakan

pengguna, bukan apa yang dikerjakan produk. Ini berarti menangkap tugas-tugas

(melalui use case) yang harus dilakukan oleh pengguna dan kemudian menerapkan

tugas-tugas beserta varian mereka sebagai pengujian-pengujian.

Skenario menemukan kesalahan-kesalahan interaksi. Tetapi untuk mencapai hal

ini test case harus lebih kompleks dan lebih realistis daripada pengujian berbasis

kesalahan. Pengujian berbasis scenario cenderung menjalankan banyak subsistem

dalam pengujian tunggal (pengguna tidak membatasi diri mereka terhadap penggunaan

sebuah subsistem pada suatu waktu). Sebagai contoh, perhatikan rancangan pengujian

berbasis scenario untuk editor teks dengan use case sebagai berikut.

Use case : memperbaiki dan Menyelesaikan Draft

Latar belakang : Tidaklah biasa untuk mencetak draft “final”, membacanya, dan

menemukan beberapa kesalahan yang mengganggu yang tidak jelas gambarnya dalam

layar. Use case ini menggambarkan urutan peristiwa yang terjadi ketika hal ini terjadi

1. Cetaklah seluruh dokumen

2. Telusuri dokumen tersebut, ubah halaman tertentu

3. Ketika setiap halaman berubah cetak halaman tersebut

4. Kadang-kadang sederetan halaman dicetak

Skenario ini menggambarkan dua hal yaitu (1) metode untuk mencetak halaman

tunggal dan (2) metode untuk mencetak sederet halaman. Sejauh pengujian berjalan,

ada kebutuhan untuk menguji penyuntingan setelah pencetakan (juga sebaliknya).

Karena itu anda harus merancang pengujian yang akan menemukan kesalahan-

kesalahan dalam fungsi penyuntingan yang disebabkan fungsi pencetakan, yaitu

kesalahan yang akan menunjukkan bahwa kedua fungsi perangkat lunak tidak benar-

benar independen

Use case : Cetak Salinan Baru

Latar belakang : Seseorang meminta pengguna sebuah salinan baru sebuah dokumen

dan salinan itu harus dicetak.

1. Buka dokumen

2. Mencetaknya

3. Tutup dokumen

Sekali lagi, pendekatan pengujian sangatlah jelas. Kecuali bahwa dokumen ini

memengaruhi tugas yang sudah ada sebelumnya.

Dikebanyakan editor modern, dokumen ingat bagaimana mereka terakhir

dicetak. Secara default, dokumen mencetak dengan cara yang sama pada waktu

berikutnya. Setelah scenario Memperbaiki Draft Final, hanya dengan memilih “print”

dimenu dan mengklik tombol print dikotak dialog akan menyebabkan halaman yang

terakhir dikoreksi tercetak lagi. Jadi, menurut editor, scenario yang benar akan terlihat

seperti ini :

1. Buka dokumen

2. Pilih “print” dalam menu

3. Periksa apakah anda mencetak satu deret halaman; jika ya klik untuk

mencetak dokumen.

4. Klik tommbol print

5. Tutup dokumen

Akan tetapi, scenario ini mengindikasikan spesifikasi potensial. Editor tidak melakukan

apa yang pengguna harapkan untuk dilakukan. Pelanggan akan sering mengabaikan

pengecekan yang dicatat dalam langkah 3. Mereka kemudian akan terganggu ketika

mereka berlari ke printer dan mendapati hanya satu halaman padahal mereka

menginginkan 100. Pelanggan yang terganggu ini memberikan sinyal bug-bug tertentu.

Ketergantungan ini mungkin tidak muncul saat anda merancang pengujian, namun ada

kemungkinan masalah akan muncul selama pengujian. Anda kemudian berpendapat

dengan respon “Itulah cara dimana sistem dapat diharapkan untuk bekerja”

19.4.6 Pengujian Struktur Permukaan dan Struktur Dalam

Struktur permukaan mengacu pada stuktur eksternal yang dapat diamati dari

program OO. Yaitu struktur yang sangant jelas bagi pengguna akhir. Daripada

melakukan fungsi, pengguna sistem OO dapat diberikan banyak objek untuk

dimanupulasi dalam beberapa cara. Apapun antarmukanya, pengujian masih

diddasarkan pada tugas-tugas pengguna. Pengerjaan tugas-tugas ini melibatkan

pemahaman, pengamatan, dan pembicaraan dengan pemakai representative (dan

banyak pemakai nonpresentatif yang perlu diperhatikan).

Pasti aka nada beberapa perbedaan rincian. Sebagai contoh, dalam sistem

konvensional dengan antarmuka berorientasi perintah (command-oriented) pengguna

dapat menggunakan daftar semua perintah sebagai daftar periksa pengujian. Jika tidak

ada scenario pengujian untuk menjalankan suatu perintah pengujian kemungkinan

besar mengabaikan tugas beberapa pengguna (atau antarmuka memiliki perintah yang

ak berguna). Dalam antarmuka berbasis objek, penguji dapat menggunakan daftar

semua objek sebagai daftar periksa pengujian.

Pengujian terbaik didapatkan ketika perancang melihat sistem dengan cara baru

atau tidak konvensional. Misalnya, jika sistem atau produk memiliki antarmuka berbasis

perintah, maka pengujian yang lebih menyeluruh akan diperoleh jika perancang test-

case menganggap bahwa operasi independen terhadap objek. “Tanyakanlah

pertanyaan seperti ini “Mungkinkah pengguna ingin menggunakan operasi ini yang

hanya berlaku untuk scanner- sementara sedang bekerja dengan printer ?” Apapun

gaya antarmukanya perancangan test case yang menjalankan struktur permukaan

harus menggunakan objek dan operasi sebagai petunjuk untuk tugas-tugas yang

terlupakan.

Struktur dalam mengacu pada detail teknis internal ayau suatu program OO,

yaitu struktur yang dimengerti dengan memeriksa rancangan dan/atau kode. Pengujian

struktur dalam ini dirancang untuk menjalankan dependensi, perilaku, dan mekanisme

komunikasi yang telah dibangun sebagai bagian dari model rancangan untuk perangkat

lunak OO.

Persyaratan dan model perancangan digunakan sebagai dasar untuk pengujian

struktur dalam. Sebagai contoh, diagram kolaborasi UML atau model deployment

menggambarkan kolaborasi antara objek dan subsistem yang mungkin tidak terlihat

secara eksternal. Perancang test case kemudian akan bertanya “Sudahkah kita

menagkap (sebagian suatu pengujian) beberapa tugas yang menjalankan kolaborasi

yang telah dicatat pada diagram kolaborasi? Jika tidak, mengapa tidak

melakukannya ?”

19.5 Metode-metode Pengujian yang Dapat Diaplikasikan Pada Level

Kelas

Pengujian “kecil” berfokus pada kelas tunggal dan metode-metode yang

terbungkus (enskapsulasi) oleh kelas. Pengujian acak dan partisi adalh metode yang

dapat digunakan untuk menjalankan kelas selama pengujian OO.

19.5.1 Pengujian Acak Untuk Kelas OO

Untuk memberikan ilustrasi singkat mengenai metode ini, perhatikan aplikasi

perbankan dimana kelas Account memiliki operasi-operasi berikut: open(), setup(),

deposit(), withdraw(), balance(), summarize(), creditLimit(), dan close() [Kir97]. Masing-

masing operasi tersebut dapat diterapkan untuk Account, namun kendala-kendala

tertentu (misalnya, account harus dibuka sebelum operasi-operasi lainnnya dapat

diterapkan dan account ditutup setelah semua operasi selesai) dismpulkan oleh sifat

masalah. Bahkan dengan kendala ini, ada banyak permutasi operasi. Sejarah

kehidupan prilaku minimum dari sebuah contoh (instance) Account meliputi operasi-

operasi berikut:

Open * open * deposit * withdraw * close

Hal ini merepresentasikan urutan pengujian minimum untuk account. Namun,

berbagai prilaku lain bias terjadi dalam urutan seperti ini:

Open * setup * deposit * [deposit | withdraw | balance | summarize |

creditLimit]ᴺ * withdraw * close

Berbagai urutan operasi yang berbeda dapat dihasilkan secara acak. Sebagai

contoh :

Test case r₁: open * setup * deposit * bakance * summarize * withdraw *

close

Test case r₂: open * setup * deposit * withdraw * deposit * balance *

creditLimit * withdraw * close

Urutan ini dan pengujian dengan urutan acak lainnya dilakukan untuk menjalankan

sejarah kehidupan instance kelas yang berbeda.

19.5.2 Pengujian Partisi di Level Kelas

Pengujian partisi mengurangi jumlah test case yang diperlukan untuk

menjalankan kelas dalam banyak cara yang sama dengan partisi kesetaraan (Bab 18)

untuk perangkat lunak tradisional. Masukan dan keluaran dikategorikan dan test case

dirancang untuk menjalankan setip kategori. Tetapi, bagaimana kategori partisi

didapatkan ?

Partisi berbasis-state mengelompokkan operasi-operasi kelas berdasarkan

kemampuan mereka untuk mengubah keadaan kelas. Dan, lagi, perhatikan kelas

Account, operasi-operasi state mencakup deposit() dan withdraw(), sedangkan operasi

nonstate meliputi balance(), summarize(), dan creditLimit(). Pengujian ini dirancang

sedemikian rupa sehingga menjalankan secara terpisah operasi-operasi yang

mengubah keadaan dan operasi yang tidak mengubah keadaan. Oleh karena itu,

Test case p₁: open * setup * deposit * deposit * withdraw * withdraw * close

Test case p₂: open * setup * deposit * summarize * creditLimit * withdraw *

close

Test case p₁ mengubah keadaan, smentara test case p₂ menjalankan operasi yang

tidak mengubah keadaan (selain operasi-operasi di urutan pengujian minimum).

Partisi berbasis atribut mengelompokkan operasi-operasi kelas berdasarkan

atribut yang merekagunakan. Untuk kelas Account, atribut balance dan creditLimit

dapat digunakan untuk menentukan partisi. Operasi dibagi menjadi tiga partisi: (1)

operasi yang menggunakan creditLimit, (2) operasi yang memodifikasi creditLimit,

dan (3) operasi yang tidak menggunakan ataupun memodifikasi creditLimit. Urutan

pengujian kemudian dirancang untuk setiap partisi.

Partisi berbasis kategori mengelompokkan operasi-operasi kelas berdasrkan

fungsi generic yang dilakukan masing-masing. Sebagai contoh, operasi di kelas

Account dapat dikategorikan dalam operasi inisialisasi (open, setup), operasi

cardInserted

password

deposit

withdraw

accountStatus

terminate

VerifyAccount

verifyPIN

verifyPolicy

withdrawReq

depositReq

accountInfo

komputasi (deposito, withdraw), query (balance, summarize, creditLimit) dan operasi

terminasi (close).

19.6 Perancangan Test case AntarKelas

Perancangan test case menjadi kian rumit saat integrasi system berorientasi

objek dimulai. Pada tahap inilah pengujian kolaborasi antarkelas harus dimulai.

seperti pengujian kelas individu, pengujian kolaborasi kelas dapat diselesaikan dengan

menerapkan metode acak dan partisi, serta pengujian berbasis scenario dan pengujian

perilaku.

19.6.1 Pengujian Banyak Kelas

Kirani dan Tsai [Kir94] menyarankan urutan langkah-langkah berikut untuk

menghasilakn beberapa test case kelas acak.

1. Untuk setiap kelas klien, gunakan daftar operasi kelas untuk menghasilakn

serangkaain urutan pengujian acak. Operasi ini akan mengirim pesan ke kelas

server lain

2. Untuk setiap pesan yang dihasilkan, tentukan kelas kolaborator dan operasi yang

sesuai dalam objek server.

3. Untuk setiap operasi pada objek server (yang telah dipanggil oleh pesan yang

dikirim dari objek klien), tentukan pesan yang dikirim.

4. Untuk setiap pesan, tentukan operasi di level berikutnya yang dipanggil dan

masukkan ke dalam urusan pengujian.

Diagram kolaborasi kelas untuk aplikasi perbankan

ATM User Interface ATM Bank

Sebuah test case acak untuk kelas Bank dapat berupa:

Test case r3 = verifyAccount + verifyPIN + depositReq

Untuk mempertimbangkan kolaborator yang terlibat dalam pengujian ini, pesan yang

terkait dengan masing-masing operasi dicatat dalam test case r3. Oleh karena itu,

sebuah test case baru yang menjalankan kolaborasi ini adalah:

Test case r4 = verifyAccount [Bank:validAccountValidationInfo] + verifyPIN

[Bank: validPINValiddationInfo] + depositReq [Bank: depositAccount]

19.6.2 Pengujian-pengujian yang Diturunkan dari Perilaku Model

Penggunaan diagram state sebagai model yang mewakili perilaku dinamis dari

suatu kelas dibahas dalam Bab 7. Diagram state untuk suatu kelas dapat digunakan

untuk membantu menurunkan suatu urutan pengujian yang akan melaksanakan

perilaku dinamis kelas (dan kelas-kelas yang berkolaborasi dengannya).

Test case masih bisa diturunkan lagi untuk memastikan bahwa semua perilaku

untuk kelas telah dilakukan secara memadai. Dalam situasi dimana perilaku kelas

menghasilakn kolaborasi dengan satu atau lebih kelas. Digunakan diagram banyak

state untuk menelusuri aliran perilaku dari system.

Setup Account

Deposit (Initial)

Deposit

Withdraw

balance

credit

accountInfo

Withdrawal (Final)

Close

Empty Account

Set Up Account

Working Account

Set Up Account

Dead Account

Model state dapat dilalui dengan cara “breadth-first” [McG94]. Dalam konteks ini,

breadth-first menyiratkan bahwa test case menjalankan transisi tunggal dan bahwa

transisi baru akan diuji hanya setelah transisi yang diuji sebelumnya digunakan.

Perhatikan objek CreditCard yang merupakan bagian dari system perbankan.

Keadaan awal dari CreditCard adalah undefined (yaitu tidak ada nomor kartu kredit

yang telah diberikan). Melalui pembacaan kartu kredit selama suatu penjualan, objek

mengambil keadaan defined , yaitu atribut card number dan expiration date, bersama

dengan pengidentifikasi ban-khusus didefinisikan. Kartu kredit diajukan ketika dikirim

untuk mendapat otorisasi, dan kemudian disetujui saat otorisasi diterima. Transisi

CreditCard dari satu keadaan ke keadaan lain dapat diuji dengan menggunakan test

case yang menyebabkan transisi terjadi. Pendekatan breadth-first pada jenis pengujian

ini tidak akan menjalankan submitted sebelum menjalankan undefined dan defined.

Jika sebaliknya, maka akan menggunakan transisi yang sebelumnya belum diuji dank

arena itu akan melanggar kriteria breadth-first.