Get best of the week

Cara membuat mobil menulis tes dari kode untuk Anda

Kita hidup di dunia yang tidak sempurna. Orang-orang menulis kode di sini, dan orang secara alami cenderung membuat kesalahan . Semuanya akan baik-baik saja, kesalahan dapat ditangkap pada tahap pengujian dan tidak diizinkan untuk menyakiti siapa pun. Mungkin saja jika Anda menulis tes. Apa yang orang tidak suka lakukan karena suatu alasan. Tapi mungkin ada harapan - autogenerasi tes dari kode tertulis.

Julia Volkova ingin menguji gagasan itu dalam kenyataan dan berusaha mengalihkan pembuatan tes berdasarkan kode ke mesin, tanpa menggunakan instruksi atau kontrak tambahan. Julia akan memberi tahu Anda tentang penemuan-penemuan yang dibawa oleh perjalanan ke dunia metaprogramming, AST, parsing dan tokenization, dan apa semua ini telah memungkinkan kita untuk mencapai dalam autogenerasi tes, di Moscow Python Conf ++. Sementara itu, saya bertanya dari mana ide itu berasal - untuk mengotomatisasi pengujian, apa yang menjadi inti dari prototipe dan apa yang masih harus dilakukan.

Julia Volkova (xnuinside) Pengembang Python Senior di GridDynamics. Dalam waktu luangnya ia menulis proyek hewan peliharaan, yang kadang-kadang menemukan aplikasi dalam kehidupan nyata. Jadi, berulang kali menguji kode warisan, Julia memperhatikan bahwa banyak hal dapat dilakukan secara otomatis. Tentu saja, memahami kode dan menulis tes "benar" untuk itu terkadang terlalu sulit bagi pengembang yang berpengalaman. Tetapi otomasi dapat dengan baik melakukan banyak tes sederhana dan menyiapkan basis kode, yang dapat dimodifikasi oleh pengembang atas kebijakannya sendiri.

- Mari kita mulai dengan pasien sendiri, mengapa menurut Anda orang tidak menulis tes? Orang pintar mengatakan untuk menulis tes, tetapi mereka tetap tidak menulis. Mengapa ada masalah seperti itu?

- Saya pikir ada beberapa alasan. Pertama, kebanyakan dari kita malas di alam. Beberapa orang langsung suka menulis tes - bangun di pagi hari dan berkata: "Kita harus memulai hari dengan 15 tes, kalau tidak semuanya akan menjadi buruk, tetapi pada saat yang sama hidup saya tidak akan berhasil." Kemalasan alami lebih sering terwujud, terutama ketika Anda melihat bahwa metode ini tidak terlalu menarik, ia memiliki kode primitif yang jelas, tetapi Anda masih perlu menutupinya dengan tes.
Sedikit menulis TDD, jadi Anda tidak hanya harus menulis tes, Anda juga harus menghabiskan waktu pada kode.
Masalahnya adalah jumlah waktu tak terbatas tidak dialokasikan untuk pengembangan. Selalu ada produk Wishlist yang terbatas waktu. Dalam tim produk secara umum, sebagai aturan, semuanya diperlukan kemarin, karena waktu adalah uang. Tampaknya bagi para manajer bahwa semakin kita menghijaukan suatu fitur, semakin mahal produk kita. Dan tidak selalu jelas bahwa cakupan pengujian, kualitas kode secara langsung memengaruhi kecepatan penambahan fitur, dukungan kode, pembaruan, dll.

Kita sering menyalahkan segalanya pada manajer dan mengatakan bahwa mereka tidak memberi kita cukup waktu, kalau tidak kita akan duduk dan menulis tes. Sebenarnya, ini tidak selalu terjadi. Dan tidak selalu berpengalaman, pengembang yang kuat mengatakan untuk menulis tes, dan kolega yang lebih muda tidak mau.

Saya sudah berada di IT untuk waktu yang lama, tetapi saya telah terlibat langsung dalam pengembangan selama 3-4 tahun. Sebelum itu, saya bekerja lebih banyak di posisi manajerial dan melihat pengembang yang berbeda. Ada banyak orang yang tidak dapat disebut tidak berpengalaman, karena mereka telah menulis kode selama 10 tahun, tetapi pada saat yang sama mereka percaya bahwa tes seperti itu tidak diperlukan. Misalkan Anda tidak perlu menutup kode dengan tes unit, karena ada insinyur QA yang perlu menangkap bug. Dan mereka tidak berpikir bahwa insinyur seperti itu dapat mencakup tidak semua kasus dengan tes ujung ke ujung.

"Jika Anda tidak pergi ke ekstrem seperti itu, bagaimana menurut Anda, siapa yang harus menulis tes?" Haruskah itu programmer sendiri, junior atau, sebaliknya, pengembang paling keren di tim?

