save cli
v0.3.10
Save adalah kerangka kerja uji barisan-tujuan serba guna yang dapat digunakan untuk alat pengujian yang bekerja dengan kode, seperti penganalisa statis dan kompiler. Ini adalah aplikasi yang sepenuhnya asli, tidak perlu menginstal SDK apa pun.
Verifikasi dan Evaluasi Analisis Statis (SIVE) adalah ekosistem (juga lihat Save-Cloud) yang dirancang untuk evaluasi, pengujian, dan sertifikasi penganalisa statis, kompiler atau perangkat perangkat lunak lainnya. Alih-alih mengembangkan kerangka pengujian Anda sendiri, Anda dapat menggunakan Simpan sebagai aplikasi uji baris perintah. Satu -satunya persyaratan adalah menyiapkan sumber daya pengujian dalam format yang sesuai.
Kami membutuhkan bantuan Anda! Kami akan senang jika Anda akan menggunakan, menguji atau berkontribusi pada proyek ini. Jika Anda tidak punya banyak waktu untuk ini - setidaknya beri kami bintang untuk menarik kontributor lain! Terima kasih! ?
- Alat analisis kode saya memproses file secara berurutan, satu per satu ;
- Itu menghasilkan peringatan dan mengeluarkannya ke stdout ;
- Saya ingin membandingkan peringatan aktual dengan peringatan yang diharapkan yang ditentukan dalam kode sumber daya uji .
- Saya juga memiliki alat analisis kode, tetapi memproses seluruh proyek sekaligus dan menyadari semua hubungan kode .;
- Itu menghasilkan peringatan dan mengeluarkannya ke stdout ;
- Saya ingin membandingkan peringatan aktual dengan peringatan yang diharapkan yang ditentukan dalam kode sumber daya uji .
- Alat saya memanipulasi kode asli, misalnya, dengan memperbaiki otomatis;
- Saya ingin memeriksa bagaimana alat saya memperbaiki kode dengan membandingkannya dengan hasil yang diharapkan;
- Selain itu, dapat digunakan dengan kompiler untuk memvalidasi pembuatan kode , transisi dari sumber asli
- Kode ke Representasi Menengah (IR), bahasa pemrograman lain, atau bahkan perakitan.
- Saya tidak ingin menentukan peringatan yang saya harapkan dalam kode;
- Saya lebih suka menggunakan file terpisah dalam sarif atau format lainnya.
save "/my/path/to/tests" Pastikan direktori tests berisi file konfigurasi save.toml .
Untuk debug simpan eksekusi, Anda dapat menggunakan argumen berikut: --log=TYPE , di mana TYPE bisa menjadi salah satu dari yang berikut:
all - Logging komprehensif yang mencakup semua informasi dari simpan eksekusi, bahkan lebih rinci daripada debug (mirip dengan jejak).debug - Menampilkan hasil, peringatan, dan informasi debug.warnings - menunjukkan hasil dan peringatan kritis.results_only - hanya menampilkan hasilnya. 
Berikut adalah daftar plugin standar:
Jika Anda ingin beberapa plugin beroperasi di direktori Anda menggunakan file uji yang sama (sumber daya), cukup tambahkan semuanya ke konfigurasi save.toml :
[general]
...
[fix]
...
[warn]
...
[other plugin]
...
Anda dapat membaca lebih lanjut tentang warn plugin di sini
Save memiliki antarmuka baris perintah yang memungkinkan Anda menjalankan kerangka kerja dan executable Anda. Tugas utama Anda adalah mengonfigurasi output penganalisa statis Anda sehingga Simpan dapat memverifikasi apakah kesalahan yang sesuai ditandai pada baris yang benar dari kode uji.
Untuk memastikan peringatan itu akurat untuk Simpan, penganalisa statis Anda harus mengeluarkan hasilnya baik ke stderr/stdout atau file log yang ditunjuk (misalnya dalam format sarif).
Anda dapat mengonfigurasi perilaku umum Save menggunakan argumen baris perintah atau dengan menggunakan file konfigurasi bernama save.properties . File ini harus ditempatkan di direktori yang sama dengan root test config, save.toml .
Untuk daftar opsi yang komprehensif yang dapat diteruskan untuk save --help melalui baris perintah atau file save.properties . Perlu diketahui bahwa opsi dengan pilihan peka huruf besar-kecil.
Kerangka Simpan akan secara otomatis mendeteksi tes Anda, menjalankan penganalisa Anda, menghitung laju kelulusan, dan mengembalikan hasil tes dalam format yang diharapkan.
Untuk mengaktifkan Simpan untuk mendeteksi suite pengujian Anda, Anda harus menempatkan file save.toml di setiap direktori yang berisi suite tes . Penting untuk dicatat bahwa file konfigurasi ini mewarisi konfigurasi dari direktori induk.
Meskipun sebagian besar bidang dapat dibiarkan tidak terdefinisi pada level yang lebih rendah dan dapat mewarisi nilai -nilai dari level atas, Anda harus berhati -hati. Beberapa bidang di bagian [general] wajib untuk dieksekusi, jadi Anda perlu menentukannya dalam setidaknya satu file konfigurasi dalam rantai warisan untuk pengujian yang dimaksudkan untuk dijalankan. Periksa bidang mana yang wajib.
Misalnya, dengan hierarki direktori berikut:
| A
| save.toml
| B
| save.toml
save.toml di direktori B akan mewarisi pengaturan dan properti dari direktori A.
Ingatlah bahwa Save akan mendeteksi semua file dengan postfix 'tes' dan secara otomatis akan memanfaatkan konfigurasi dari file save.toml yang ada di direktori yang sama (atau diwarisi dari induk). Tes dinamai sesuai dengan nama sumber daya file uji, tidak termasuk akhiran 'tes'. Jika Save mendeteksi file dengan postfix 'tes' di sumber daya pengujian dan tidak dapat menemukan konfigurasi save.toml dalam hierarki direktori , itu akan melempar kesalahan.
Misalnya, skenario di bawah ini tidak valid dan akan memicu kesalahan, karena kerangka kerja Simpan tidak dapat menemukan file konfigurasi save.toml :
| A
| B
| myTest.java
Seperti yang disebutkan sebelumnya, save.toml sangat penting untuk mengkonfigurasi tes. Idealnya , harus ada satu file konfigurasi untuk setiap direktori yang berisi tes, membangun hubungan satu-ke-banyak. Kami menyebut direktori ini sebagai test suites .
Alasan di balik memiliki file konfigurasi tunggal untuk satu suite tes adalah untuk menghindari konfigurasi yang berlebihan dalam rangkaian tes yang sama.
Konfigurasi Simpan menggunakan format TOML yang ditenagai oleh proyek KTOML. Seperti disebutkan di atas, save.toml dapat diwarisi dari hierarki direktori (direktori induk).
File konfigurasi berisi tabel [general] dan tabel [plugins] . Untuk informasi lebih lanjut tentang plugin, lihat bagian plugin.
Di bagian ini, kami hanya akan memberikan informasi tentang tabel [general] , yang dapat digunakan di semua plugin.
[general]
# Your custom tags that will be used to detect groups of tests (required)
tags = ["parsing", "null-pointer", "etc"]
# Custom free text that describes the test suite (required)
description = "My suite description"
# Simple suite name (required)
suiteName = "DocsCheck", "CaseCheck", "NpeTests", "etc"
# Execution command (required at least once in the configuration hierarchy)
# By the default these binaries should be in the same directory of where SAVE is run
# or should have full or relational path (root - is the directory with save executable)
execCmd="./ktlint -R diktat-0.4.2.jar"
# Excluded tests in the suite (optional). Here, you can list the names of excluded tests, separated by commas. By default, no tests are excluded.
# To exclude tests, use the relative path to the root of the test project (to the root directory of `save.toml`)
excludedTests = ["warn/chapter1/GarbageTest.kt", "warn/otherDir/NewTest.kt", "etc"]
# Command execution time for one test (in milliseconds)
timeOutMillis = 10000
# Language for tests
language = "Kotlin"
Kadang -kadang, Anda mungkin hanya ingin menjalankan satu set tes tertentu alih -alih menjalankan semua tes di bawah konfigurasi save.toml tertentu. Untuk mencapai hal ini, lewati jalur relatif ke file uji setelah semua opsi konfigurasi (root - adalah direktori dengan save biner):
$ save [options] /path/to/tests/Test1Anda juga dapat memberikan daftar jalur relatif untuk menguji file (dipisahkan oleh spasi):
$ save [options] /path/to/tests/Test1 /path/to/tests/Test2 Simpan akan secara otomatis mendeteksi file save.toml terdekat dan menggunakan konfigurasi darinya.
Note: Pada Windows, ingatlah untuk menggunakan Backslash \ ganda sebagai pemisah jalur.
Simpan mendukung beberapa format untuk output laporan tes:
PLAIN : Tabel seperti penurunan harga yang menunjukkan semua hasil tes.PLAIN_FAILED : Mirip dengan PLAIN , tetapi hanya menampilkan tes yang gagal.JSON : Representasi terstruktur dari hasil eksekusi. Format yang diinginkan dapat dipilih menggunakan opsi --report-type=PLAIN .
Penggunaan analisis statis adalah bagian integral dari proses pengembangan untuk setiap produk perangkat lunak. Sementara pengembang perangkat lunak dapat menulis berbagai tes dan mencapai cakupan tes yang baik, kesalahan manusia tetap tidak dapat dihindari. Kesalahan semacam itu dapat mengakibatkan kerugian finansial yang signifikan bagi perusahaan. Analisis program statis membantu dalam mengidentifikasi dan memperbaiki bug dan masalah yang mungkin tidak dapat dideteksi melalui validasi kompiler saja.
Analisis statis hadir dalam berbagai bentuk dan melayani tujuan yang berbeda. Ini mungkin melibatkan analisis sederhana menggunakan AST (pohon sintaksis abstrak) atau mempelajari prosedur yang lebih kompleks seperti CFA (analisis aliran-aliran), analisis interprocedural, atau analisis konteks-sensitif. Analisis statis dapat menilai gaya kode, menunjukkan masalah runtime potensial dalam logika aplikasi, mendeteksi bau kode, dan menyarankan praktik terbaik. Namun, masih ada kurangnya kejelasan tentang fungsi inti dari analisis statis. Bagaimana kemanjurannya dapat diukur? Kriteria apa yang menentukan penerimaan mereka? Fungsi apa yang penting bagi pengembang yang menciptakan penganalisa baru? Meskipun bertahun -tahun pengembangan penganalisa statis, pertanyaan -pertanyaan ini sebagian besar masih belum terjawab.
Pada awal perjalanan pengembangan mereka, setiap pencipta penganalisa statis dimulai dengan mengidentifikasi jenis masalah yang akan ditargetkan oleh alat mereka. Ini sering mengharuskan pencarian untuk daftar masalah potensial yang ada atau paket pengujian yang dapat memandu proses pengembangan, terutama jika mengikuti pendekatan TDD (pengembangan berbasis tes). Sementara domain lain dalam pemrograman sistem telah menetapkan tolok ukur dan set uji, seperti tolok ukur spec.org yang digunakan secara global untuk mengevaluasi berbagai komponen perangkat lunak dan perangkat keras, tidak ada standar seperti itu untuk mengidentifikasi masalah dalam bahasa pemrograman populer. Sementara pedoman untuk pengkodean dalam C/C ++ telah ditetapkan oleh Misra, tidak ada padanan untuk bahasa yang banyak digunakan seperti python dan bahasa JVM. Ada tes suite yang tersedia di NIST, tetapi kerangka kerja dan ekosistemnya agak membatasi.
Mengingat skenario ini, pengembang sering menemukan diri mereka menciptakan mekanisme untuk analisis statis atau mengembangkan kerangka kerja uji baru, yang mengarah ke pekerjaan yang berulang. Beberapa mungkin memilih pedoman yang ada seperti gaya Google Code atau aturan PMD, tetapi terlepas dari pendekatannya, waktu yang signifikan selalu dihabiskan untuk mengonseptualisasikan, menulis, dan men -debugging tes.
Proyek ini menggunakan Gradle sebagai sistem pembuatannya dan dapat dibangun menggunakan perintah ./gradlew build .
Untuk menyusun artefak asli, Anda harus memasang prasyarat seperti yang dijelaskan dalam dokumentasi Kotlin/asli.
Untuk mengakses dependensi yang di -host pada Registry Paket GitHub, tambahkan yang berikut ini ke gradle.properties atau ~/.gradle/gradle.properties :
gprUser =<GH username>
gprKey =<GH personal access token> Token akses pribadi dapat dihasilkan di https://github.com/settings/tokens/new. Pastikan token memiliki ruang lingkup yang termasuk read:packages .
Karena kode yang dihasilkan, Anda perlu menjalankan build sekali untuk mengimpor proyek dengan benar ke IDE dengan impor terselesaikan.
