BAB 7 Coding dan Pengujuan unit

Nama : santi

Npm   : 43a87007150347

kelas   : S1/SI/3B/P

BAB 7

Coding dan Pengujian Unit

Tujuan dari coding atau pemrograman kegiatan adalah untuk menerapkan desain dengan cara terbaik mungkin. Aktivitas coding sebuah mengenai baik pengujian dan main-tenance mendalam. Seperti yang kita lihat sebelumnya, waktu yang dihabiskan di coding adalah sebagian kecil dari total biaya perangkat lunak, sementara pengujian dan pemeliharaan mengkonsumsi porsi besar. Dengan demikian, itu harus jelas bahwa tujuan selama coding tidak harus hanya untuk mengurangi biaya pelaksanaan, tetapi membantu mengurangi biaya tahap selanjutnya. Selama coding, harus diingat bahwa program tidak harus dibangun sehingga mereka mudah untuk menulis, tetapi dengan cara yang mereka mudah untuk membaca dan memahami. Sebuah program yang banyak membaca lebih sering dan lebih banyak orang selama fase kemudian. Memiliki pembacaan dan dimengerti sebagai tujuan yang jelas dari aktivitas cod-ing sendiri dapat membantu dalam mencapai itu.

Dalam bab ini kita akan membahas:

- Beberapa prisip seperti pemrograman terstruktur, informasi bersembunyi, penggunaan standar cod-ing, yang dapat membantu mengembangkan program lebih mudah dibaca.

- Beberapa proses programmer tingkat seperti pengembangan tambahan dan pengembangan uji-didorong, untuk effisien mengembangkan kode berkualitas tinggi.

- Bagaimana mengelola berkembang kode dengan menggunakan kontrol kode sumber yang tepat dan refac-toring.

- Bagaimana unit modul tes menggunakan kerangka pengujian unit.

- Sebuah proses pemeriksaan kode terstruktur yang dapat digunakan untuk meningkatkan kualitas kode.

7.1 Pemrograman Prinsip dan Pedoman

Tugas utama sebelum programmer untuk menulis kode yang dapat dibaca dengan beberapa bug di dalamnya. Sebuah gol tambahan adalah untuk menulis kode cepat. Menulis kode padat adalah keterampilan yang hanya dapat diperoleh dengan praktek. Namun, berdasarkan pengalaman, beberapa aturan umum dan pedoman dapat diberikan untuk programmer. pemrograman yang baik (memproduksi program yang benar dan sederhana) adalah independen praktek bahasa pemrograman sasaran, meskipun bahasa pemrograman yang terstruktur dengan baik membuat pekerjaan programmer sederhana. Pada bagian ini, kita akan membahas beberapa konsep dan praktik yang dapat membantu programmer menulis kode berkualitas tinggi yang juga mudah untuk dipahami.

7.1.1 Pemrograman Terstruktur

Seperti yang dinyatakan sebelumnya tujuan dasar dari kegiatan coding adalah untuk menghasilkan pro-gram yang mudah dimengerti. Telah dikemukakan oleh banyak bahwa praktek pemrograman terstruktur membantu mengembangkan program yang lebih mudah untuk dipahami. Gerakan pemrograman terstruktur dimulai pada tahun 1970-an, dan banyak yang telah dikatakan dan ditulis tentang hal itu. Sekarang konsep meresapi begitu banyak bahwa itu diterima-bahkan biasanya tersirat-yang pemrograman harus terstruktur. Meskipun banyak penekanan telah ditempatkan pada pemrograman terstruktur, yang con-kecuali bahwa dan motivasi di balik pemrograman terstruktur sering tidak baik di bawah-berdiri. pemrograman terstruktur sering dianggap sebagai "goto-kurang" pemrograman.

Sebuah program memiliki struktur statis serta struktur yang dinamis. Struktur statis adalah struktur teks dari program, yang hanya orga-nization linear laporan program. Struktur dinamis dari program ini adalah urutan pernyataan dijalankan selama pelaksanaan program. Dengan kata lain, baik struktur statis dan perilaku dinamis adalah urutan laporan; sedangkan urutan mewakili struktur statis dari sebuah program adalah tetap, urutan laporan dijalankan dapat berubah dari eksekusi eksekusi.

Seperti membaca program adalah kegiatan jauh lebih umum daripada menulis program, tujuan dari kegiatan coding adalah untuk menghasilkan program yang, selain bebas dari cacat, mudah untuk memahami dan memodifikasi.