- Jika kita berbicara tentang unit test, pastinya bukan QA. Itu harus tes-tes yang diperiksa, lulus dan ditulis sebelum melakukan. Mereka harus diarahkan untuk menarik permintaan, dalam hal apa pun orang lain tidak harus menulisnya nanti. Sebagai contoh, saya, sebagai pengembang non-junior yang malas, hanya akan menempatkan junior untuk menulis tes untuk kode primitif. Ada beberapa hal yang cukup untuk hanya membaca kode di tingkat menengah dan menulis menegaskan, pekerjaan seperti itu sangat cocok untuk junior dan akan berguna untuk pengembangan mereka.

Ini adalah unit test yang hanya mencakup kode negara apa adanya. Tes-tes ini tidak memeriksa seberapa valid fungsi tersebut dalam kaitannya dengan persyaratan tugas dalam tugas, tetapi pastikan bahwa kode melakukan apa yang dilakukannya dan melakukannya dengan benar ...

Tetapi untuk memverifikasi validitas kode untuk persyaratan bisnis, untuk logika bisnis, bagaimanapun, seseorang yang mengimplementasikan persyaratan ini harus. Dia harus mengerti apa dan bagaimana dia meliput dengan tes. Tetapi tidak jelas bagaimana itu akan membantu jika seseorang awalnya tidak memahami masalah, menulis metode yang memecahkannya secara salah, tetapi melakukan tes yang benar untuk metode yang salah ini.

- Kita dapat mengatakan bahwa masalahnya adalah orang memiliki gagasan yang buruk tentang bagaimana proses pengembangan perangkat lunak berjalan?

- Ini sangat subjektif. Anda membayangkan diri Anda sebagai unit pengembang yang memahami bahwa tes diperlukan, mengapa diperlukan, dan Anda berpikir itu benar dan baik. Tetapi ada lapisan pengembang yang cukup besar yang percaya bahwa ini berlebihan. Dan, dalam arti tertentu, manajer mungkin benar dengan caranya sendiri ketika mereka mengatakan bahwa tes tidak perlu mencakup semua kode, hanya pengujian manual pada tahap ini sudah cukup.
Tidak selalu benar untuk mengatakan bahwa orang yang tidak menyukai tes adalah pengembang yang tidak terampil.
Dia memiliki beberapa penglihatannya sendiri, dan bukan untuk saya menghakimi. Saya masih sering bertemu dengan pengembang yang telah menulis kode selama 10 tahun dan mengatakan bahwa itu berlebihan untuk mencakup semuanya dengan unit test, pengujian asap yang cukup dan pekerjaan QA sudah cukup.

Saya, pada gilirannya, merasa tidak nyaman pada suatu proyek di mana tidak ada unit-tes untuk fungsi. Penting bagi saya bahwa setidaknya ada tes yang menjamin perlindungan terhadap faktor manusia, yang mampu menangkap koma yang ditempatkan secara acak atau mengubah nama kunci dalam suatu dikt. Tetapi saya tidak suka menghabiskan waktu untuk itu, karena saya selalu ingin melakukan lebih banyak tugas "pintar". Karenanya, saya berpikir tentang alat untuk mengotomatisasi proses penulisan tes.

- Apakah Anda berpikir bahwa Python diketik secara dinamis dan tidak memeriksa apa pun pada tahap kompilasi? Mungkinkah ini lebih mudah dalam bahasa lain dengan ini?

- Saya pikir, permainan, dan kuat. Ini adalah kisah abadi tentang jenis, tetapi dengan munculnya anotasi jenis, ini menjadi lebih mudah untuk dikerjakan.

Misalnya, dalam Python mungkin ada rantai fungsi bersarang, di mana yang diharapkan di akhir daftar karena beberapa alasan berubah menjadi kamus. Eksekusi mungkin tidak pernah mencapai fungsi akhir, tetapi dalam beberapa jika, dalam beberapa kasus luar biasa tidak, dan kemudian kesalahan akan muncul.

Tentu saja, dengan bahasa yang diketik ini pada prinsipnya tidak dapat terjadi, karena kesalahan sudah terjadi pada tahap kompilasi. Dalam hal ini, tentu saja, Python menyediakan cara-cara tambahan untuk menembak diri sendiri di kaki (di kepala dan di tempat lain). Terutama jika Anda bekerja dengan proyek-proyek besar dengan logika bercabang, di mana data dapat dituangkan ke dalam variasi yang berbeda, ke dalam agregasi yang berbeda.

- Lalu bagaimana dengan tipifikasi? Apakah menurut Anda mengetik harus maksimal atau minimum? Apa yang harus menjadi keseimbangan mengetik kode dinamis?

