Tapi pertama-tama, perjalanan sejarah singkat: Apple WWDC (WorldWide Developers Conference), atau sekadar dub-dub, adalah konferensi yang diadakan Apple di California sejak akhir tahun delapan puluhan. Tahun ini, konferensi diadakan online untuk pertama kalinya. Dan jika tiket sebelumnya diundi dalam undian, dan mereka yang tidak menerima email yang diinginkan harus puas dengan video dari situs https://developer.apple.com/videos/ , maka tahun ini, untuk alasan yang jelas, tidak ada pilihan lain: semua orang menonton video ...
Jadi, apa yang bisa Anda lihat dari pengujian di sana?
Saya akan membuat reservasi segera bahwa pada WWDC 2020 tidak ada sesi umum besar yang didedikasikan untuk pengujian di ekosistem Apple, seperti tahun-tahun sebelumnya (Pengujian dalam Xcode 2019 dan Apa yang baru dalam pengujian 2018 ,2017 ). Pengujian hal baru pada tahun 2020 dioleskan ke dalam enam sesi mini. Pergilah!
XCTSkip untuk tes Anda
Xcode 11.4 menambahkan API baru untuk mengontrol peluncuran tes berdasarkan kondisi - XCTSkip.
Seringkali dalam tes, terutama tes integrasi, ada kondisi atau persyaratan yang tidak mudah dikaburkan. Misalnya, aplikasi memiliki beberapa fungsi spesifik untuk iPad yang tidak berfungsi pada iPhone. Atau beberapa fitur untuk versi tertentu dari sistem operasi.
Dan sebelumnya, ketika tes datang ke kasus-kasus seperti itu (memeriksa fungsionalitas khusus iPad di iPhone), ada pilihan:
- Akhiri uji kasus;
- Tandai tes saat lulus dan lanjutkan;
- Gagal ujian.
Kami sekarang memiliki kesalahan ketika tes saat ini berhenti berjalan dan ditandai sebagai dilewati.
Dengan demikian, sekarang XCTest memiliki tiga status untuk lulus ujian, bukan dua:
Lebih detail di sini dan di sini .
Penanganan interupsi dan peringatan dalam tes UI
Penanganan interupsi dan peringatan ada di XCTest sebelumnya, tetapi dalam sesi tersebut mekanisme operasinya terungkap lebih detail. Saya menemukan fungsionalitas baru yang menarik ditambahkan di Xcode 11.4, iOS / tvOS 13.4 dan macOS 10.15.4, yaitu, mengatur ulang izin (alias sumber daya yang dilindungi).
Intinya adalah ini: jika sebelumnya, misalnya, dalam uji # 1 Anda memberi akses aplikasi ke kamera atau kontak, maka nanti, dalam uji # 2, akses ini tidak begitu mudah untuk diambil. Untuk melakukan ini, Anda harus menginstal ulang aplikasi.
Sekarang, menggunakan API untuk mengatur ulang otorisasi untuk sumber daya yang dilindungi, Anda dapat memilih akses yang sebelumnya diberikan:
Class XCUIApplication {
open func resetAuthorizationStatus(for: XCUIProtectedResource)
}Mengatur ulang izin membuat aplikasi berperilaku seolah-olah tidak pernah meminta pengguna untuk mengakses sumber daya yang dilindungi sebelumnya.
Ini memungkinkan Anda untuk melangkah jauh dengan mengeluarkan dan mengumpulkan izin untuk kontak, kalender, foto, mikrofon, kamera, dan geolokasi. Di iOS, Anda juga dapat mengatur ulang akses ke Bluetooth dan akses jaringan Keyboard, dan mulai dengan Xcode 12 / iOS 14, ke data Health. Pada Mac OS, Anda dapat mengatur ulang akses ke direktori Desktop dan Unduhan.
Di bawah ini adalah contoh cara mengatur ulang akses aplikasi ke foto:
// Example
func testAddingPhotosFirstTime() throws {
let app = XCUIApplication()
app.resetAuthorizationStatus(for: .photos)
app.launch()
// Test code...
}Penting untuk diingat bahwa sering mengatur ulang (sering tidak mengatur ulang) izin membunuh aplikasi.
Lebih detail di sini , di sini dan di sini .
Menghilangkan animasi yang tertinggal dengan XCTest
Kelambatan animasi, atau halangan, adalah perilaku di mana bingkai muncul lebih lambat dari yang diharapkan.
Kuliah ini menjelaskan cara mencegah munculnya kelambatan dalam animasi aplikasi Anda dengan mengukur dan menguji menggunakan Performance XCTests.
Ini juga memberikan praktik terbaik dan mengidentifikasi keterlambatan mana yang dapat ditoleransi dan mana yang harus diwaspadai:
Menjelaskan mengapa keterlambatan kritis perlu diselidiki dan diperbaiki dengan cermat. Topik pengujian animasi itu sendiri cukup luas dan layak untuk artikel terpisah, jadi kami akan membatasi diri pada bagian pengantar dan tautan ke sumbernya .
Triase dan diagnosis tes jatuh
Sering kali memperbaiki tes yang gagal adalah rasa sakit yang membutuhkan banyak waktu dan sumber daya.
Xcode 12 akan memiliki API baru yang akan membuatnya lebih mudah untuk memperbaiki tes yang gagal. API seharusnya membantu menjawab pertanyaan dengan cepat: apa, bagaimana, mengapa, dan yang paling penting - di mana ia jatuh?
Jika sebelumnya, setelah tes jatuh, Anda harus mencari situs crash di
navigator Issue atau navigator laporan, kemudian dengan Xcode 12 proses pencarian menjadi lebih mudah: sekarang situs crash disorot dalam tes itu sendiri.
Kesalahan dengan penyorotan abu-abu muncul jika baris merujuk ke beberapa baris lain di masa depan:
Dan merah jika kesalahan terjadi secara langsung di baris ini:
Fitur baru yang nyaman - membuka editor kode tidak di jendela terpisah, tetapi langsung di navigator laporan:
Selain itu, objek XCTIssue baru ditambahkan dalam Xcode 12, yang, selain untuk merangkum data kesalahan yang sebelumnya dikumpulkan oleh XCTest sendiri (pesan, jalur, nomor baris dan bendera "Diharapkan"), sekarang menambahkan:
- Jenis yang berbeda;
- Detil Deskripsi;
- Kesalahan terkait;
- Lampiran.
Lebih detail di sini dan di sini .
Tulis tes untuk membuatnya gagal
Tujuan dari penguji adalah menulis tes untuk melihat mereka lulus hijau, yang berarti produk dapat dikirim ke pengguna akhir. Namun demikian, menulis tes untuk melihat mereka gagal juga diperlukan, karena tes yang gagal kemungkinan besar adalah bug yang ditemukan. Jadi, kita perlu menulis tes dengan memperhatikan fakta bahwa jika mereka gagal, kita akan memiliki cukup informasi untuk diselidiki.
Jadi apa yang disarankan:
Gunakan pesan yang bisa dibaca manusia dalam pernyataan:
Pastikan untuk menggunakan jenis pernyataan yang sesuai dengan situasi Anda:
Buka bungkusan opsional untuk membuat tes Anda mengalami kesalahan saat melempar kesalahan. Swift menyediakan beberapa cara untuk melakukan ini, tetapi tes cenderung menggunakan XCTUnwrap, yang merupakan penyederhanaan konstruksi let guard.
Gunakan waitForExistence () alih-alih sleep () untuk menunggu asinkron.
Gunakan XCTContext.runActivity () untuk meningkatkan keterbacaan log eksekusi tes:
Dan jika Anda ingin menambahkan logging tambahan, Anda dapat menambahkan lampiran, melampirkan tangkapan layar atau output debugger, seperti di sini. Fitur ini sangat berguna jika tes Anda berjalan dalam CI / CD.
Lebih detail di sini .
Dapatkan hasil uji coba lebih cepat
Sayang sekali ketika pada hari Senin pagi Anda mengetahui bahwa pekerjaan lama yang diluncurkan pada hari Jumat malam tidak berhasil sampai akhir, tergantung di tengah atau bahkan di awal. Dan Anda harus memulai minggu kerja Anda dengan tanya jawab: mengapa ini terjadi? Bagaimana Anda bisa menghindari situasi ini di masa depan?
Xcode 12 memperkenalkan alat anti-beku. Ini adalah opsi baru untuk ujian paket Execution Time Allowance.
Saat diaktifkan, Xcode menetapkan batas waktu tentang bagaimana setiap tes berjalan.
Jika batas terlampaui, Xcode melakukan hal berikut:
- Mengumpulkan laporan (spindump);
- Membunuh tes yang digantung;
- Mulai ulang pelari uji sehingga sisa suite dapat berjalan.
Laporan (spindump) menampilkan thread mana, yang fungsinya paling banyak menghabiskan waktu. Ini akan memungkinkan Anda untuk melihat hambatan dari tes Anda dengan mata Anda bahkan sebelum kopi / teh pagi Anda sudah dingin.
Secara default, 10 menit dialokasikan untuk setiap tes, dan jika tes selesai lebih cepat, maka timer diatur ulang ke nol untuk tes berikutnya. Jika Anda membutuhkan lebih banyak / lebih sedikit waktu untuk setiap tes di suite tes Anda, Anda dapat mengubah nilai default dalam pengaturan rencana tes.
Anda juga dapat melakukan ini menggunakan opsi perintah xcodebuild:
xcodebuild option
-default-test-execution-time-allowance <seconds>Demikian pula, Anda dapat mengatur waktu pelaksanaan tes maksimum:
xcodebuild option
-maximun-test-execution-time-allowance <seconds>Bahkan jika Anda perlu mengatur waktu eksekusi untuk tes atau kelas tes tertentu, ini juga dimungkinkan menggunakan API eksekusiTimeAllowance:
Class XCTestCase: XCTest {
var executionTimeAllowance: TimeInterval //
}Menyesuaikan pelaksanaan tes tertentu akan menghemat waktu Anda, tetapi ini tidak semua yang dapat dilakukan untuk mempercepat berlalunya suite uji panjang.
Xcode 12 memungkinkan Anda untuk menjalankan tes pada beberapa perangkat secara bersamaan. Fitur ini disebut Pengujian Terdistribusi Paralel. Manfaat menjalankan tes pada banyak perangkat sudah jelas - penghematan waktu yang layak.
Namun, sayangnya, ada juga jebakan: urutan peluncuran tes secara paralel tidak deterministik, tidak ada jaminan bahwa tes nomor 6 akan dieksekusi pada perangkat # 1 setelah uji nomor 5. Fakta ini harus diperhitungkan saat merencanakan tes peluncuran menggunakan Paralel. Pengujian Terdistribusi.
Secara umum, gagasan menjalankan tes secara paralel bukanlah hal baru. Ada peluang seperti itu sebelum Xcode 12, tetapi di Xcode 12 menjadi mungkin untuk menjalankan tes pada perangkat nyata (sejauh ini hanya menggunakan xcodebuild).
Perintah untuk menjalankan tes terdistribusi paralel adalah sebagai berikut:
xcodebuild test
-project MyProject.xcodeproj
-scheme MyProject
-parallel-testing-enabled YES
-parallelize-test-among-desinations
-destination 'platform=iOS,name=iPhone 11'
-destination 'platform=iOS,name=iPad pro' Lebih detail di sini .
Ini menyimpulkan ulasan fitur pengujian baru dari WWDC 2020. Terima kasih sudah membaca sampai akhir.
Saya harap Anda menemukan artikel ini bermanfaat. Selamat mencoba!