Motivasi nyata untuk pemrograman terstruktur, bagaimanapun, adalah resmi pembuktian program. Untuk menunjukkan bahwa program benar, kita perlu menunjukkan bahwa ketika program dijalankan, perilakunya adalah apa yang diharapkan. Untuk menentukan perilaku, kita perlu menentukan kondisi output dari program harus memenuhi

Menggunakan notasi Hoare ini untuk memverifikasi program, pernyataan dasar tentang segmen program ini dalam bentuk

         P {S}Q.

Penafsiran ini adalah bahwa jika pernyataan P benar sebelum mengeksekusi S, maka pernyataan Q akan menjadi kenyataan setelah melaksanakan S, jika eksekusi S berakhir. Sikap tegas P adalah pra-kondisi program dan Q adalah pasca-kondisi. pernyataan ini adalah tentang nilai-nilai yang diambil oleh variabel dalam program sebelum dan setelah pelaksanaannya. Pernyataan umumnya tidak menentukan nilai nominal-TERTENTU untuk variabel, tetapi mereka menentukan sifat umum dari nilai-nilai dan hubungan di antara mereka.

7.1 Prinsip Pemrograman dan Pedoman 185

memanfaatkan konstruksi terstruktur. Dalam pemrograman terstruktur, pernyataan ini bukan pernyataan tugas sederhana, itu adalah pernyataan terstruktur. Properti kunci dari pernyataan terstruktur adalah bahwa ia memiliki single-entry dan satu-keluar. Artinya, selama eksekusi, eksekusi (terstruktur) pernyataan dimulai dari satu titik didefinisikan dan eksekusi berakhir pada satu titik didefinisikan. Dengan pernyataan single-entry dan single-keluar, kita dapat melihat program sebagai urutan laporan (terstruktur). Dan jika semua pernyataan adalah pernyataan terstruktur, maka selama eksekusi, urutan eksekusi pernyataan ini akan sama dengan urutan dalam teks program. Oleh karena itu, dengan menggunakan laporan single-entry dan single-keluar, korespondensi antara struktur statis dan dinamis dapat diperoleh.

Gunakan pemrograman terstruktur di mana program ini adalah urutan yang sesuai single-entry konstruksi single-exit membuat program yang mudah untuk memahami dan memverifikasi. praktek-praktek lainnya seperti menggunakan menyembunyikan informasi, cocok coding stan-dards, dan praktek pemrograman yang baik juga membantu meningkatkan pembacaan kode dan kualitas. Tujuan dasar menggunakan konstruksi terstruktur adalah untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk di bawah-berdiri dan berdebat tentang. Dalam aliran kontrol linier, jika kita memahami perilaku masing-masing konstruksi dasar benar, perilaku program dapat dianggap sebagai komposisi perilaku dari laporan. Untuk pendekatan ini untuk bekerja, itu tersirat bahwa kita dapat dengan jelas memahami dan menentukan perilaku setiap konstruk.

Titik utama adalah bahwa setiap konstruk tidak terstruktur harus digunakan hanya jika alternatif terstruktur lebih sulit untuk memahami. Pandangan ini dapat diambil hanya karena kita berfokus pada pembacaan. Jika tujuannya adalah pemastian formal, pemrograman terstruktur mungkin akan diperlukan.

7.1.2 Informasi Menyembunyikan

Sebuah solusi perangkat lunak untuk masalah selalu berisi struktur data yang dimaksudkan untuk mewakili informasi dalam domain masalah. Artinya, ketika perangkat lunak dikembangkan untuk memecahkan masalah, perangkat lunak menggunakan beberapa struktur data untuk menangkap informasi dalam domain masalah.

Secara umum, hanya operasi tertentu dilakukan pada beberapa informasi. Artinya, sepotong informasi dalam masalah domain hanya digunakan dalam sejumlah cara dalam domain masalah. Sebagai contoh, sebuah buku besar di akuntan memiliki beberapa kegunaan yang sangat jelas: debit, kredit, memeriksa saldo, dll Sebuah operasi di mana semua debet dikalikan bersama-sama dan kemudian dibagi dengan jumlah semua kredit biasanya tidak dilakukan.

Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. Ini, pada dasarnya, adalah prinsip bersembunyi informasi. Informasi yang ditangkap dalam struktur data harus disembunyikan dari sisa dari sistem, dan hanya akses fungsi pada struktur data yang mewakili operasi yang dilakukan pada informasi yang harus terlihat. Dengan kata lain, ketika informasi tersebut ditangkap di struktur data dan kemudian pada struktur data yang mewakili beberapa informasi, untuk setiap operasi pada informasi fungsi akses harus disediakan.