- Ini lagi sangat subyektif. Banyak orang datang ke Python justru karena tidak ada pengetikan dan karena semuanya sangat fleksibel dan nyaman. Anda tidak boleh melupakan hal ini dan jangan membuang banyak pengembang, termasuk ilmuwan data dan analis yang juga menulis kode. Misalkan saya, sebagai pengembang backend, tentu saja lebih nyaman ketika mengetik umumnya ada di mana-mana. Idealnya, mypy juga berfungsi.

Tetapi di sebagian besar proyek di mana saya berpartisipasi, ini tidak mungkin. Karena proyek ini juga memiliki analis data yang mengatakan itu karena mereka menulis dengan Python karena mereka tidak ingin mengacaukan jenis, sangat nyaman bagi mereka.
Sejumlah besar orang percaya bahwa ditambah Python karena tidak adanya tipe dan mengetik.
Anda perlu tumbuh ke tingkat tertentu untuk memahami kapan dan mengapa itu menjadi minus. Dalam beberapa skrip Python kecil atau dalam proyek kecil, saya juga tidak menggunakan tipe, karena saya tahu bahwa dalam skrip 2-fungsi, tipe tidak terlalu diperlukan. Tetapi ini adalah sesuatu yang, secara kasar, saya cepat-cepat lakukan pada lutut saya untuk menarik sesuatu keluar dari pangkalan. Dan dalam proyek yang lebih besar, saya mencoba untuk menambahkan jenis ke maksimum di mana-mana, jika tidak ada penolakan dari pengembang lain.

- Saya sepenuhnya setuju dengan Anda dalam hal ini. Tetap hanya untuk memahami cara menggunakan jenis, karena ini adalah topik yang tidak jelas terpisah.

: «, Haskell , : , . Python , , ».

— . , , legacy- smoke-. . ?

- Saya tidak akan mengatakan bahwa pendekatan saya lebih baik, hanya saja berbeda. Menutupi kode Anda dengan tes asap bagus saat Anda bisa. Proyek saya sebelumnya adalah rasa sakit klasik yang terkait dengan tes. Itu adalah platform ilmu data 8 microservices dan 20 ribu baris kode. Masalahnya adalah bahwa platform menerima sejumlah besar data dan karakteristik untuk kendaraan, stasiun dan kota, berbagai tempat parkir dan jenis persediaan, agregat dan menciptakan sejumlah besar jadwal potensial untuk kendaraan ini di seluruh dunia. Jadwal memperhitungkan sejumlah besar kondisi dari kategori di mana Anda dapat mengisi bahan bakar kendaraan, di mana harus berhenti sementara.

Ada banyak metode yang berbeda dalam sistem yang dapat digunakan dalam 1-2 situasi, yang, mungkin, bahkan tidak ada klien yang akan pernah ingat. Kemudian menulis tes asap sebenarnya berubah menjadi tes menulis untuk seluruh sistem, dengan mempertimbangkan semua fungsi dan kombinasinya.

Uji asap harus memeriksa bahwa semuanya berfungsi pada output dan tidak rusak minimal. Tes asap yang sangat primitif bahwa sistem dimulai dan entah bagaimana berfungsi tidak membawa manfaat apa pun dalam kasus kami. Katakanlah kita memeriksa bahwa ada koneksi ke database, ada sesuatu yang mulai, UI mendapatkan semacam API. Dan kemudian satu langkah ke kiri, satu langkah ke kanan - dan tidak ada yang berhasil. Artinya, ada tes asap, seolah-olah, tetapi kesalahan masih terbang dari produksi.

Dalam sistem ini, tes unit bekerja dengan baik: ketika dipantau dengan jelas bahwa fungsi tidak berubah, mereka tidak rusak setelah beberapa perubahan kode. Kode ini juga berbeda. Proyek yang berbeda, tugas yang berbeda memerlukan pendekatan pengujian yang berbeda pula.

Gagasan yang sedang saya kerjakan hanya bisa disebut tes generasi otomatis secara kondisional. Ini lebih merupakan alat pengembang. Saya ingin mendapatkan alat yang akan menulis tes untuk saya dan menjalankan semua kode yang dapat berjalan tanpa saya.

Saya akan memberi contoh. Ada fungsi kecil yang mengambil kamus, dari itu beberapa nilai dan kunci. Kunci ini sangat penting untuk bisnis, tetapi dari sudut pandang kode ini adalah operasi yang agak primitif: ambil dari kamus, bahkan jika itu adalah kunci bersarang beberapa kali; periksa apakah dia ada di sana, bahwa dia tidak nol; swap atau mungkin hanya mengembalikan nilainya. Ini adalah kode yang cukup primitif persis dari sudut pandang AST. Saya tidak ingin membuang waktu saya untuknya dan menulis tes. Saya ingin mobil melakukannya untuk saya.

