Mengapa ujian unit? Bagaimana untuk menjalankan ujian?

Berikut ialah pautan kepada video saya bercakap tentang topik ini

Jika anda tidak menyukai video, berikut ialah versi panjang lebar.

Perisian

Perisian boleh ditukar. Inilah sebabnya ia dipanggil "perisian". Keplastikannya lebih kuat daripada perkakasan. Pasukan jurutera yang hebat harus menjadi aset yang menakjubkan kepada syarikat, menulis sistem yang terus menambah nilai apabila perniagaan berkembang.

Jadi mengapa kita begitu teruk dalam hal ini? Berapa banyak projek yang pernah anda dengar tentang yang gagal sepenuhnya? Atau ia menjadi "warisan" dan mesti ditulis semula sepenuhnya (penulisan semula biasanya gagal juga!)

Bagaimana sistem perisian "gagal"? Tidak bolehkah ia diubah suai sebelum betul? Ini janji kami!

Ramai orang memilih untuk membina sistem dalam Go kerana ia telah membuat banyak pilihan yang diharapkan orang akan menjadikannya lebih sah. [Cadangan berkaitan: Pergi tutorial video]

• Berbanding dengan kerjaya Scala saya sebelum iniSaya menyifatkannya sebagai membuatkan anda mempunyai keinginan untuk menggantung diri , Go hanya mempunyai 25 kata kunci dan banyak sistem yang boleh dibina daripada perpustakaan standard dan beberapa perpustakaan kecil lain. Visinya ialah dengan Go anda boleh menulis kod dan melihatnya semula dalam masa 6 bulan dan ia masih akan masuk akal.

• Alat untuk ujian, penanda aras, penghuraian semantik dan pemuatan adalah yang terbaik berbanding kebanyakan alternatif.

• Perpustakaan standard yang hebat.

• Gelung maklum balas yang ketat menjadikan kompilasi sangat pantas

• Go mempunyai komitmen keserasian ke belakang. Nampaknya Go akan mendapat generik dan ciri lain pada masa hadapan, tetapi pereka bentuk telah berjanji bahawa walaupun kod Go yang anda tulis 5 tahun lalu masih akan dibina. Saya telah menghabiskan beberapa minggu menaik taraf projek saya daripada Scala 2.8 kepada 2.10.

Walaupun dengan semua sifat hebat ini, kami masih boleh membuat sistem yang tidak baik, jadi kami harus mengkaji semula kejuruteraan perisian yang lalu tanpa mengira sama ada bahasa yang anda gunakan bagus atau tidak dan memahaminya pelajaran yang dipelajari.

