dikit lagi gw sampe rumah, ntar gw jelasin gimana gw bisa develop app without even running it locally

tapi disclaimer dulu: I am not a senior software engineer (by all means), if this does not work for you, idk tho

another disclaimer: ini bukan kayak grup-grup sebelah (baca: Python dan Java dan PHP) yang kalo ada 1 orang ngomong, ga boleh ada orang lain yang ngomong. lu mau nyelak karena bingung, atau nyelak karena ketemu tweet lucu, bodo amat. ngomong aja. ini grup santai.

Group sebelah ga boleh di selak? Baru tau, dotnet kykny selak2 aja

padahal php grupnya sepi

Wkwkwkwkwkwkwk, insert meme "never be accountable"

insert idk tho

testing came to be a significant part pas gw kerja di ****** (pas itu ceritanya nge rewrite 3 monolith lama pake django ke microservice pake go — yang ujung-ujungnya ada javascript sama dotnet).
signifikan karena gw percaya pada beberapa hal:

1. testing proves that your code is right, kalo ada yang salah ya MUNGKIN bukan salah kita
2. kalo nggak ada test, dan kita udah meninggalkan perusahaan, your code became a legacy product of yours. gw gamau ninggalin legacy kayak gitu. gw gamau hasil kerja gw di rewrite orang lain, gw maunya diterusin.
3. karena microservice, nggak mungkin lu nyalain belasan service lainnya just to test if your service can run properly. gila aja harus spin up semua service di local.

WKWKWKW

dan semua yang pas itu contribute ke backend nya ******, tanya pertanyaan yang sama: "Cara jalaninnya gimana?"
jawabannya: "You don't"