Ini adalah program yang tepat dengan kode input dan kode output. Katakanlah, ke py-module, yang mengatakan: "Di sini saya menegaskan, saya" membantu "Anda bahwa ada peningkatan kesalahan dalam kondisi ini, nilai yang valid dikembalikan dalam situasi seperti itu, sesuatu yang lain terjadi dengan argumen seperti itu" . Yaitu, pada kenyataannya, ia melakukan pekerjaan di mana saya sendiri akan melihat apa yang diumpankan ke input fungsi dan menuliskannya dalam ujian.

Saya ingin program menghasilkan minimum yang dapat dijalankan untuk saya. Tetapi ini harus berupa file uji, di mana kemudian, jika diinginkan, Anda dapat mengubah atau memperluas sesuatu. Yang bisa Anda komit di Git, tes tes, dll.

- Seberapa banyak Anda dapat mengandalkan tes yang dibuat secara otomatis tersebut? Apa yang saya maksud - berapa banyak mereka terikat pada implementasi spesifik, dan bagaimana mereka akan berperilaku di bawah perubahan normal dalam logika bisnis atau refactoring?

- Idenya adalah untuk mengambil kode dalam bentuk yang sekarang, dan berdasarkan itu untuk menghasilkan tes yang valid saat ini.

Tentu saja, Anda dapat membuat ulang tes setiap waktu, tetapi ini tidak akan benar, karena dengan demikian tidak akan ada pelacakan status perubahan kode. Dengan demikian, masih ada perbedaan tes untuk ini, yaitu, tes hanya dihasilkan untuk apa yang belum tercakup oleh tes sebelumnya. Dan tes yang sudah dibuat perlu didukung oleh Anda sendiri.

Mungkin ini sedikit paranoia, tapi sejauh ini saya ragu bahwa dengan pembuatan otomatis dimungkinkan untuk memastikan bahwa dengan membuat ulang tes, Anda tidak akan mencakup kode yang valid dengan tes yang valid. Adalah satu hal ketika pada bulan Februari 2019 saya membuat tes, dan jika Anda mengubah logika, maka Anda mengubah tes sendiri, karena Anda tahu perubahan apa yang telah dibuat. Anda tahu mengapa tes jatuh, dan Anda dapat memperbaiki tes yang sesuai. Dan itu masalah yang sama sekali berbeda ketika Anda membuat ulang setiap waktu. Tes akan valid, tetapi hanya untuk kondisi kode yang diubah.
Saya ingin mendapatkan alat untuk pengembang, dan bukan bagian untuk meningkatkan cakupan kode.

- Apa yang bisa menjadi metrik keberhasilan? Bagaimana memahami bahwa kami menghasilkan tes dengan baik?

Saya akan menyebutkan apa yang saya perhatikan, yang tanpanya bagi saya tes itu tidak masuk akal. Sangat penting bahwa semua kasus perilaku kode yang dijelaskan oleh pengembang diproses dalam pengujian. Misalnya, jika ada jika tidak mengembalikan apa pun, tetapi menulis log, dalam pengujian log ini harus berfungsi. Bukan hanya itu orang menulis peringatan dan cetak. Oleh karena itu, jika di suatu tempat ada pemrosesan kenaikan-kesalahan, Anda harus menyelesaikannya dalam ujian. Jika tiba-tiba muncul, maka akan ada perubahan dalam logika kode, maka ini juga perlu diselesaikan.

Demikian pula, jika ada pernyataan-if, maka harus ada pemrosesan dalam setiap kondisi yang ditegaskan. Maka ujian akan lebih atau kurang mendekati kebenaran. Dan jangan lupa bahwa ini semua harus dimulai, dan tidak hanya mengeluarkan "kesuksesan" di PyTest dengan badan uji kosong.

- Katakan padaku betapa sulitnya secara teknis untuk melakukannya. Kedengarannya seperti tugas yang cukup sulit.

Ya, ini adalah tugas yang sangat sulit, dan mungkin fakta ini dan beberapa keadaan lain yang membuat saya membicarakan hal ini dalam sebuah laporan tentang Moscow Python Conf ++. Saya ingin mengangkat topik ini, menarik minat orang lain di dalamnya, dan mendiskusikan solusi dengan mereka.

Saya mempunyai perasaan bahwa tidak ada yang mencoba melakukan ini, karena tugasnya sulit. Kalau tidak, akan ada beberapa artefak di jaringan seperti kode, deskripsi, artikel, atau setidaknya menyebutkan bahwa ada hal seperti itu, tetapi ditinggalkan.

Untuk memahami betapa sulitnya ini, mari kita ingat kembali bagaimana penerjemah bekerja. Ada operasi, pernyataan dalam kode, penerjemah melakukannya - baik, tidak baik, gagal, tidak gagal - dan menghasilkan hasilnya. Selanjutnya, pengembang secara manual menambahkan argumen baru, memulai juru bahasa lagi, memastikan semuanya berhasil sekarang. Tetapi ketika Anda mencoba membuat tes untuk kode, pertama-tama Anda harus melalui pohon AST dan memahami langkah-langkah apa yang perlu Anda ambil untuk mendapatkan hasilnya.