Pada tahun 1974, seorang jurutera perisian pintar bernama [Manny Lehman](https://en.wikipedia.org/wiki/Manny_Lehman...) menulis Dimuat turun Evolusi Perisian Lehman Undang-undang.

Undang-undang ini menerangkan keseimbangan antara kuasa yang memacu perkembangan baharu dan kuasa yang menghalang kemajuan.

Ini adalah kuasa yang perlu kita fahami jika kita tidak mahu sistem yang kita bangunkan menjadi warisan dan ditulis semula berulang kali.

Undang-undang perubahan berterusan

Sistem perisian yang digunakan dalam kehidupan sebenar mesti sentiasa berubah, jika tidak, ia akan dihapuskan oleh persekitaran umum

Jelas sekali, satu sistem mesti terus berubah, jika tidak, ia akan menjadi semakin tidak berguna, tetapi mengapa keadaan ini sering diabaikan? menghantar projek mengikut tarikh yang ditentukan, dan kemudian mereka meneruskan ke projek seterusnya. Sekiranya perisian itu "bertuah", sekurang-kurangnya ia akan diserahkan dalam beberapa bentuk kepada kumpulan orang lain untuk mengekalkannya, tetapi mereka pastinya tidak akan terus mengulanginya.

Orang ramai sering bimbang dengan memilih rangka kerja untuk membantu mereka "menyampaikan dengan cepat" daripada menumpukan pada ketekunan sistem.

Walaupun anda seorang jurutera perisian yang hebat, anda masih boleh menjadi mangsa kerana tidak memahami keperluan masa depan sistem anda. Apabila perniagaan anda berubah, kod hebat yang anda tulis mungkin tidak lagi berkaitan.

Lehman sangat berjaya pada tahun 1970-an kerana dia memberi kami satu lagi peraturan yang patut difikirkan.

Hukum peningkatan kerumitan

Apabila sistem berkembang, kerumitan sistem akan terus meningkat melainkan langkah diambil untuk mengurangkan peningkatan dalam sistem kerumitan.

Apa yang dia ingin katakan sekarang ialah: Kami tidak boleh membiarkan pasukan perisian menjadi kilang fungsi tulen, hanya dengan menumpukan lebih banyak fungsi pada perisian supaya sistem boleh terus berjalan untuk masa yang lama.

Apabila landskap pengetahuan kami berubah, kami

mesti

terus mengurus kerumitan sistem kami.

Refactoring

Pembangunan perisian boleh mengekalkan keplastikan perisian dalam

banyak

aspek, seperti:

Keizinan Pembangun
Secara amnya kod "baik". Fokus pada pemisahan kod yang munasabah, dsb.
Keupayaan komunikasi
Senibina
Kebolehcerap
Kebolehlaksanaan
Ujian automatik
Gelung tertutup
Saya akan fokus pada pemfaktoran semula. Pandangan biasa yang didengar daripada pembangun pada hari pertama pengaturcaraan mereka ialah "kita perlu memfaktorkan semula ini".

Ayat ini berasal dari dan? Bagaimanakah pemfaktoran semula berbeza daripada menulis kod?

Saya tahu saya dan ramai lagi berfikir bahawa kami sedang memfaktorkan semula, tetapi kami silap.

Martin Fowler menerangkan cara orang membuat kesilapan

Walau bagaimanapun, "pemfaktoran semula" sering digunakan di tempat yang tidak sesuai. Jika seseorang membincangkan sistem yang tidak berfungsi selama beberapa hari semasa mereka memfaktorkan semula, anda boleh pastikan mereka tidak memfaktorkan semula.

Apa itu?

Pemfaktoran

Apabila anda belajar matematik di sekolah, anda mungkin belajar tentang pemfaktoran. Berikut ialah contoh pengiraan

yang sangat mudah 1/2 1/4

Untuk melakukan ini, faktorkan penyebut menjadi , menukar ungkapan menjadi

2/4 1/4 Anda boleh mengubahnya menjadi 3/4.

Kita boleh belajar beberapa pengajaran penting daripada ini. Apabila kita menguraikan ungkapan , kita tidak mengubah maksud ungkapan . Kedua-duanya sama dengan 3/4, tetapi tugas kami menjadi lebih mudah dengan menukar 1/2 kepada 2/4; ia lebih sesuai dengan "domain" kami.

Apabila anda memfaktorkan semula kod anda, anda harus cuba mencari cara untuk menjadikan kod anda lebih mudah difahami sambil "memastikan" keperluan sistem semasa anda. Kuncinya ialah bahawa anda tidak seharusnya mengubah tingkah laku asal kod

Contoh daripada Go

Kaedah berikut menggunakan Salam languagename

func Hello(name, language string) string {
    if language == "es" {
        return "Hola, " + name
    }

    if language == "fr" {

        return "Bonjour, " + name

    }

    // 想象一下更多的语言

    return "Hello, " + name

}

Rasa tidak selesa jika terdapat berpuluh-puluh

kenyataan, dan kita perlu berulang kali menggunakan if khusus untuk mengiringi language salam ,. Jadi mari kita refactor kod. name

func Hello(name, language string) string {
      return fmt.Sprintf(
          "%s, %s",
          greeting(language),
          name,
      )
}

var greetings = map[string]string {
  es: "Hola",
  fr: "Bonjour",
  //等等...
}

func greeting(language string) string {
  greeting, exists := greetings[language]

  if exists {
     return greeting
  }

  return "Hello"
}

Sebenarnya sifat refactoring ini tidak penting, yang penting kita tidak mengubah tingkah laku kod tersebut.

Apabila memfaktorkan semula, anda boleh melakukan apa sahaja yang anda suka, menambah antara muka, jenis baharu, fungsi, kaedah, dsb. Satu-satunya peraturan ialah anda tidak boleh mengubah tingkah laku kod.

Jangan tukar kefungsian semasa memfaktorkan semula kod

Ini sangat penting. Jika anda menukar fungsi semasa pemfaktoran semula, anda sedang melakukan

dua perkara pada masa yang sama. Sebagai jurutera perisian, kita harus belajar untuk memisahkan sistem kepada fail/pakej/fungsi/dll yang berbeza kerana kita tahu bahawa cuba memahami sebahagian besar sesuatu adalah sukar.

Kita tidak seharusnya memikirkan banyak perkara sekaligus kerana itu akan membuatkan kita melakukan kesilapan. Saya telah menyaksikan banyak usaha pemfaktoran semula gagal kerana pembangun menggigit lebih daripada yang mereka boleh kunyah.

Semasa saya memfaktorkan dengan pen dan kertas dalam kelas matematik, saya terpaksa menyemak secara manual sama ada saya telah menukar maksud ungkapan di kepala saya. Apabila kita memfaktorkan semula kod, terutamanya pada sistem kritikal, bagaimana kita tahu jika kita telah menukar fungsi

Mereka yang memilih untuk tidak menulis ujian sering bergantung pada ujian manual. Melainkan ia adalah projek kecil, ini akan menjadi masa yang besar dan tidak kondusif untuk pengembangan sistem masa depan dalam jangka masa panjang.

Untuk memfaktor semula dengan selamat, anda memerlukan ujian unit kerana ia menyediakan

• untuk memfaktorkan semula kod tanpa perlu risau tentang perubahan fungsi

• Membantu pembangun menulis dokumentasi tentang cara sistem harus dijalankan

• Maklum balas yang lebih pantas dan lebih dipercayai daripada ujian manual

Satu contoh dalam Go

Kami mempunyai ujian unit untuk kaedah

seperti ini:Hello

func TestHello(t *testing.T) {

    got := Hello("Chris", es)

    want := "Hola, Chris"

    if got != want {

        t.Errorf("got %q want %q", got, want)

    }

}

Dalam baris arahan, kami boleh menjalankan

, dan anda boleh mendapatkan maklum balas segera tentang sama ada kerja pemfaktoran semula kami menjejaskan operasi program asal. Sebenarnya, lebih baik belajar menjalankan ujian dalam editor/IDE. go test

Anda ingin mendapatkan status berjalan program anda

• Pemfaktoran semula kecil

• Jalankan ujian

• Ulang

Semuanya dalam gelung maklum balas yang sangat ketat supaya anda tidak melakukan kesilapan.

Mempunyai projek di mana semua gelagat utama anda diuji unit dan diberi maklum balas dalam masa sesaat adalah jaringan keselamatan yang sangat berkuasa untuk membuat keputusan yang berani apabila anda perlu Refactor. Ini membantu kami menguruskan kerumitan yang semakin meningkat yang diterangkan oleh Lehman.

Ujian unit sangat hebat, kenapa kadangkala ada rintangan untuk menulisnya?

Di satu pihak, ada mereka (seperti saya) yang mengatakan ujian unit adalah penting untuk kesihatan jangka panjang sistem anda kerana ia memastikan anda boleh meneruskan pemfaktoran semula dengan yakin.

Sebaliknya, ada yang mengatakan bahawa ujian unit sebenarnya

menghalang pemfaktoran semula.

Tanya diri anda, berapa kerap anda perlu menukar ujian semasa pemfaktoran semula? Saya telah terlibat dalam banyak projek selama bertahun-tahun yang mempunyai liputan ujian yang sangat tinggi, tetapi jurutera enggan memfaktorkan semula kerana mereka fikir menukar ujian itu akan menyusahkan.

Ini bertentangan dengan janji kami!

Kenapa ni?

Andaikata anda diminta melukis segi empat sama, kami fikir cara terbaik ialah melekatkan dua segi tiga.

Dua segi tiga tegak membentuk segi empat sama

Kami menulis ujian unit di sekeliling segi empat sama untuk memastikan kedua-dua belah adalah sama dan kemudian kami menulis beberapa ujian di sekeliling segi tiga. Kami ingin memastikan segitiga kami diberikan dengan betul supaya kami menegaskan bahawa jumlah sudut ialah 180 darjah, kami melakukan dua ujian untuk menyemak, dsb. Liputan ujian adalah sangat penting dan menulis ujian ini sangat mudah, mengapa tidak

Beberapa minggu kemudian perubahan undang-undang melanda sistem kami dan pembangun baharu membuat beberapa perubahan. Dia kini berfikir bahawa adalah lebih baik untuk membuat segi empat sama daripada dua segi empat tepat daripada dua segi tiga.

Dua segi empat tepat membentuk segi empat sama

Dia mencuba pemfaktoran semula ini dan mendapat beberapa petunjuk daripada beberapa ujian yang gagal. Adakah dia benar-benar memecahkan fungsi penting kod itu? Dia kini mesti mendalami ujian segitiga ini dan cuba memahami apa sebenarnya yang berlaku di dalamnya.

Sebenarnya tidak penting bahawa segi empat sama terdiri daripada segi tiga, tetapi ujian kami tersilap meningkatkan kepentingan butiran pelaksanaan.

Kefungsian ujian dan bukannya butiran pelaksanaan

Apabila saya mendengar orang mengadu tentang ujian unit, biasanya kerana ujian berada pada tahap abstraksi yang salah. Mereka semua sedang menguji butiran pelaksanaan, memerhati kod rakan usaha sama mereka secara taksub dan membuat banyak ejekan.

Saya percaya masalah ini disebabkan oleh salah faham mereka terhadap ujian unit dan mengejar metrik (liputan ujian).

Jika saya bercakap tentang hanya menguji kefungsian, bukankah kita sepatutnya menulis ujian sistem/kotak hitam? Jenis ujian ini sememangnya mempunyai banyak nilai dalam mengesahkan perjalanan pengguna utama, tetapi ia selalunya mahal untuk ditulis dan lambat dijalankan. Atas sebab ini, mereka tidak begitu membantu untuk pemfaktoran semula kerana gelung maklum balas adalah perlahan. Tambahan pula, berbanding dengan ujian unit, ujian kotak hitam tidak banyak membantu dalam menyelesaikan masalah asas.

Jadi apakah tahap abstraksi yang betul?

Menulis ujian unit yang berkesan ialah perkara reka bentuk

Lupakan sebentar tentang ujian, lebih baik masukkan "unit" yang serba lengkap dan dipisahkan dalam sistem anda, Center mengenai konsep utama dalam bidang anda.

Saya suka menganggap unit ini sebagai bata LEGO ringkas dengan API konsisten yang boleh saya gabungkan dengan bata lain untuk membina sistem yang lebih besar. Di dalam API ini, mungkin terdapat banyak perkara (jenis, fungsi, dll.) yang bekerjasama untuk menjadikannya berfungsi mengikut keperluan.
Sebagai contoh, jika anda menggunakan Go untuk membangunkan sistem perbankan, anda harus mempunyai pakej "akaun". Ia akan menyediakan API yang tidak membocorkan butiran pelaksanaan dan mudah untuk disepadukan.

Jika unit anda mematuhi sifat ini, anda boleh menulis ujian unit terhadap API awam mereka. Secara takrifan ujian ini hanya boleh menguji kefungsian yang berguna. Dengan unit ini disediakan, kami bebas untuk memfaktorkan semula apabila perlu, dan ujian tidak akan menghalang kami dalam kebanyakan kes.

Adakah ujian unit ini

Ya. Ujian unit adalah untuk apa yang saya nyatakan sebagai "unit". Mereka tidak pernah hanya menyasarkan satu kelas/fungsi/apa sahaja.

Menggabungkan konsep ini

Kami telah pun membincangkan

• Pemfaktoran Semula

• Ujian unit

• Reka bentuk unit

Apa yang dapat kita lihat ialah aspek reka bentuk perisian ini saling melengkapi antara satu sama lain.

Pemfaktoran semula

• menyediakan isyarat untuk ujian unit kami. Jika kita perlu menyemak secara manual, maka kita memerlukan lebih banyak ujian. Jika ujian gagal, maka ujian kami berada pada tahap abstraksi yang salah (atau tidak mempunyai nilai dan harus dialih keluar)

• membantu kami menangani kerumitan dalam dan antara unit.

Ujian unit

• menyediakan perlindungan keselamatan untuk pemfaktoran semula.

• Sahkan dan dokumenkan kefungsian unit kami.

Unit (Reka bentuk yang baik)

• Ujian unit bermakna yang mudah ditulis.

• Mudah difaktorkan semula.

Adakah terdapat proses yang membantu kami terus memfaktorkan semula kod kami untuk mengurus kerumitan dan memastikan sistem berskala?

Mengapa Pembangunan pandu uji (TDD)

Sesetengah orang mungkin terlalu mereka bentuk dan membuang banyak masa mencuba untuk mencipta sistem berskala "sempurna" terlebih dahulu kerana idea Lehman tentang cara membuat perisian sentiasa berubah, Tetapi tiada apa yang dicapai .

Pada zaman dahulu perisian yang buruk, satu pasukan penganalisis akan menghabiskan 6 bulan menulis dokumen keperluan, satu pasukan arkitek akan menghabiskan 6 bulan mereka bentuk, dan beberapa tahun kemudian keseluruhan projek akan gagal.

Saya katakan zaman dahulu adalah buruk, tetapi masih begitu

Pembangunan tangkas mengajar kita bahawa kita perlu bekerja secara berulang, bermula dari kecil dan terus menambah baik perisian supaya kita boleh mendapatkan maklum balas dengan cepat mengenai reka bentuk perisian dan cara ia berfungsi dengan pengguna sebenar TDD menguatkuasakan pendekatan ini.

TDD menangani undang-undang yang dibincangkan oleh Lehman dan pelajaran sejarah lain yang sukar dipelajari dengan menggalakkan pendekatan pembangunan pemfaktoran semula dan penyampaian berulang yang berterusan.

Langkah kecil

• Tulis ujian kecil untuk fungsi kecil

• Periksa sama ada ujian gagal, dan mempunyai ralat yang jelas (merah)

• Tulis kod minimum untuk membuat ujian lulus (hijau)

• Refactor

• Ulang langkah di atas

Apabila anda menjadi lebih mahir, ini akan menjadi cara semula jadi untuk bekerja untuk anda, dan kecekapan kerja anda juga akan meningkat dan lebih tinggi

Anda mula berharap bahawa unit ujian kecil anda tidak mengambil masa terlalu lama untuk melengkapkan keseluruhan ujian, kerana jika anda melihat program anda sentiasa dalam keadaan bukan "hijau", itu bermakna anda mungkin mengalami sedikit masalah.

Dengan maklum balas ujian ini, anda boleh memastikan kestabilan beberapa fungsi aplikasi kecil dengan mudah.

Pengakhiran yang memuaskan

• Kelebihan perisian ini ialah saya boleh mengubahnya mengikut keperluan. Dari masa ke masa, disebabkan beberapa sebab yang tidak dapat diramalkan, kebanyakan perisian perlu membuat perubahan yang sepadan mengikut keperluan tetapi jangan terlalu banyak bekerja dan terlalu reka bentuk pada mulanya, kerana masa depan terlalu sukar untuk diramalkan.

• Jadi untuk memenuhi keperluan di atas, kami perlu memastikan perisian kami berskala. Jika tidak, keadaan akan menjadi sangat teruk apabila perisian kami perlu difaktorkan semula dan dinaik taraf.

• Ujian unit yang baik boleh membantu anda memfaktorkan semula projek anda dengan cepat dan gembira.

• Menulis ujian unit yang baik ialah masalah reka bentuk Anda mesti berfikir dengan teliti untuk menyusun kod anda supaya setiap ujian unit anda sama menariknya dengan menyusun blok Lego , berjaya menyelesaikan ujian daripada keseluruhan projek.

• Pembangunan Dipacu Ujian (Pembangunan Dipacu Ujian TDD) boleh membantu dan menggesa anda untuk membangunkan perisian yang direka dengan baik secara berulang Menggunakannya sebagai sokongan teknikal akan memberi impak yang besar pada masa depan anda kerja.

Alamat asal: https://quii.gitbook.io/learn-go-with-tests/meta/why

Alamat terjemahan: https: //learnku.com/go/t/34095

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Video Pengaturcaraan! !

Atas ialah kandungan terperinci Mengapa ujian unit? Bagaimana untuk menjalankan ujian?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!