Untuk pengembang, hal ini sangat efektif untuk mengembangkan kode secara bertahap. Hal ini dapat dilakukan dengan menulis kode sedikit demi sedikit, dan pengujian dan debugging setiap kenaikan sebelum menulis kode lebih. Atau, pengembangan uji-driven dapat diikuti di mana uji kasus yang ditulis pertama dan kemudian kode ditulis untuk lulus uji kasus ini. Meskipun coding dari modul umumnya dilakukan oleh programmer individu, alternatif adalah pasangan pemrograman, di mana coding dilakukan oleh sepasang programmer-baik strategi bersama-sama berkembang, struktur data, algoritma dll

7.1.3 Beberapa Praktek Pemrograman

Konsep yang dibahas di atas dapat membantu dalam menulis kode sederhana dan jelas dengan beberapa bug. Ada banyak praktek pemrograman yang juga dapat membantu ke arah tujuan itu. Kita bahas di sini beberapa aturan yang telah ditemukan untuk membuat kode lebih mudah dibaca serta menghindari beberapa kesalahan.

Kontrol Constructs: Seperti telah dibahas sebelumnya, hal ini diinginkan bahwa sebanyak mungkin single-entry, konstruksi single-exit digunakan. Hal ini juga diinginkan untuk menggunakan beberapa konstruksi kontrol standar daripada menggunakan berbagai konstruksi, hanya karena mereka tersedia dalam bahasa.

Gotos: gotos harus digunakan dengan hemat dan secara disiplin. Hanya ketika alternatif untuk menggunakan gotos lebih kompleks harus yang gotos digunakan. Dalam kasus apapun, alternatif harus memikirkan sebelum akhirnya menggunakan goto. Jika goto harus digunakan, transfer ke depan (atau melompat ke pernyataan kemudian) lebih diterima daripada melompat ke belakang.

Informasi Menyembunyikan: Seperti telah dibahas sebelumnya, informasi bersembunyi harus didukung mana mungkin. Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.

Jenis Buatan Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku.

Nesting: Jika bersarang jika-maka-lain konstruksi menjadi terlalu dalam, maka logika menjadi sulit untuk memahami.

Modul Ukuran: Kami membahas masalah ini selama desain sistem. Seorang programmer harus hati-hati memeriksa setiap fungsi dengan terlalu banyak laporan (mengatakan lebih dari 100). modul besar sering tidak akan fungsional kohesif. Tidak ada aturan keras-dan-cepat tentang ukuran modul; prinsip harus kohesi dan kopling.

Modul Interface: Sebuah modul dengan antarmuka yang kompleks harus diteliti dengan seksama. Sebagai aturan praktis, setiap modul yang antarmuka memiliki lebih dari lima parameter harus diteliti dengan seksama dan patah menjadi beberapa modul dengan antarmuka sederhana jika mungkin.

Kode Berkembang perlu dikelola dengan baik. Hal ini dapat dilakukan melalui kontrol alat kode sumber yang tepat yang memungkinkan manajemen mudah dari versi berbeda yang bisa dibuat, serta mudah kehancuran perubahan yang perlu digulung kembali.

7.1.4 Standar Coding

Programmer menghabiskan jauh lebih banyak waktu membaca kode daripada menulis kode. Selama kehidupan kode, penulis menghabiskan waktu yang cukup membacanya selama debugging dan peningkatan. Orang lain selain penulis juga menghabiskan cukup e ff ort dalam membaca kode karena kode ini sering dipelihara oleh orang lain selain penulis. Singkatnya, itu adalah sangat penting untuk menulis kode dengan cara yang mudah dibaca dan dimengerti. Coding standar memberikan aturan dan pedoman untuk beberapa aspek pemrograman untuk membuat kode lebih mudah dibaca. Sebagian besar organisasi yang mengembangkan perangkat lunak secara teratur mengembangkan standar mereka sendiri.

File Ada konvensi tentang bagaimana file harus dinamai, dan apa file harus berisi, sehingga pembaca bisa mendapatkan beberapa ide tentang apa file con-tains. Beberapa contoh konvensi ini adalah:

- File sumber Java harus memiliki ekstensi .java-ini diberlakukan oleh sebagian besar kompiler dan alat.

- Setiap file harus berisi satu kelas luar dan nama kelas harus sama dengan nama file.

- Panjang garis harus dibatasi kurang dari 80 kolom dan khusus charac-ters harus dihindari. Jika garis lebih panjang, hal itu harus dilanjutkan dan kelanjutan harus dibuat sangat jelas