Suatu fungsi dapat memiliki banyak kelompok argumen, strategi untuk argumen, dan banyak hasil untuk strategi ini. Berbicara tentang strategi, maksud saya, katakanlah, ada if arg_1==1: raise error. Ini berarti bahwa ada beberapa grup arg_1=1yang fungsinya selalu mengembalikan kesalahan. Tetapi dengan argumen, arg_1>2hasil dari fungsi akan berbeda, dan kelompok kedua akan dibuat, strategi kedua.

Oleh karena itu, kita perlu menemukan dan menyoroti semua kelompok argumen semacam itu (jika, tentu saja mereka), di mana fungsinya mengubah perilakunya. Dan kemudian ikuti rantai tindakan: apa yang akan terjadi di dalam fungsi dengan argumen ini untuk mendapatkan hasil akhir.

Selain itu, kami tidak lupa bahwa selain fakta bahwa ada beberapa argumen, ada juga tindakan di dalam fungsi, misalnya, menetapkan variabel, memanggil fungsi lainnya. Artinya, kami juga mendapatkan grafik ketergantungan metode pada metode, ketika untuk memeriksa beberapa kode Anda harus terlebih dahulu mendapatkan hasil dari kode lain.

Dengan demikian, untuk menghasilkan tes, Anda harus terlebih dahulu mendapatkan semua informasi yang diperlukan dari pohon AST, dan kemudian menghasilkan argumen, parameter, data untuk setiap strategi. Dengan mereka, lalui seluruh rangkaian tindakan, dapatkan hasilnya, dan hanya dengan begitu kita akan menjalani tes yang valid dengan berbagai pernyataan. Ini adalah tugas yang sulit.

Saya tidak berpikir bahwa suatu hari nanti akan mungkin untuk 100% mencakup semua jenis kasus secara otomatis, misalnya, untuk kanvas besar kode sumber Django. Itu melelahkan tetapi menarik. Sejauh ini saya hanya ingin tahu di mana saya memiliki kesabaran dan kekuatan untuk mencapainya.

- Apakah ada contoh dari bahasa lain dan area di mana sesuatu seperti ini berfungsi?

- Tidak ada yang serupa yang diketahui. Saya pikir karena lebih mudah untuk menulis tes daripada memotong alat khusus.
Tetapi saya punya perasaan bahwa cepat atau lambat kita akan mengotomatiskan apa yang sudah kita lakukan dengan baik.
Ada sekelompok besar pengembang yang menulis unit test dengan baik. Kami memiliki cukup kompetensi dalam pengembangan Python hingga ingin menulis alat atau pustaka yang melakukan ini untuk kami. Dan kita akan menulis hal-hal yang lebih kompleks, tes yang lebih kompleks.

Ada beberapa jenis generasi pengujian di Jawa, C, dan .Net. Tetapi di sana juga, semuanya lebih berbasis properti atau berbasis kontrak. Di C, ada generasi tes karakter-oleh-simbol, sepertinya hanya melihat kode dan atas dasar ini melakukan beberapa tes. Tetapi ini adalah tingkat abstraksi yang berbeda dalam bahasa itu sendiri sehingga saya tidak yakin apakah ini adalah cerita yang serupa.

Jika ada sesuatu yang sangat mirip, maka, tentu saja, orang bisa mengadopsi sesuatu, intip.

- Apakah Anda berpikir bahwa kerangka kerja atau mungkin teknik untuk menulis kode Python menyederhanakan atau mempersulit tugas menghasilkan tes dari pohon AST?

- Sulit untuk mengatakan apakah dalam pengertian ini sangat berbeda untuk hanya mengimpor beberapa perpustakaan atau menggunakan kerangka kerja yang langsung spesifik. Tentu saja, ini dapat sangat mempersulit pekerjaan sesuatu yang mengubah perilaku interpretasi proses kode, misalnya, ekstensi-C. Bagaimana menghadapi ini, saya belum tahu, tetapi penggunaan paket ketiga favorit saya sejauh ini dalam masalah ini terletak pada kebutuhan untuk menyelesaikan impor. Semuanya sederhana dengan paket bawaan, tetapi dengan impor semuanya menjadi lebih rumit. Mypy memiliki beberapa ide dan implementasi, tetapi saya belum menyentuh sejarah mengimpor paket pihak ketiga.

- Mungkin itu semacam teknik - banyak dinamika, penggunaan getattr - sesuatu seperti itu? Atau apakah itu berfungsi dengan baik?

