Pembangunan API dipacu ujian dalam Go-Golang-php.cn

Test-driven API Development in Go

pengenalan

Pembangunan dipacu ujian ialah kaedah yang berkesan untuk memastikan kod yang diuji dengan baik dan boleh difaktorkan semula. Idea asas ialah anda memulakan pembangunan dengan menulis ujian. Ujian ini dengan jelas mendokumenkan jangkaan dan mencipta rubrik untuk pelaksanaan yang berjaya. Apabila dilakukan dengan betul, anda boleh mentakrifkan dengan jelas input/output yang diharapkan bagi sesuatu fungsi sebelum menulis sebarang kod. Ini mempunyai beberapa faedah segera:

Anda mempertimbangkan dengan teliti antara muka untuk berinteraksi dengan kod anda dan mereka bentuknya supaya boleh diuji
Apabila anda mula menulis kod, aliran anda tidak terganggu oleh ujian manual atau melangkah melalui logik pelaksanaan untuk meramalkan hasilnya. Sebaliknya, anda hanya menjalankan ujian
Membuat lulus ujian menjadi matlamat yang memuaskan untuk dicapai. Memecahkan proses kepada satu siri pencapaian yang jelas dan boleh dicapai menjadikan kerja lebih menyeronokkan
Elakkan kemalasan selepas pelaksanaan dan terlalu yakin yang boleh menghalang anda daripada menguji kod anda

Sekarang anda yakin dengan faedahnya, anda boleh bermula dengan pembangunan dipacu ujian (TDD) dengan mengikuti langkah berikut:

Tulis atau ubah suai ujian
Semak jika ujian gagal
Tulis jumlah minimum kod untuk membuat ujian lulus

Langkah-langkah ini diikuti dalam kitaran supaya anda sentiasa menambah lebih banyak ujian untuk mencabar pelaksanaan semasa.

Langkah terakhir, yang menentukan menulis jumlah minimum kod, ialah perkara yang boleh menjadi membosankan jika diikuti dengan tegar. Adalah penting untuk memahami sebab peraturan ini wujud sebelum anda boleh menentukan masa yang sesuai untuk menyimpang daripada peraturan ini.

Contoh Mudah

Anda ditugaskan untuk melaksanakan fungsi Add(x, y int) int. Sebelum anda melompat ke pelaksanaan dan hanya kembalikan x + y, tulis ujian paling mudah: 1 + 1 == 2. Kemudian, apakah pelaksanaan paling mudah yang akan lulus ujian? Ia baru kembali 2. Kini ujian anda lulus!

Pada ketika ini, anda menyedari bahawa anda memerlukan lebih banyak ujian, jadi anda meningkatkan rentak dan menambah beberapa lagi:

1 + 2 == 3
100 + 5 == 105

Kini ujian anda gagal, jadi anda perlu membetulkan pelaksanaannya. Anda tidak boleh hanya mengembalikan 3 atau mengembalikan 105 kali ini, jadi anda perlu mencari penyelesaian yang berfungsi untuk semua ujian. Ini membawa kepada pelaksanaan: pulangkan x + y.

Walaupun ini terasa terlalu membosankan dalam contoh remeh, pematuhan ketat kepada kaedah ini menyebabkan anda menulis berbilang ujian dan bukannya hanya mempercayai pelaksanaan anda. Sudah tentu, idea awal anda untuk mengembalikan x + y akan berjaya, tetapi perkara utama adalah untuk melatih semula diri anda untuk bergantung pada ujian dan bukannya pemahaman anda sendiri tentang kod tersebut. Di dunia nyata, anda bukan seorang sahaja yang bekerja pada sekeping kod ini dan pasti akan melupakan butiran pelaksanaan. Proses ini memaksa anda menulis lebih banyak ujian dan memikirkan lebih banyak cara untuk memecahkan pelaksanaan mudah.