to know if your code is right, is to test them, rigorously (or extensively if anyone doesn't know what rigorously means)

jenis-jenis testing udah pada tau kan ya: ada unit testing, integration testing, load testing, end-to-end testing, dll. banyak

kalo join cult nya golang, biasanya bakal ngomongin 2 school of testing: Detroit and London.
TLDR: London —> bikin mock, Detroit —> deep class/module creation.

but yes, some language are best by just using one of them. misal dotnet emang cocok kalo style testingnya bikin mock (but it's a whole different case with this beast of an om-om @RonnyGunawan).

Kok malah lebih ribet dari unit test yg mocking2 ya?, tear up and tear down itu idempotent ga unit testnya?

tapi kalo golang, emang banyak yang argue kalo style testing lebih cocok kalo nggak di mock, tapi test aja langsung.
misal spawn database beneran, kafka beneran, semua pake docker compose

idempotent, dan ga ribet. it looks "ribet" karena emang belom biasa aja. go ask @dsnoor

but I'd argue that both style of testing really go hand in hand. emang ada beberapa yang harus kita mock, ada beberapa yang harus kita test against managed dependency (alias dependency yang emang kita bisa manage sendiri, within our own control)

btw testing nya gak perlu pilih salah satu kan ?
beberapa bagian mock, beberapa bagian lainnya langsung

yes gw gitu kok

dan nggak ada yang salah atau bener, yang penting ikut aja apa kata Dan Abramov: "Do whatever feels less awkward"

less awkward for you, not for someone else

mantappp

point no. 2 mantep

Kalau library driver ke db atau orm nya cukup fitur untuk ngeset koneksi versi mocked/fake, bagus.

balik lagi kesini bentar. notice Detroit ini deep module creation. artinya kalo mau test service/business layer yang depends on banyak repository layers, artinya repository layernya di create juga. nggak di mock

more about that in detail: https://zone84.tech/architecture/london-and-detroit-schools-of-unit-tests/

busyet, ternyata sebelum groot ada yang lain

nah kalo gw emang gitu, jadi emang susah banget kalo mau jalanin servicenya. but it forces you to create unit test

Ini integration test yg kemarin kan?

nanti pas bikin unit test, keliatan line of code mana aja yang kena coverage. dan keliatan juga line of code mana aja yang POSSIBLE buat kena coverage kalo kita tambah test case

yes

mantap om penjelasannya

dari sini kalo the whole team udah aware sama seberapa pentingnya testing (no matter what kind of test), ya jadi:

1. pengen ngejar coverage setinggi mungkin
2. lebih pede sama kodingannya

soal "apa yang bisa di test", jawaban gw "anything you can think of"

kalo dirasa penting, ya test. kalo dirasa ga penting, ya terserah mau test atau engga

misal penting: repository layer, business layer yang ada validasi kompleks, business layer yang LOC nya banyak
misal ga penting: business layer yang cuma panggil repository layer sebiji abis itu return, presentation layer yang panggil business layer sebiji

kalo nggak penting kayak function gini doang:

enum Education {
  Others,
  SD,
  SMP,
  SMA,
  KuliahS1,
  KuliahS2,
}  
function convertEducationToString(education: Education) string {
  switch (education) {
    case Education.SD:
      return "SD";
    case Education.SMP:
      return "SMP";
    case Education.SMA:
      return "SMA";
    case Education.KuliahS1:
      return "Strata 1";
    case Education.KuliahS2:
      return "Strata 2";
    case Education.Others:
    default:
      return "Lainnya";
  }
}

ini kan function ga penting, dan hasilnya gitu doang. kalo mau di test ya monggo, kalo ga mau ya gapapa.

kalo pas ngerjain test nya bikin happy ngodingnya, ya gapapa, bikin aja

no one's stopping you from doing it or not doing it

butuh copilot banget kalau case nya banyak

itu soal what to test

terus pertanyaan berikutnya biasa gini: karena code kita udah dijamin oke, how do you prove it to the others?

kalo pake copilot udah disuruh nambah
Diploma1
Diploma3
KuliahD1
KuliahD3
KuliahDiploma1
KuliahDiploma3
KuliahDiplomaD1
KuliahDiplomaD3

ya masukin di CI pipeline.
github actions atau gitlab ci sama-sama bisa spawn additional service yang running pake docker. services ini jalan sidecar sama proses kita, jadi kita bisa hit mereka.

ini ayam napa jadi pedes amat

+1 github action, mulai suka, mulai perlu bayar sepertinya.
2000 menit kayanya kurang

ini gitlab ci: https://docs.gitlab.com/ee/ci/yaml/index.html#services
ini github actions: https://docs.github.com/en/actions/using-containerized-services/creating-postgresql-service-containers

bisa self hosted. kantor gw pake github, dan github actionsnya self hosted

kalo pake CI providers lain, bisa juga seharusnya. kayak argocd, jenkins, agola, dll.

ooh, bisa gitu ya. gak kena charge ?

kalo nggak ada opsi buat spawn service external, bisa aja dikasih akses ke docker socket, nanti pas run test nya baru spawn required servicesnya

misal kalo golang pake https://github.com/ory/dockertest

Jadi setiap tear up and down itu instance baru? Supaya bener2 idempotent?, gede pasti setup nya, karena yg diharapin dari unit test kan bisa test tanpa spawn apa2pun

oh nggak instance baru

tear up + down itu bener bener bikin dependency nya jadi clean

hati2 pake GH action. credit card saya hampir jebol gara2 ngga sadar ngebuild pake macos itu costnya pake faktor pengali 10x

kalo database ya tear down nya cuma drop tables

wkwkwk

bener

kalo self hosted ga kena

ubuntu x 1
windows x 2
mac x 10

Biar tim pada "aware sama seberapa pentingnya testing" ada saran?

berasa kena scam

kalo kafka, sebenernya ga perlu tear down juga sih, cukup kirim administrator request aja buat clear topics

create the test, dominate the team

that's the only way

pake CI. kalo test fail mereka ngga bisa lanjutin PR

ini london atau detroit? https://github.com/mashingan/localredis wkwkwk

wkwkw, saya juga baru nyampe ke docs nya itu pas udah pake.
tpi untung masih pake ubuntu

saya ngga pake london londonan atau detroit detroitan. saya pake gaya redmond

For you?, for boss maybe, kecuali kerja sendiri wkwkwk

ini saya anggap london btw

itu cuma glorofied mock library

awalnya cmn sebagai redis-client tapi karena udah implement protocol nya ya udah sekalian bikin server langsung jadi cmn sebagai runnable redis instance aja, wkwk

ini bener-bener jadi prove ke orang lain kalo your code works.
di kantor gw yang sekarang, gw ada bikin API buat ngurusin pembukaan rekening RDN salah satu bank di indonesia. ada 1 orang yang gapernah pegang golang sebelomnya, harus nyentuh repositorynya untuk ngubah beberapa hal, karena dia yang ikut testing UAT buat API ini.
all he did was:

1. install golang sama goland (karena dia punya full jetbrains suite) — biar dapet intellisense nya doang
2. ubah di tempat yang kira-kira butuh
3. git checkout branch baru, push
4. tunggu hasil CI pipeline hijau
   kalo merah, dia baca failing messagenya, dan ubah accordingly

it. really. works.

testing your code and putting it as a CI pipeline, really works

Detroit lebih ribet ya, padahal yg mock bisa auto generate

gw bukan bos kok, gw just another middle-level. gw galak aja sama orang lain, even yang senior2 gw galakin wkwkwkw

tanya aja ke orang yang pernah ketemu gw di ******, seberapa galak gw

detroit cuma ribet di pisahin dependency configuration. setelah itu everything is easy

tapi jujur, ngetest detroit style capek

dunia luar API itu kotor. jadi yang dicek banyak sekali

udah kaya QA engineers walk into a bar

but is it worth it?

saya cuma ngetest alur registrasi, verify sms, verify email, forgot password, role assignment, etc

worth it

kesalahan ini mah wkwkwk

Tpi dri sekian penjelasan. Itu ntar QA nya gmna om? Postman testing doang?

daripada ngetest manual bisa mencret2

woii, lu jangan ngambil kerjaan guaa

it happened

minggu lalu saya bikin test scenario registrasi, cek email, klik link di email ke browser A, klik link email ke browser B, dst dst

QA jadi user beneran

bener-bener testing as if they are the user

bukan di promosikan jadi user ya

kan gw berhenti di unit test dan integration test, something that users won't be able to see

Yes, more effort berrti, sekalipun bisa auto, but still, butuh setup hal2 lain diluar code

ya, buat gw sih effortnya udah "gitu doang"

effort gak jauh beda, tapi saya cenderung prefer yg mock murni karena faktor waktu ngetes nya
setup dan tear down dependency itu makan waktu

Debit card aja, biar aman wkwk

func destroy(ctx context.Context) error {
  queries := []string{"DROP TABLE a", "DROP TABLE b", "DROP TABLE c"}  
  connection, err := db.Conn(ctx)
  if err != nil {}  
  transaction, err := connection.BeginTx(ctx, &sql.TxOptions{})
  if err != nil {}  

  for _, query := range queries {
    _, err = transaction.ExecContext(ctx, query)
  }  
  transaction.Commit()  
  connection.Close()
}

tear down gini doang

do that 500 times

that's where Github Copilot come into play

Bilang aja, "gimana supaya code lu error kalo disenggol2?"

but I've done it without Github Copilot, so what?

"do that" bukan nulis testnya, tapi executenya

biar kibod mechanya kepake

ngetik yg banyak

oh yaudah execute aja

WKWKWKWKWKK

saya pernah jalanin test hampir 3k tests. tanpa begituan aja udah lama bener

Ini dilakuin diakhir test?
Yes.

kalo dotnet, enak. entitiy framework bisa spawn in-memory database

nama functionnya destroy sih

Siapa tau

tapi kalo migrationnya berat, tetep lama

saya pernah wkwkwkwk

100 an migration scripts, with seed

Bikin gaya baru ah, Bandung Style

kalo migration berat, lebih cepet hit database langsung?

tetep cepetan in memory

Bakal makan gede memory ga itu om?

ya proporsional ke available memory

Kalo 100 migration with seed. Terus seed nya ada sejuta ya tekor jga kayaknya :D

sekian motivasi untuk test your apps

belakangan saya ngga pake in memory database. soalnya saya butuh ngetest FK constraints sedangkan sqlite ngga support

sekarang saya ngetestnya pake MSSQL localdb dengan GUID database name

Bukan wkwkwkwk

ngeri bener nge seed sejuta pak wkwk

ini hampir sama kencengnya dengan in memory

padahal production database saya PGSQL family

Kantor lama dlu gw pernah. Karena pengen nyoba fitur searchnya. Yg pke fulltext-search sama modal like query. Karena blum percaya dri katanya. Dn ya, dua2 nya ga rekomen IMO. Wkwkwkwk

butuh seseorang buat convince ngetest frontend itu worth

biasanya males karena ujung ujungnya tetep tes sendiri di browser wkwkw

Mana dn harus ngapain?

anjir. saya pernah ngeseed > 1 miliar record. seminggu baru kelar

ooh case nya fts

kalo componentnya interaktif ya oke lah, aku masih ngga paham sama test yg expect tulisan anu on component anu

belum lagi kalo seedernya ada bug, mesti diulang

Itu gw pas run 1 jta. Kena memory limit kalo ga salah. Alhasil running bertahap berapa ratus gtu wkwkwk

sampe saya ngodingnya pake 3 laptop

busyet

buset

Iyo, tpi ga ada yg kupake. Gw ngikutin cara bank akhirnya

Nah kan, yg ginian ga bisa di auto generate, logic tersendiri. Beneran more effort

mestilah, itu udah occupied buat seed doang wwkk

Ujung2nya qa yg test juga

btw nge seed apa tuh pak ?

data wkwkwk

1 ngeseed production, 1 ngeseed local (test), 1 buat coding

data schematic part mobil

Hooo gw dulu data warehouse sih.

saya waktu itu pengen ditransform aja ke relational

tadi poin yang disampein soal effort juga happines.
kalo happy ya lanjut, kalo engga ya skip

and it was worth it

edun, 1 miliar itu belum kebayang

pas itu gw ga izinin orang QA buat ngubah value langsung dari database

di production nanti gaboleh ada manusia yang ngubah value apapun di database

mau ngubah anything di database harus lewat running app

nggak lewat itu, you risk the whole business to go down

mencegah orang delete record atau drop table secara "ga sengaja" juga sebenernya

langsung berasa kecepatan insert menurun drastis pas rownya udah di atas 100 ribu

Yg enak itu kalau pake library atau orm yg udah ada objek mock/fake/stub didalemnya, jadi gak perlu mock2an/fake2an/stub2an lg. Kalo command yg dijalanin test, otomatis execute objek versi mocked/fake. Ga perlu generate apa2, ga perlu setup2 apa2 diluar code, ga perlu tear up and down

pas itu juga ada requirements "bisa customizable, dinamis dari database valuenya"
gw tolak

good case dengan dotnet

Paling tinggal ngetest yg pure functionz doank

inii pakai nest kah?

wkwkwk, sempet ngecek resource CPU nya gak pak ?

100% mentok

itu azure SQL

terus saya scale up ke tier 7 jutaan, barulah lancar

setelah selesai seed, saya scale down lagi ke tier 200 ribuan

hah?

mantap wkwkwk
tadi kena 1 minggu ya

Wkwkwkwk, id auto increment + banyak index + bukan nvme ini kayaknya sampe seminggu.

1 minggu lebih. plus development time

3-5 minggu lah total

1 bulan

WUUT

kadang udah jalan 3 hari, crash

masih pake yang 7 jutaan ?

1 bulan mayan tuh jadinya wkkw

saya naik turunin sih tergantung lagi seed apa ngoding

enaknya azure bisa scale up & down instantly gitu