"Ini hanya bekerja dengan sangat baik." Karena getattr atau manipulasi dengan metaclasses terlihat di AST. Ya, mereka perlu diselesaikan, dan ini menambah beberapa kompleksitas. Tapi ini tetap dilacak.

- Kami telah mengatakan bahwa tes yang dibuat secara otomatis terutama ditujukan untuk orang-orang. Seberapa mudah dibaca untuk orang? Akan ada banyak logika di dalam setiap tes, tegas? Seperti apa pemisahan antara kode dan data, bagaimana Anda melihatnya?

- Sekarang saya mencoba untuk awalnya menambahkan semua jenis hal dangkal ke tes. Misalkan, jika itu adalah semacam kesalahan kenaikan, maka itu bukan hanya dengan kenaikan gaji, tetapi setidaknya meninggalkan komentar, kesalahan macam apa, mengapa muncul, sehingga orang tersebut, setelah membaca tes, memahami apa yang sebenarnya terjadi, argumen apa yang mengarah pada kesalahan mana .

Pernyataan sejauh ini digabungkan dalam satu metode. Artinya, jika ada fungsi dan ada 5 status yang ingin kita periksa, maka sampai 5 menegaskan masuk ke dalam fungsi.

Ada ide untuk memperkenalkan konvensi nama, misalnya: menempatkan kesalahan di akhir kesalahan, log pengujian juga memiliki sesuatu sendiri. Tetapi saya telah menundanya untuk saat ini, karena pertanyaan tentang bagaimana membuat jenis tes terakhir dalam kode, secara langsung blok teks dengan tes, adalah operasi yang paling murah. Jika tiba-tiba muncul ide bahwa semuanya perlu diformat ulang, maka ini akan mudah dilakukan - ada rakitan yang siap pakai, Anda hanya perlu memilih tampilan berbeda untuk tes.

- Apakah Anda mendukung unittest atau pytest?

- Pytest. Dan hanya karena saya tidak ingin menghabiskan banyak energi untuk output sekarang. Pytest bagus karena ada banyak plugin, dekorator, berbagai pengubah untuk itu yang mudah digunakan.

Prettiness mungkin penting bagi pengguna akhir dan pengembang. Tapi ini sama sekali tidak mempengaruhi perkembangan ide. Jika Anda perlu mendukung unittest, ini dapat dengan mudah ditambahkan.

- Seberapa dekat pendekatan ini dengan tes berbasis properti?

- Sekarang, untuk menghasilkan argumen, hanya tipe moki yang digunakan: Anda perlu int, berikan int acak. Tetapi strategi seperti itu kemudian akan mudah untuk ditulis ulang, misalnya, mulai menggunakan hipotesis. Meskipun saya tidak menghabiskan banyak waktu dan usaha untuk ini, karena saya mengerti bahwa saya kemudian dapat menggunakan generator pihak ketiga untuk nilai. Sekarang, menurut saya, ini tidak sepenting bekerja dengan AST.

- Apakah Anda berencana untuk mendukung pemrograman kontrak atau entah bagaimana berpisah dengan cara khusus? Karena itu banyak membantu dalam bekerja dengan pengujian unit, pengujian berbasis properti, dan pengujian, pada prinsipnya, untuk memahami logika bisnis.

- Jika dengan pemrograman kontrak yang kita maksud adalah kontrak dalam kode, maka saya hanya menyimpang dari ini sebanyak mungkin. Karena ketika Anda dapat menggunakan pemrograman kontrak, pada dasarnya Anda dapat membuat kode kontrak dengan kontrak dan menghasilkan unit test berdasarkan mereka. Dan kemudian alat saya tidak begitu dibutuhkan.

Sekarang saya mencoba untuk tidak memikirkan apa pun yang memodifikasi kode. Karena, misalnya, dalam proyek outsourcing, di mana saya menghadapi masalah kurangnya tes - dan ini hampir semua proyek, sayangnya, di perusahaan saat ini - hampir tidak mungkin untuk menyentuh kode. Artinya, tidak mungkin melakukan perubahan sampai Anda dapat menjamin bahwa dekorator atau kontrak ini tidak akan mengubah seluruh komponen fungsional kode.
Jika mungkin untuk mengedit kode, maka tes kontrak bagus.
Tetapi untuk sekarang, saya melanjutkan dari kenyataan bahwa tidak ada kemungkinan seperti itu. Jadi, berdasarkan kontrak, Anda dapat membuat tes unit dan, pada kenyataannya, menerapkan duplikasi fungsi.

- Ceritakan pada kami tentang poin penting berikutnya: bagaimana cara menguji tes yang diterima dan seberapa banyak Anda dapat menjamin bahwa tes ini benar-benar menguji sesuatu?