Akhirnya, anda akan mendapat pengalaman dan belajar untuk mencari keseimbangan yang berfungsi dalam senario berbeza yang anda hadapi. Anda akan kembali kepada pelaksanaan ciri berkelajuan penuh dan mendapati bahawa anda mempunyai lebih sedikit pepijat dan menulis lebih banyak kod yang boleh diselenggara.

Langkah demi langkah TDD untuk API HTTP

Mari kita masuk ke contoh yang lebih rumit menggunakan TDD untuk HTTP REST API. Panduan langkah demi langkah ini menggunakan rangka kerja Go saya, babyapi, tetapi konsepnya boleh digunakan di mana-mana sahaja.

babyapi menggunakan generik untuk mencipta API CRUD penuh di sekeliling struktur Go, menjadikannya sangat mudah untuk mencipta API REST penuh dan CLI pelanggan. Selain itu, pakej babytest menyediakan beberapa alatan untuk membuat ujian jadual API hujung ke hujung. Menggunakan TDD pada peringkat API membolehkan anda menguji sepenuhnya HTTP dan lapisan storan API atau ciri baharu sekaligus.

Penafian: Memandangkan babyapi mengendalikan kebanyakan pelaksanaan dan juga digunakan untuk menjana plat dandang ujian, kami secara teknikal tidak bermula dengan TDD. Walau bagaimanapun, kami akan melihat betapa berfaedahnya apabila menambahkan sokongan untuk permintaan PATCH pada API kami.

Buat projek Go baharu
Buat main.go awal menggunakan contoh mudah babyapi
Gunakan CLI untuk menjana plat dandang ujian
Laksanakan setiap ujian dengan mengisi ruang letak dengan JSON yang dijangkakan
Jalankan ujian dan pastikan mereka lulus!

Memandangkan PUT adalah idempoten, ia memerlukan semua medan disertakan. Untuk mengelakkan perkara ini, kami ingin menambah sokongan untuk menogol permintaan Completed with PATCH. Kami mulakan dengan menambah ujian mudah untuk rupa yang kami jangkakan ciri ini
This test fails since babyapi doesn't support PATCH by default. We can fix it by implementing Patch for the TODO struct. Since we defined our feature with two tests, our simplest implementation isn't just setting Completed = true and we have to use the value from the request
Now we can change the Completed status of a TODO, but we still cannot use PATCH to modify other fields as show by this new set of tests
Update Patch to set the remaining fields
Our tests still fail since we always update the TODO with the request fields, even if they're empty. Fix this by updating the implementation to check for empty values
The new UpdateWithPatch test passes, but our previous tests fail. Since we changed Completed to be *bool, TODOs created with an empty value will show as null
Implement Render for TODO so we can treat nil as false

Implementing the PATCH feature with test-driven development resulted in a robust set of tests and a well-implemented feature. Since we started by defining the expected input and output of a PATCH request in tests, it was easy to see the issues caused by not checking for empty values in the request. Also, our pre-existing tests were able to protect from breaking changes when changing the type of Completed to *bool.

Conclusion

Test-driven development is an effective approach for creating fully tested and correct code. By starting with tests in mind, we can ensure that every piece of code is designed to be testable instead of letting tests be an afterthought.

If you're hesitant about adopting TDD, here are a few ideas to get started:

Try it in simple scenarios where a function's input/output is clear and the implementation is not overly complicated. You can write a robust table test for the variety of input/output that could be encountered. Having a clear visual of the different scenarios can simplify implementation
If you're fixing a new bug, you have already identified a gap in your testing. Start by writing a test that would have identified this bug in the first place. Then, make this test pass without breaking any existing tests.
Similar to the babyapi example, you can use TDD for high-level API tests. Once you have a definition of the expected request/response, you can resume your usual development flow for more detail-oriented parts of the implementation

Even if TDD isn't a good fit for the way you write code, it's still a powerful tool to have in your belt. I encourage you to at least commit some time to trying it out and see how it affects your development process.

Atas ialah kandungan terperinci Pembangunan API dipacu ujian dalam Go. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!