TDD dalam PPL? Jadi apa yo….

Dear all my friend…. May peace be upon you.

Apakah anda menggunakan Framework dalam project anda?

Selamat… anda sekarang bagian dari development software berbasis TDD. Singkat kata, seluruh Framework pasti terdapat modules yang dapat digunakan untuk testing project. Jika tidak ada, maka itu disebut Library.

Apa sih TDD?

TDD (Test-Driven Development) merupakan software development progress yang memiliki cycle dengan waktu kecil, dalam membangun software berbasis test case yang telah dibuat.

Source: https://en.wikipedia.org/wiki/Test-driven_development

1. Untuk membangun sebuah test case, perlu memahami alur kerja framework anda. Jika anda menggunakan google cukup ketik: TDD spasi <nama framework> kirim ke “i feel lucky”
2. Bangun sebuah program kosong dengan test case yang siap untuk dicoba, expect not pass tetapi yang terpenting, pastikan no compile error. (tahap environment construction)
3. Mulai deh penuhi code agar pass test case (cukup membangun function kosong / return agar memenuhi test-case)
4. Setelah pass, mulai Refactor (ngoding serius, isi function dengan real code)
5. re-test, correct regression, pastikan pass test.
6. Mulai lagi iterasi baru dengan membangun test case baru. (loop to step-2 or perhaps 1 if compile error)

Banyak diluar sana yang dapat menjelaskan TDD dengan lebih akurat dan benar. kali ini mari membahas TDD di PPL terutama project sulang. Intinya, metode TDD terbukti ampuh dalam membangun software yang robust (kuat) dalam konteks software, adalah software yang tahan terhadap run error (karena functional programming, bila ada error, dapat di-handle).

Let’s talk about Git at PPL 2018.

Bagan Git Flow untuk PPL 2018

Untuk membangun Git flow sesuai dengan gambar tersebut, di propose struktur git dalam project sebagai berikut:

- Master (commit)
- hotfix/ (folder)
-- <number versioning>(commit)
- sit_uat (commit)
- coldfix (commit)
// NOTE: format coldfix dapat disamakan dengan hotfix jika
// diperlukan versioning
// For each Story
- story_<UserStory-name> (commit)
- task_<UserStory-name>/ (folder)
// For each Task
-- <task-name> (commit)

Struktur git flow ini memudahkan untuk developer untuk memastikan bahwa setiap branch tidak ada terdapat conflict git push (dimana 1 brach dikerjakan oleh >1 orang). Setiap task yang selesai harus dimerge ke story terlebih dahulu, bila story dikerjakan lebih dari 1 orang, perlu adanya merge request agar dapat di trace oleh kelompok. Selebihnya, git flow sesuai dengan bagan.

Dikarenakan pada bagan git flow tidak terdapat UserTask, maka commit yang masuk dalam kategori task tidak wajib dalam pemberian tag [RED / GREEN] tidak wajib untuk dilakukan test CI / pipeline.

Maka dapat diberikan pada file .gitlab-ci.yml

job:
  only:
    message:
      - /\[RED]/
      - /\[GREEN]/

Dimana setiap commit-an dengan tag [RED] / [GREEN] akan di-test otomatis oleh gitlab kecuali commit-an tanpa pemberian tag, yaitu UserTask yang tidak di-dedikasi-kan untuk test.

Perlu diingat bahwa pipeline memiliki resource yang terbatas (terutama dalam project ini menggunakan docker) dan membutuhkan waktuyang cukup lama >5 menit, sehingga dedikasi filterisasi berdasarkan pemberian tag untuk commitan sangat membantu kerja flow dari pipeline agar effisien dalam men-test program.

Here, some coffee break.

Selamat membangun software yang 100 % murni robust. (biar kuat ngoding gak tidur-tidur). Salam.