- Pengujian mutasi belum dibatalkan, dan dalam gambaran dunia yang ideal itu pasti perlu digunakan dalam cerita ini. Gagasan secara keseluruhan adalah sama seperti jika tes itu ditulis oleh pengembang secara manual. Artinya, segala sesuatu yang tersedia untuk pengujian pengujian dapat diterapkan sepenuhnya.

- Sekarang mari kita sedikit membahas konferensi Moscow Python Conf ++. Kami akan tampilsalah satu pengembang hipotesis yang kami sebutkan beberapa kali. Apa yang ingin Anda tanyakan padanya?

- Saya akan tertarik untuk bertanya kepada Zach tentang di mana mereka ingin mengembangkan proyek bersama dengan pengelola: apa yang ditambahkan, cara mana yang harus dikembangkan. Saya tahu pasti bahwa Zach sekarang memiliki PR untuk generasi uji. Mereka melakukannya secara teratur. Lebih tepatnya, dekorator menambah tes unit yang ada.

Saya ingin membahas gagasan pembuatan tes otomatis dalam hal bagaimana hipotesis melihatnya, bagaimana kontributor melihatnya. Tentunya orang-orang yang terlibat dalam tes pada tingkat seperti itu memiliki beberapa ide atau mungkin seseorang telah mencoba sesuatu.

“Kami mengandalkan ini ketika kami sedang mempersiapkan program konferensi: untuk laporan untuk menetapkan topik untuk diskusi, di mana setiap orang akan menemukan ide dan arahan baru untuk pengembangan. Laporan apa yang akan Anda tuju?

- Saya ingin marah dan pergi ke semua laporan pada jam 12. Pada saat ini, akan ada Zac Hatfield-Dodds, Andrey Svetlov dengan laporan tentang pemrograman asinkron, dan Vladimir Protasov dengan otomatisasi refactoring . Saya akan pergi ke beberapa dari dua yang terakhir, dan kemudian berlari ke Zack di akhir laporan ( Ed: mengambil hacking kehidupan ke dalam layanan -. Hampir mendengar tema baru, dan kepada pembicara, dengan siapa Anda ingin berbicara, datang ke akhir laporan dan pertanyaan ) .

Pasti sangat menarikmelaporkan validasi data , saya tertarik secara langsung. Dan ada dua laporan lagi yang akan saya tuju, tetapi semuanya akan sejalan dengan saya: ini adalah laporan Vitaly Bragilevsky tentang pengetikan dan Christian Heime tentang pembuatan profil . Sayangnya, saya tidak bisa menghubungi mereka dengan cara apa pun.

- Ceritakan lebih banyak tentang topik laporan Anda, mengapa Anda melakukan, apa yang Anda lakukan, mengapa Anda berbicara dan apa yang Anda tunggu dari pidato?

- Saya ingin lebih banyak alat untuk mengotomatisasi proses pengembangan dan lebih banyak kolaborasi terkait dengan ini. Ada kegiatan seperti itu, tetapi dengan latar belakang terus-menerus menulis kode yang sama, menurut saya seharusnya ada lebih banyak.

Seperti yang saya katakan, tidak ada pengalaman terbuka dalam pengujian pembuatan otomatis dengan Python. Tidak jelas apakah ada yang melakukan ini, jika demikian, mengapa tidak lepas landas, tidak pergi. Saya tidak tahu berapa banyak generasi tes berbasis AST akan relevan bagi masyarakat, seberapa jauh dapat berlangsung. Sekarang saya melakukan ini karena saya tertarik pada proses itu sendiri, saya tertarik menggali melalui pohon AST, belajar lebih banyak tentang cara kerja kode Python, dan menemukan banyak nuansa berbeda yang tidak jelas ketika bekerja dengan kode tingkat atas. Bekerja dengan pohon AST membawa banyak penemuan mendadak.

Saya ingin orang-orang memiliki ide setelah laporan, misalnya, cara mengotomatisasi sesuatu yang mereka gunakan dalam pekerjaan mereka. Sehingga beberapa dari mereka berhenti menulis potongan kode yang sudah mereka tulis setiap hari, dan mulai menghasilkan atau mengurangi jumlah waktu untuk menulisnya. Saya harap seseorang keluar dengan pemahaman baru tentang cara mengatasi masalah ini.

- Di mana Anda meluangkan waktu untuk berbicara di konferensi, menulis perpustakaan Anda sendiri? Pertanyaan ini sebenarnya muncul terus-menerus, banyak orang mengeluh bahwa mereka tidak punya waktu untuk apa pun.