Laporan Pedoman ini adalah untuk deklarasi dan dieksekusi negara-KASIH dalam kode sumber. Beberapa contoh diberikan di bawah. Namun, perlu diketahui bahwa tidak semua orang akan setuju pada ini. Itulah sebabnya organisasi umumnya mengembangkan pedoman mereka sendiri yang dapat diikuti tanpa membatasi fleksibilitas programmer untuk jenis pekerjaan organisasi tidak.

- Variabel harus diinisialisasi di mana dinyatakan, dan mereka harus dinyatakan dalam lingkup terkecil yang mungkin.

- Menyatakan variabel yang terkait bersama-sama dalam sebuah pernyataan umum. Tidak terkait vari-ables tidak harus dinyatakan dalam laporan yang sama.

- Variabel Kelas tidak harus dinyatakan publik.

- Gunakan hanya pernyataan kontrol loop dalam untuk loop.

- Variabel loop harus diinisialisasi segera sebelum loop.

- Hindari penggunaan istirahat dan terus dalam satu lingkaran.

- Hindari penggunaan do ... sementara membangun.

- Hindari kondisional kompleks ekspresi memperkenalkan sementara boolean variabel-variabel-bukan.

- Hindari pernyataan dieksekusi dalam conditional.

  Java menyediakan komentar dokumentasi yang dibatasi oleh "/ ** ... * /", dan yang bisa diambil ke file HTML. Komentar ini sebagian besar digunakan sebagai prolog untuk kelas dan metode-metode dan bidang, dan dimaksudkan untuk menyediakan dokumentasi untuk pengguna kelas yang mungkin tidak memiliki akses ke kode sumber. Selain prolog untuk modul, standar pengkodean dapat menentukan bagaimana dan di mana komentar harus berada. Beberapa pedoman tersebut adalah:

- Satu baris komentar untuk blok kode harus sejajar dengan kode mereka dimaksudkan untuk.

- Harus ada komentar untuk semua variabel utama menjelaskan apa yang mereka rep-membenci.

- Sebuah blok komentar harus didahului oleh kosong baris komentar hanya dengan "/ *" dan diakhiri dengan baris yang berisi hanya "* /".

- Trailing komentar setelah laporan harus singkat, pada baris yang sama, dan bergeser cukup jauh untuk memisahkan mereka dari laporan.

pedoman tata letak fokus pada bagaimana program harus menjorok, bagaimana harus menggunakan baris kosong, ruang putih, dll, untuk membuatnya lebih mudah dibaca. pedoman lekukan kadang-kadang disediakan untuk setiap jenis pemrograman membangun. Namun, kebanyakan programmer belajar ini dengan melihat kode dari orang lain dan fragmen kode dalam buku-buku dan dokumen, dan banyak dari ini telah menjadi cukup standar selama bertahun-tahun.

7.2 bertahap Mengembangkan Kode

Aktivitas coding dimulai ketika beberapa bentuk desain yang telah dilakukan dan spesifikasi dari modul untuk dikembangkan tersedia. Dengan desain, modul ditugaskan untuk pengembang untuk coding. Ketika modul ditugaskan untuk pengembang, mereka menggunakan beberapa proses untuk mengembangkan kode.

7.2.1 Sebuah Incremental Coding Proses

Proses diikuti oleh banyak pengembang untuk menulis kode untuk modul yang saat ini ditetapkan, dan ketika dilakukan, melakukan unit testing di atasnya dan memperbaiki bug yang ditemukan. Maka kode tersebut akan diperiksa dalam repositori proyek untuk membuatnya tersedia untuk orang lain dalam proyek tersebut. (Kami akan menjelaskan proses memeriksa kemudian.)

Sebuah proses yang lebih baik untuk coding, yang sering diikuti oleh berpengalaman pengembang, adalah untuk mengembangkan kode secara bertahap. Artinya, menulis kode untuk im-plementing hanya bagian dari fungsi modul. Kode ini disusun dan diuji dengan beberapa tes cepat untuk memeriksa kode yang telah ditulis sejauh ini. Ketika kode melewati tes ini, pengembang hasil untuk menambah fungsionalitas lebih lanjut untuk kode, yang kemudian diuji lagi.

