Ya, Anda tidak salah dengar - itu benar! Dalam komunitas TI, pendapat berakar kuat bahwa semua tes ini membantu Anda, tetapi benarkah demikian? Sudahkah Anda mencoba berpikir kritis dan menganalisis sendiri kearifan konvensional ini? Hipsters datang dengan banyak paradigma - TDD, BDD, SDA, polisi lalu lintas - hanya untuk menciptakan ilusi aktivitas yang sibuk dan entah bagaimana membenarkan gaji mereka. Tetapi pikirkan tentang apa yang akan terjadi jika Anda (atau programmer Anda) mulai mencurahkan seluruh waktu Anda secara eksklusif untuk menulis kode? Ada area terpisah untuk pengujian dan seluruh divisi. Anda tidak memaksa programmer untuk menulis persyaratan, bukan? Lalu mengapa mereka harus menulis tes? Semua yang setuju dan tidak setuju, saya meminta Anda untuk melanjutkan ke dalam posting, di mana saya akan dengan jelas menunjukkan kepada Anda bahwa tes unit (dan integrasi) adalah kejahatan besar!
Dari mana asal pengujian?
Di zaman kuno, tidak ada pengujian sama sekali. Bahkan tidak ada arahan seperti itu, apalagi istilah-istilah seperti blok (unit) dan pengujian integrasi. Dan tentang segala macam e2e dan, Tuhan maafkan saya, saluran pipa, saya biasanya diam. Dan semua ini karena, pada kenyataannya, belum ada yang bisa diuji. Pada tahun-tahun itu, insinyur perangkat lunak hanya mencoba membuat komputer pertama.
Seperti yang kita semua tahu, komputer pertama berukuran raksasa, beratnya puluhan ton, dan harganya lebih mahal daripada Apple MacBook Pro Retina 4k 32Gb RAM 1Tb SSD Touch Bar USB Type-C. Dan pada masa itu, pengembang sangat takut jika terjadi kesalahan selama bekerja. Saya pikir Anda tahu sejarah asal mula istilah "bug" - jika tiba-tiba tidak, maka bacalah , itu sangat menarik. Dan, karena programmer takut dengan segala sesuatu di dunia, mereka membuat pengujian unit.
Waktu telah berubah, komputer juga berubah. Pengujian juga berubah. Selain unit test, muncul juga area yang kemudian dikenal dengan Quality Assurance.
Tetapi para pengembang juga berubah. Saat ini, menjadi konyol untuk berpikir bahwa seseorang takut meluncurkan program, karena ini dapat membuat server terbakar. Di tahun 2020, programmer tidak takut untuk meluncurkan programnya. Dan jika tidak ada rasa takut, mengapa diuji?
Realitas modern
Saya ulangi pertanyaan saya - jika MacBook Anda (atau Xiaomi) tidak meledak karena bug dalam kode, mengapa harus menguji? Anda tinggal meluncurkan dan menikmati hasilnya. Mengantisipasi kemarahan Anda atas kesalahan yang mahal bagi pelanggan - biarkan orang yang terlatih khusus melakukan pengujian.
. , . - . . -, Quality Assurance โ , ยฏ\_(ใ)_/ยฏ
, Software Development, Unmistakable Development. .
-, : ยซ, , ยป. ? ?
. โ . . , , , ?
: ยซ ยป - .
, master, , . pull request , โ . , , .
:
, .
, . , , , , . , -, .
.
โ . โ . ? .
, . , . , . , .
, , . , QA , . , โ , .
โ . .
Unit-testing, Integration Testing, End 2 End, Pipelines, CI, CD โ , ? , , .
. , , e2e , . โ .
- CI CD โ . devops, . - , - , โ .
. , โ . โ . โ bash. โฆ , .
Delivery In Time
: DIT โ Delivery In Time. ( ****), . . , , . DIT , โ , . , . , : โ , โ , . , , .
DIT . , ( ), . . , , Quality Assurance . .
:
โ ?
โ .
โ .
โ โฆ , 1000 .
. , .
, DIT , , . , . - (, , , ), .
: โ , . - , , , . .
, . .
- , (, , ) . , , - . , ? , , .
. , . , โ . , , , .
. , , . , ? , , , ? , . , - . โ .
. (, 2 ) โ . , , . , , . . .
, ? . . , .
. . โ , โ . - , . , . .
!
, , :)
, . , . , . , , 15%. . , .
? / 80%? - 30? โ , ?
, . , , :)
Dan, mengambil kesempatan ini: jika Anda menyukai format ini, maka saya mengundang Anda ke blog saya dari pengembang yang buruk (sering berbohong) VK publik , di mana saya memposting dari waktu ke waktu seperti posting sarkastik, yang seringkali tidak nyaman untuk diposting di sini.