- Pertama, tentang waktu. Saya bukan karyawan yang sangat nyaman bagi banyak perusahaan dalam arti bahwa saya tidak melakukan hal-hal yang tampaknya tidak efektif bagi saya. Saya mencoba melakukan hal-hal yang benar-benar menarik bagi saya, atau yang dapat saya lakukan secara efektif dan benar. Jika, misalnya, seorang manajer ingin saya memperbaiki beberapa jenis bug saat ini, yang sebenarnya bukan bug, tetapi daftar harapan pelanggan baru, saya tidak akan duduk dan memperbaiki semuanya kembali, karena saya tahu bahwa pelanggan akan kembali dan mengatakan mengapa Anda melakukannya.
Saya mencoba untuk tidak melakukan pekerjaan yang tidak perlu di tempat kerja, tidak melakukan apa yang akan menyebabkan hilangnya waktu saya setelahnya.
Misalkan, jika mereka meminta saya untuk menyebarkan pada hari Jumat, saya berkata: "Guys, aku sangat mencintaimu, kalian semua adalah rekan yang hebat, tetapi jika Anda perlu mengerahkan sesuatu sekarang, silakan sebarkan diri Anda, dan saya akan pulang. Saya dapat menyebarkannya pada hari Senin, kita dapat berbicara tentang mengapa situasi seperti itu terjadi, yang ingin Anda terapkan sekarang pada hari Jumat. ” Mungkin menyakitkan untuk pertama kalinya memberi tahu pelanggan atau manajer ini, tetapi kemudian orang-orang terbiasa, belajar, dan tidak meminta Anda melakukan sesuatu yang sangat mendesak pada Jumat malam. Mereka mengerti bahwa, pertama, tidak ada yang mati Jumat lalu, ketika tidak ada yang kebanjiran, dan bahkan tidak ada yang kehilangan uang. Saya berusaha untuk tidak melakukan sesuatu yang akan membahayakan saya.

Kisah yang sama tentang bug - jika ada banyak bug yang harus diperbaiki terus-menerus, pertanyaannya adalah: mengapa bug ini muncul. Kita seharusnya tidak memperbaikinya, tetapi pikirkan mengapa ada begitu banyak dari mereka, dari mana mereka berasal dan bertarung terutama dengan masalah akar. Ini juga selalu merupakan masalah yang menyakitkan, ketika seorang manajer atau pelanggan mengatakan bahwa kebutuhan mendesak untuk memperbaiki fitur dalam produksi. Tetapi Anda harus dapat mengatakan bahwa jika saya menyentuh kode ini sekarang, maka mungkin Anda memiliki sesuatu selain fitur ini, Anda tidak akan memiliki produksi, karena kode tersebut tidak tercakup oleh tes, Anda tidak dapat menambahkan yang lain jika ke dalamnya, karena kami tidak ingat apa yang enam lainnya lakukan.

Terkadang Anda perlu mengatasi diri Anda dan mulai berbicara. Ini tidak selalu mungkin, perlu untuk tumbuh ke tingkat kesadaran tertentu bahwa untuk berapa banyak waktu yang Anda habiskan untuk jenis pekerjaan apa, Anda bertanggung jawab.

Karena itu, saya mungkin punya waktu. Karena saya mencoba mengoptimalkan waktu kerja saya, untuk membuatnya butuh beberapa jam untuk menyelesaikan tugas. Pada saat yang sama, saya mengerti bahwa dalam struktur yang baik harus ada 1-2 jam untuk hutang teknis dan beberapa perbaikan.

Saya tidak akan mengatakan bahwa saya bekerja 8 jam tanpa bangun. Saya akan melihat seorang pengembang yang duduk dan menulis kode selama 8 jam waktu kerja. Jika Anda mengambil hari kerja saya yang biasa, maka 2 jam hanyalah segala macam tes, review kode, hutang teknis, "buzz" pada kode. Jam 3 adalah solusi untuk masalah saat ini, satu jam untuk berkomunikasi dengan manajer. Dan sisa 2 jam tersebar untuk beberapa alasan, untuk diskusi dengan tim dan hal-hal lepas.

Ada hal-hal yang Anda tertarik lakukan - Anda lakukan, dan ketika Anda tidak memiliki kekuatan, mereka memberi Anda kekuatan. Saya memiliki banyak kegiatan berbeda - ini mungkin disebut penundaan yang berguna - ketika saya melakukan apa yang saya minati saat ini, dan bukan apa yang perlu saya lakukan. Jika Anda belajar untuk bervariasi antara apa yang menarik dan apa yang masih dibutuhkan, itu ternyata menjadi yang paling sukses. Anda tidak perlu membuang waktu untuk melakukan apa yang tidak Anda inginkan.

Tidak ada rahasia, Anda hanya perlu melakukan apa yang Anda suka, tetapi pada saat yang sama tanpa membahayakan orang-orang di sekitar Anda dan proyek.

Untuk detail penerapan uji generasi dari kode Python, serta menyelesaikan banyak tugas pengembang Python lainnya, datang ke Moscow Python Conf ++ , yang kami tunda hingga 15 September.

More articles:


All Articles