7.2.2 Uji-Driven Development

   Test-Driven Development (TDD) [8] adalah proses coding yang berbalik pendekatan umum untuk coding. Alih-alih menulis kode dan kemudian mengembangkan kasus uji untuk memeriksa kode, di TDD itu adalah sebaliknya-programmer pertama menulis skrip tes, dan kemudian menulis kode untuk lulus tes. Seluruh proses dilakukan secara bertahap, dengan tes yang ditulis berdasarkan spesifikasi dan kode yang ditulis untuk lulus tes.

   Beberapa poin yang perlu diperhatikan tentang TDD. Pertama, pendekatan mengatakan bahwa Anda menulis kode hanya cukup untuk lulus tes. Dengan mengikuti ini, kode ini selalu sinkron dengan tes. Hal ini tidak selalu terjadi dengan pendekatan kode-pertama, di mana itu semua terlalu umum untuk menulis sepotong panjang kode, tapi kemudian hanya menulis beberapa tes yang hanya mencakup beberapa bagian kode.

Tulisan ini kasus uji sebelum kode ditulis membuat pengembangan penggunaan-driven. Sejak kasus uji harus tertulis pertama dari spesifikasi, bagaimana kode tersebut akan digunakan mendapat perhatian pertama. Ini akan membantu memastikan bahwa interface dari perspektif pengguna kode dan skenario penggunaan kunci. Hal ini dapat membantu mengurangi kesalahan antarmuka.

Dalam TDD, beberapa jenis prioritas untuk pengembangan kode alami hap-pena. Hal ini kemungkinan besar bahwa beberapa tes pertama cenderung fokus pada menggunakan fungsi utama. Umumnya, kasus uji untuk fitur-prioritas yang lebih rendah atau func-tionality akan dikembangkan kemudian.

7.2.3 Pair Programming

Pair programming juga merupakan proses coding yang telah diusulkan sebagai metodologi kunci tech-nique dalam pemrograman ekstrim (XP) [7]. Dalam pemrograman pasangan, kode tidak ditulis oleh programmer individu tetapi oleh sepasang programmer. Artinya, pekerjaan coding ditugaskan untuk tidak individu tetapi untuk sepasang individu. Pasangan ini bersama-sama menulis kode.

Proses dipertimbangkan adalah bahwa satu orang akan ketik program sementara yang lain akan secara aktif berpartisipasi dan terus-menerus meninjau apa yang sedang diketik. Ketika kesalahan perhatikan, mereka menunjukkan dan diperbaiki.

7.3 Mengelola Berkembang Kode

Selama proses coding, kode yang ditulis oleh programmer (atau sepasang) berevolusi-mulai dari nol untuk akhirnya memiliki modul teruji. Selama proses ini kode mengalami perubahan. Selain perubahan karena proses pembangunan, perubahan kode juga dibutuhkan karena perubahan spesifikasi modul, yang mungkin terjadi karena perubahan persyaratan.

7.3.1 Source Code Control dan Build

Dalam proyek banyak beberapa orang mengembangkan kode sumber. Setiap programmer membuat file sumber, yang akhirnya digabungkan bersama-sama untuk menciptakan executable. Programmer terus berubah file sumber mereka sebagai kode berevolusi, seperti yang kita lihat dalam proses dibahas di atas, dan sering membuat perubahan dalam file sumber lain juga.

Sebuah sistem kontrol sumber kode yang modern berisi repositori, yang essen-tially struktur direktori dikontrol, yang membuat sejarah revisi penuh dari semua file yang dihasilkan oleh programmer didalam tim proyek. Memperbarui salinan lokal. Perubahan yang dilakukan oleh anggota proyek untuk repositori tidak tercermin dalam salinan lokal yang dibuat sebelum perubahan itu dilakukan.

Dengan sistem kontrol kode sumber, programmer tidak perlu mempertahankan semua versi-kapan saja jika beberapa perubahan perlu dibatalkan, versi yang lebih tua dapat dengan mudah ditemukan.

7.3.2 Refactoring

Kita telah melihat bahwa coding sering melibatkan membuat perubahan ke beberapa kode yang ada. Sebagai kode berubah dengan waktu, untuk memastikan bahwa kualitas kode tidak terus menurunkan karena evolusi, refactoring dapat dilakukan. Selama refactoring ada fungsi baru ditambahkan-satunya perbaikan dilakukan agar desai kode membaik dengan penurunan kopling, peningkatan kohesi, dan lebih baik menggunakan hirarki.

Refactoring adalah teknik untuk meningkatkan kode yang ada dan mencegah kerusakan desain ini dengan waktu. Refactoring adalah bagian dari coding di bahwa itu dilakukan selama masa coding, tetapi tidak coding biasa. Refactoring telah dipraktekkan

7.3 Mengelola Berkembang Kode 201

di masa lalu oleh programmer, tetapi baru-baru ini telah mengambil bentuk yang lebih konkrit, dan telah diusulkan sebagai langkah kunci dalam praktek XP [7]. Refactoring juga memainkan peran penting dalam test-driven development-kode perbaikan langkah dalam proses TDD benar-benar melakukan refactoring.

Tujuan dasar dari refactoring adalah untuk memperbaiki desain. Namun, perlu diketahui bahwa ini bukan tentang meningkatkan desain selama tahap desain untuk menciptakan desain yang akan kemudian dilaksanakan (yang merupakan fokus dari desain metode-ologies), tetapi tentang meningkatkan desain kode yang sudah ada.

prinsip-prinsip dasar desain memandu proses refactoring. Akibatnya, refactoring umumnya menghasilkan satu atau lebih hal berikut:

1. Mengurangi kopling

2. kohesi Peningkatan

3. kepatuhan yang lebih baik untuk membuka-menutup prinsip

Refactoring melibatkan perubahan kode untuk meningkatkan salah satu desain yang tepat-ikatan, sambil menjaga perilaku eksternal yang sama. Refactoring sering dipicu oleh beberapa perubahan coding yang harus dilakukan. Risiko utama dari refactoring adalah bahwa ada kode kerja mungkin "istirahat" karena perubahan yang dibuat. Untuk mengurangi risiko ini, dua aturan emas adalah:

1. Refactor dalam langkah-langkah kecil

2. Memiliki tes skrip yang tersedia untuk menguji fungsi yang ada

Jika tes yang baik suite tersedia, maka apakah refactoring mempertahankan fungsi yang ada dapat diperiksa dengan mudah. Dengan refactoring, kode menjadi terus meningkatkan. Artinya, desain, daripada membusuk dengan waktu, berkembang dan membaik dengan waktu.

1. Kode Duplikat. Ini sangat umum. Salah satu alasan untuk ini adalah bahwa beberapa fungsi kecil sedang dijalankan di beberapa tempat (misalnya, usia dari

tanggal lahir dapat dihitung di setiap tempat yang membutuhkan tanggal). Alasan lain yang umum adalah bahwa ketika ada beberapa subclass dari kelas, maka setiap subclass mungkin berakhir melakukan hal yang sama.

2. Metode Long. Jika metode besar, sering menggambarkan situasi di mana ia mencoba untuk melakukan terlalu banyak hal dan karena itu tidak kohesif.

3. Panjang Class. Demikian pula, kelas besar dapat menunjukkan bahwa itu encapsulating beberapa konsep, membuat kelas tidak kohesif.

4. Panjang Parameter Daftar. interface yang kompleks jelas tidak diinginkan-mereka membuat kode lebih sulit untuk mengerti. Seringkali, kompleksitas tidak intrinsik tetapi tanda desain yang tidak tepat.

5. Beralih Laporan. Dalam program berorientasi objek, jika polimorfisme yang tidak digunakan dengan benar, kemungkinan untuk menghasilkan pernyataan switch di mana-mana perilaku adalah untuk menjadi berbeda tergantung pada properti.

6. Generality spekulatif. Beberapa hierarki kelas mungkin ada karena benda-benda di subclass tampaknya berbeda. 

7. Terlalu Banyak Komunikasi Antara Objek. Jika metode dalam satu kelas membuat banyak panggilan ke metode objek lain untuk mencari tahu tentang keadaan, ini adalah tanda kopling kuat. 

8. Pesan Chaining. Salah satu metode panggilan metode lain, yang hanya melewati panggilan ini ke objek lain, dan sebagainya. . rantai ini berpotensi menyebabkan kopling yang tidak perlu.

Pengujian 7.4 Satuan

Setelah programmer telah menulis kode untuk modul, itu harus diverifikasi sebelum digunakan oleh orang lain. Pengujian tetap metode yang paling umum dari verifikasi ini. Pada tingkat programmer pengujian dilakukan untuk memeriksa kode programmer telah mengembangkan (dibandingkan dengan memeriksa seluruh sistem software) disebut unit testing.

Unit pengujian seperti pengujian rutin di mana program dijalankan dengan beberapa kasus uji kecuali bahwa fokusnya adalah pada pengujian program yang lebih kecil atau modul yang biasanya ditugaskan ke salah satu programmer (atau sepasang) untuk coding.

Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.

7.4.1 Pengujian Unit Prosedural

Dalam bab sebelumnya kita telah melihat bahwa ketika menggunakan unit prosedural untuk modul, program dapat dilihat sebagai bagan struktur, di mana node fungsi dan tepi mewakili hubungan panggilan. Dalam unit testing, satu, atau koleksi kecil, modul ini adalah untuk diuji dengan serangkaian uji kasus.

Sebagai perilaku modul tergantung pada nilai parameter serta negara secara keseluruhan sistem yang merupakan bagian (misalnya, negara variabel global), kasus uji untuk modul f () akan melibatkan pengaturan baik keadaan sistem yang perilaku f () tergantung serta nilai parameter.

Pengujian modul f () dengan kasus uji maka akan melibatkan langkah-langkah berikut:

1. Mengatur sistem negara yang diperlukan oleh uji kasus ini.

2. Nilai Set parameter sesuai.

3. Panggil prosedur f () dengan parameter.

4. Bandingkan hasil f dengan hasil yang diharapkan.

5. Menyatakan apakah kasus uji telah berhasil atau gagal.

7.4.2 Pengujian Unit Kelas

Dalam program berorientasi objek, unit yang akan diuji biasanya objek kelas. Pengujian benda dapat didefinisikan sebagai proses latihan rutinitas yang disediakan oleh suatu objek dengan tujuan mengungkap kesalahan dalam pelaksanaan rutinitas atau keadaan objek atau keduanya

   Untuk menguji kelas, programmer perlu menciptakan sebuah objek dari kelas itu, mengambil objek untuk negara tertentu, memanggil metode di atasnya, dan kemudian memeriksa apakah keadaan objek tersebut seperti yang diharapkan. Urutan ini harus dijalankan berkali-kali untuk sebuah metode, dan harus dilakukan untuk semua metode , Di sini kita secara singkat menjelaskan bagaimana Junit dapat digunakan untuk menguji kelas dan memberikan contoh.

Untuk pengujian dari CUT kelas (kelas yang diuji) dengan Junit, tester harus menciptakan kelas lain yang mewarisi dari Junit (misalnya, kelas cuttest meluas Junit). Kerangka Junit harus diimpor oleh kelas ini. kelas ini adalah driver untuk pengujian CUT.

Inspeksi kode adalah teknik lain yang sering diterapkan pada tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui proses manual. inspeksi kode, seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program menjadi sasaran pemeriksaan. Oleh karena itu, kami menganggap itu sebagai bentuk lain dari unit testing. Ini harus menunjukkan bahwa pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen.

Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode dengan menemukan cacat. Beberapa karakteristik kunci dari inspeksi adalah:

- Inspeksi Kode dilakukan oleh programmer dan programmer

- Ini adalah proses yang terstruktur dengan peran yang ditetapkan untuk peserta.

- Fokusnya adalah pada identifikasi cacat, tidak memperbaiki mereka.

-Inspeksi data yang dicatat dan digunakan untuk memantau efektifitas dari proses pemeriksaan.

7.5.1 Perencanaan

Tujuan dari tahap perencanaan adalah untuk mempersiapkan untuk pemeriksaan. Sebuah tim inspeksi terbentuk, yang harus mencakup programmer yang kode untuk ditinjau. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota juga terbentuk. Sebuah moderator ditunjuk.

Penulis kode memastikan bahwa kode siap untuk diperiksa dan bahwa kriteria entri puas. Umumnya kriteria masuk yang digunakan adalah bahwa kode mengkompilasi dengan benar dan alat analisis statis yang tersedia telah diterapkan. moderator memeriksa bahwa kriteria masuk puas dengan kode.

7.5.2 Self-Ulasan

   Pada fase ini, setiap resensi melakukan self-review kode. Selama self-review, resensi melewati seluruh kode dan log semua cacat potensial ia menemukan di log diri persiapan. Seringkali pengulas akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan ringkasan dari diri-review dalam log.

 Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam.

7.5.3 Group Meeting Ulasan

Tujuan dasar dari pertemuan kajian kelompok adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan dalam pertemuan tersebut.

Project	Xxxxxxxx
Bekerja Produk	Kelas AuctionItem
Ukuran Produk	250 LOC of Jawa
Ulasan Tim	P1, P2, P3
Effort (Person-Hours)
Persiapan	Total 3 orang-jam
Pertemuan Kelompok Ulasan	4.5 orang-jam
Total Upaya	7.5 orang-jam
Cacat
Jumlah Cacat Major	3
Jumlah Cacat Minor	8
Total Jumlah Cacat	11
Status Ulasan	Diterima
Rekomendasi berikutnya tahap
Komentar	kualitas kode dapat ditingkatkan

7.6 Metrik

Secara tradisional, bekerja pada metrik telah difokuskan pada produk akhir, yaitu, kode. Dalam arti, semua metrik untuk produk antara persyaratan dan desain pada dasarnya digunakan untuk memastikan bahwa produk akhir memiliki kualitas tinggi dan produktivitas proyek tetap tinggi. Artinya, tujuan dasar dari metrik untuk produk antara adalah untuk memprediksi atau mendapatkan beberapa ide tentang metrik dari produk akhir.

7.6.1 Tindakan Ukuran

Ukuran produk adalah ukuran sederhana, yang dapat mudah untuk menghitung. Alasan utama untuk kepentingan dalam tindakan ukuran adalah bahwa ukuran adalah faktor utama yang ff sebuah proyek-biaya proyek. Ukuran sendiri adalah menggunakan sedikit; itu adalah hubungan ukuran dengan biaya dan kualitas yang membuat ukuran metrik penting. Hal ini juga digunakan untuk mengukur produktivitas selama proyek (misalnya, KLOC per orang-bulan).

 Sejumlah metrik ada untuk kuantitasnya di kualitas kode. Yang paling umum digunakan adalah metrik ukuran, karena mereka digunakan untuk menilai produksi-tivity orang dan sering digunakan dalam estimasi biaya.Untuk ukuran paling umum adalah baris kode (LOC), yang juga digunakan di sebagian besar model biaya. Tujuan dari metrik kompleksitas adalah untuk mengukur kompleksitas perangkat lunak, sebagai com-plexity merupakan faktor penting sebuah produktivitas proyek dan merupakan faktor dalam estimasi biaya. Sejumlah metrik di ff erent ada, yang paling umum adalah kompleksitas cyclomatic, yang didasarkan pada logika internal program dan mendefinisikan kompleksitas sebagai jumlah siklus independen dalam grafik aliran program. Dalam program kita mendefinisikan jumlah terukur berikut:

- N1 adalah jumlah operator yang berbeda

- N2 adalah jumlah operan yang berbeda

- F1, j adalah jumlah kejadian dari j Operator yang paling sering

- F2, j adalah jumlah kemunculan j paling operan sering Kemudian kosakata n dari sebuah program didefinisikan sebagai

n = n1 + n2.

7.6.2 Kompleksitas Metrik

produktivitas, jika diukur hanya dari segi baris kode per satuan waktu, dapat bervariasi banyak tergantung pada kompleksitas sistem yang akan dikembangkan. Jelas, seorang programmer akan menghasilkan jumlah yang lebih rendah dari kode untuk program sistem yang sangat kompleks, dibandingkan dengan program aplikasi sederhana.

Cyclomatic Kompleksitas Berdasarkan kemampuan pikiran manusia dan pengalaman orang, umumnya diakui bahwa kondisi dan pernyataan kontrol menambahkan kompleksitas program. Mengingat dua program dengan ukuran yang sama, program dengan jumlah yang lebih besar dari pernyataan keputusan cenderung lebih kompleks.

218 7. Coding dan Unit Testing

kesederhanaan, seperti pada contoh). Dalam grafik tersebut akan ada jalur dari node masuk ke setiap node dan jalur dari setiap node ke node keluar (dengan asumsi program tidak memiliki anomali seperti kode unreachable). Untuk grafik tersebut, jumlah cyclomatic dapat 0 jika kode adalah urutan linear dari laporan tanpa pernyataan kontrol. Jika kita menarik busur dari node keluar ke node entri, grafik akan sangat terhubung karena ada jalur antara dua node. Jumlah cyclomatic dari grafik untuk program apapun maka akan nol, dan itu diinginkan untuk memiliki kompleksitas nol untuk program yang sederhana tanpa persyaratan apa pun (setelah semua, ada beberapa kompleksitas dalam program seperti itu).

Untuk modul, kompleksitas cyclomatic didefinisikan sebagai jumlah cyclomatic dari grafik tersebut untuk modul.

Ternyata kompleksitas cyclomatic dari modul (atau cyclomatic num-ber grafik nya) adalah sama dengan jumlah maksimum sirkuit bebas linear dalam grafik. Satu set rangkaian linear jika ada sirkuit yang benar-benar terkandung dalam sirkuit lain atau merupakan kombinasi dari sirkuit lainnya.

Jumlah cyclomatic merupakan salah satu ukuran kuantitatif kompleksitas modul. Hal ini dapat diperluas untuk menghitung kompleksitas seluruh program, meskipun itu lebih cocok pada tingkat modul.

Jumlah ini juga dapat digunakan sebagai jumlah jalur yang harus diuji selama pengujian. kompleksitas cyclomatic adalah salah satu kompleksitas mea-langkah-paling banyak digunakan. Percobaan menunjukkan bahwa kompleksitas cyclomatic sangat berkorelasi dengan ukuran modul di LOC (setelah semua, lebih baris kode semakin besar jumlah keputusan).