#13 dari TDD sampai BDD – transkrip
Posted: September 28th, 2009 | View Commentsingin kontribusi membantu teman macet? ketik bagian podcast yang kamu suka di post ini ala WIKI dengan login di facebook connect disamping kanan dan klik edit this. Dengan membantu teman macet, kamu ikut berpartisipasi dalam membuat konten ini lebih mudah diakses untuk orang-orang yang tidak bisa mengkonsumsi audio
RW: kali ini gue pengen ngomong sama Hendry lagi soal lebih ke Test Driven Development karena gw tau Hendry sangat aktif. Lo mau ngejelasin sedikit ga kenapa lo suka Test Driven Development.
HL:boleh. Test driven development gw demen karena bisa dibilang ini natural way of working. Jadi gimana cara lo nulis codenya itu. Jadi sebenernya awal awalnya gw dengan Test Driven Develop ga make sense. Kalau lo pikir pikir the fact, jadi pertama tama lo mesti nulis test ini sebelon code. Sebenernya ga make sense kalau lo pikir pikir apa yang mesti lo test kalau misalnya lo ga punya code nya. Cuman belakangan lo bakalan nyadar kenapa mesti begini makanya mengapa lo mesti nulis code kalau misalnya ga requirementnya. Jadi sebenernya lo ga bakal nulis code yang ga ada di requirement.
RW: Okay, jadi lo melihat Test Driven Development ini sebagai do as little as possible buat nge satisfy specification nya yah. Jadi lebih Specification Driven Development sebenernya yah.
HL: Salah satu manfaatnya yah itu. Walaupun manfaat kedua adalah buat design.
RW: Nah ini interesting juga bahwa lo ngomong Test Driven Development pertama adalah yaitu buat specifikasi, yang kedua adalah buat design. Tapi lo ga sama skali ga ngomong bahwa the fact pentingnya buat ngetest code lo.
HL: Karena sebenernya Test Driven Development ini satu hal yang paling misleading dari Test Driven Development atau Unit karena penggunaan kata test. Sebenernya Test Driven Development itu doesn’t have anything to do with test, in fact Test Driven Developmentnya tahunnya sebagai development bukan buat test. Jadi Test Driven Development itu ga ada hubungannya sama test. Ini adalah bagaimana development itu adalah development practice bukan test practice. Jadi kalau gw ngomong unit test, kadang kadang ada beberapa team yang misalnya ga familiar dengan unit uest, yang ada di bayangan mereka adalah quality. Sebenernya unit test itu bukan nyari bug, sama skali bukan buat nyari bug. Makanya belakangan ini unit test mulai di ganti. Misalnya x unit, diganti kata test di x unit kata baru diganti dengan kata fact. Karena itu adalah fact requirement. Dan Test Driven Development mulai berkembang juga menjadi design by example atau bisa juga yang mulai baru mulai di ganti dengan Behaviour Driven Design.
RW: Coba bentar bentar, kayanya mulai overload ni. Gw belon pernah denger design by example sama Behaviour Driven Design. Ini semua bedanya apa ni, dari Test Driven ke design by example and so forth. Coba lo bisa jelasin sedikit.
HL: Design by eample itu sebenernya memperbaiki kata Test Driven Development. Jadi design by example itu kita punya example, examplenya itu adalah test. Jadi kita mengungkapkan fact. Sebenernya yang paling penting dalam satu application itu adalah unit test nya. Sedangkan code sendiri itu adalah . Code itu cuman membuat unit test jadi hijau.
RW: Wah ini kayanya satu fakta yang sangat penting banget karena gw di kerjaan gw sehari hari project saat ini gw ga melakukan Test Driven Development. Di pet project gw di luar waktu kerja, gw melakukan Test Driven Development dan yang gw nemuin adalah code test gw lebih panjang dan lebih banyak dari code yang gw bikin. Ini salah satu kenapa gw tertarik banget ngobrol sama lo tentang Test Driven Development karena gw mikir apakah gw salah nulis test nya menghasilkan spaghetti code di test side atau apakah ini expected?
HL: Sebenernya diskusinya kita mesti lebih rinci apakah ini Test Driven Development versus test after development atau Test Driven Development versus sama skali ga ada unit test. Jadi kalau misalnya lo test Driven Development atau Test After Development, sebenernya jumlat unit test yang lo tulis kan sama ajah jumlah banyaknya. Cuman bedanya lo tulis after development bakalan lebih susah
RW: lo harus refactor code lo supaya akhirnya jadi testable yah.
HL: betul, jadi lebih banyak effort sebenernya. Tapi kalau misalnya kita lagi ngomongin sama skali ga ada nulis unit test, itu sebenernya sudah hal yang sangat sangat salah karena ga ada unit test. Unit test itu bisa di bilang kalau mau pake code atau mau unit test menggunakan mouse sama keyboard. Mouse sama keybouard itu ga scaleable jadi lo ngulangin itu terus tiap kali lo ganti code. Jadi sebenernya buat jangka panjang itu lebih banyak effort. Test Driven Development itu sebenernya, ada yang bilang itu adalah evolution dari , sebenernya menurut gw itu ga accurate. Menurut gw itu Test Driven Development itu adalah hal yang sama tapi di lakukan dengan hal yang benar. Jadi Test Driven Development misalnya lo bikin test yang terlalu banyak accertention nya, terlalu banyak ga jelas, ga bisa dibaca. Tapi Test Driven Development itu bikin grammer yang baku buat nulis ini test, dengan kata kata when. When gw kirim duit dari account A to account B behave like account transfer A money, jadi itu adalah grammer buat nulis Test Driven Development.
RW: Jadi rules buat make sure kalau lo ngelakuin Test Driven Development lo ngelakuinnya the right way dengan testing the right stuff di level yang tepat juga yah.
HL: Benar, Sebenernya beberapa introduce symantic yang bikin lo berpikir dengan cara yang benar. Misalnya symantic yang biasa dipake jadi dalam Test Driven Development ada yang namanya context. Jadi kalau lo nulis test lo mesti dipanggil contextnya apa dan context itu specific. Jadi contextnya lo bisa nulis jika a adalah apa dan b adalah apa maka action nya apa. Maka ada context ada action dan ada associate. Jadi tiga context itu define lo punya unit test. Jadi lebih gampang dibaca. Salah satu framework yang lo bisa liat kalau lo mau coba coba Behaviour Driven Development dot Net itu ada MBA itu lumayan . Itu adalah extention dari N unit.
RW: Wow, very cool. Terus skarang ada banyak discussion soal kalau unit test lo pake mocking framework atau ga. Dan kebanyakan kalau Test Driven Development people pasti make mocking kan karena bagi mereka tanpa mocking ngelakuin Test Driven Development lumayan sulit ya karena harus buat stubs nya satu per satu dan sebagainya. Menurut lo gimana? Posisi lo terharap mocking framework kaya apa?
HL: Mocking framework tuh bener bener membantu. Jadi bisa gw bilang itu hal yang bagus. Gw ga bisa argument tentang hal yang jelek tentang mocking framework.
RW: Tapi satu post yang g baca di blog lo, lo membahas tentang specification pattern yah. Lo argue bahwa ga setiap saat lo butuh mocking framework.
HL: Betul, nah ini sebenernya lo juga mesti aware bahwa ada 4 macam test isolation. Jadi ada stub, mock, fake, ada spy. Jadi lo mesti pake, Jadi mock itu bukan satu satu nya hal yang lo bisa pakai sebegai senjata lo. Jadi lo mesti bisa pake hal yang tepat supaya lo bisa nulis test yang lebih bagus,
RW: Lo bisa run through dikit bedanya antara mock, stub, fake sama spy itu apaan?
HL: Jadi kalau bedanya stub sama mock itu sebenernya itu paling penting. Sebenernya bedanya mock sama stub itu adalah state verification dengan behaviour verification. Jadi kalau misalnya lo tulis dengan Stubs misalnya let say lo beli barang bikin sell order 20 pieces Nokia. Jadi lo kalau misalnya lo menjual 20 pieces Nokia, lo mau make sure bahwa barang di inventory lo itu berkurang lebih sebanyak 20. Nah ada 2 cara buat ngetest ini jadi cara yang pertama menggunakan Stubs. Misalnya lo bikin frame repository. Jadi isinya ada 100 nokia melakukan sales jadi sisanya tinggal 80 barang. Jadi ini adalah technique stub. Jadi lo stub 100 barang di dalam situ. Nah satu lagi itu techique Mock. Mock ini lo tuh ga peduli lo punya data base atau lo punya repository, dia cuman peduli lo sebagai part of sales operation lo panggil method buat mulangin barang sebanyak barang 20 biji ke repository dan lo ga peduli state nya bahwa state dari repository kaya apa. Jadi lo cuman butuh interaction, interaction antara satu object dengan object lain. Nah itu adalah mock.
RW: Kalau fake dan spy?
HL: Kalau fake itu cuman . Sorry yang satu lagi bukan spy, tapi dummy. Fake itu jadi kaya yang tadi gw sebutin itu repository sendirinya itu adalah fake bahwa repository itu bisa bekerja dengan baik, full finctional, tetapi lo ga bisa taro di production.
RW: Ini kaya ibaratnya kaya lo nulis stubs secara manual yah. Itu sebenernya lo bikin fake object yah.
HL: Benar. Untuk 2 hal yang gw sering pake itu yang tadi repository itu product nya sendiri adalah stub karena misalanya lo get Nokia lo balikin Nokia sebanyak 100 biji, yang lo balikin itu adalah stub. Repository sendirinya adalah fake. Jadi repository itu sering gw dengan menggunakan inner memory, misalnya pake siculate. Jadi kalau pake siculate itu ga mungkin pakai siculate di production, tapi cuman ada disitu sebagai fake. Dan satu lagi yang sering gw pakai misalnya buat station as requested sering pakai fake fully functional kalau lo tulis disitu requst.set lo bisa pakai dengan baik, cuman itu ga bener bener web beneran, itu cuman boongan.
RW: Sekedar history juga itu salah satu yang paling sulit buat Test Driven Development people dalam menghadapi web form adalah htp context itu yah karena life cycle nya kita ga control dan tiba tiba ada dan gunanya sangat banyak. Dan ini salah satu yang cukup sulit untuk di fake. Iya ga sih?
HL: Benar. Ini sebenernya gw ga mau Fake, sebenernya menurut gw hal yang ga bagus. Menurut gw sebaiknya ga di test karena kita mau web people ga mengandung logic ga mengandung requirement apa pun, web itu cuman buat presentation doang sebenarnya.
RW: Dan ini kembali ke arah kenapa sekarang ASP. Net punya webform juga punya visi framework yah which is membiarkan view nya sangat pasif, sangat dump dan ga membagi semua kepintarannya ke controller dan module itu yah. Skarang gw pengen balik ngomong soal mocking lagi bahwa tadi lo ngomong mocking itu test bukan state tapi interaction. Jadi kalau misalnya gw nulis Unit Test biasanya gw ngomong function ini misalnya lo should ngambil semua barang dari repository dan misalnya gw nge test controller. Jadi system under test nya adalah sebuah controller dan gw pengen ngetest kalau gw manggil lo, di object controller ini dia akan ngambil semua barang dari repository. Kalau gw ngegunain mocking framework yang akan gw lakuin adalah gw set repository boongan, gw bilang repository ini akan dipanggil, method nya find all dan should return a couple of stubs. Abis itu gw panggil controller nya dan gw bakal asersi apakah find nya dipanggil beneran apa ga. Biasanya tapi system ga simple itu kan biasanya lo pengen nge asersi bahwa, okay, repository bakal ngembaliin semua object dan untuk setiap object ini gw bakal ngelakuin operasi ini yah. Jadi gw punya dua expektasi satu repository bakal di panggil dan ngebalikin beberapa object dan expektasi yang kedua adalah setiap object yang dipanggil harus dilakukan operasi tertentu, Dari sisi lo seorang Test Driven Development guy itu seharusnya gw lakukin itu di dua test scenario yang berbeda atau di satu scenario ajah? Karena sangat mudah untuk melakukan ini di satu test iyah ga sih. Gw tinggal bikin expect expect jalanin tapi secara bersamaan gw bisa take into extreme iya ga sih. Gw bisa bilang expect expect expect ini banyak banget expectasi nya karena gw bisa melihat berbagai macam interaksi dan secara code gw ngerasa less repetition on the testing side. Gw ga usah bikin mocking nya berkali kali, stub gw berkali kali. Gw set up once, gw set up expectation nya semua dan gw test all in one go. Lo ada opini ga tentang kedua approach tersebut?
HL: Sebenernya lo baru point out tentang perbedaan Test Driven Development biasa dengan Behaviour Driven Development. Jadi kalau lo main di Behaviour Driven Development lo mesti bikin expektasinya itu, lo mesti bikin context dan mesti bikin expektasi satu per satu, jadi lo ga bikin satu biji expektasi yang isinya segala sesuatunya. Lo bikin expektasinya pendek dan bagian yang panjang biasanya bagian yang paling penting kenapa Behaviour Driven Development gampang dibaca adalah karena biasanya isinya cuman 2,3, atau 4 baris doang, jadi ga lebih dari itu. Maksudnya isi metod lo cuman palingan 4 baris. Yang paling panjang biasanya context, set up context nya itu yang paling panjang. Jadi kalau misalnya lo pake cara semua langsung ke method biasanya bakalan panjang banget isinya dan susah dibaca. Jadi built in context ini penting. Perbedaan yang paling penting ini sebenernya kalau perbedaan antara Test Driven Development biasa dengan Behaviour Driven Development biasanya itu paling kelihatan, satu test harus context dalam TDD. Jadi 1 test itu lo set up context nya disana, set up segalanya disana. Emang ga ada set up method, cuman set up method itu akhirnya ga lo pake buat set up context setiap test cases. Tapi kalau Behaviour Design set up method itu dipakai buat set up context nya jadi isi dari test method itu strictly isinya cuman execute dan exertion doang
RW: Kembali ke soal Behaviour Driven Development itu tadi, ini sebenernya nge apply good practices principals yang sama yang biasa kita lakuin di code tapi dilakuin di unit test. Jadi satu method ya harus punya satu single purpose, dan juga dengan naro semua expektasi nge set context nya itu di set up method kita juga ga melanggar principal don’t repeat youself. Kita cuman punya single point of control, set up semua context nya di set up method dan setiap methodnya harus punya 1 single purpose which is nge verify scenario yang sesuai dengan behaviour specification nya yah.
HL: Dan sebenernya rule of thumb nya adalah 1 text picture atau 1 scenario, jadi ini beda banget sama Test Driven Development. Kalau TDD kan 1 test method per scenario. Jadi kalau di tarik keluar satu test picture itu meng describe satu scenario itu, 1 scenario doang. Jadi dia ga meng describe scenario lain. Jadi scenario lain itu di define sebagai text picture baru.
RW: Okay. Maksud lo scenario itu misalnya gimana?
HL: Jadi scenario itu misalnya di kasus lo ini, kasus lo ini misalnya adalah jika barang inventory available maka harus melakukan ini. Itu adalah satu test picture. Itu bukan satu test method.
RW: Tapi apakah bukan dalam hal itu lo cuman punya satu test method dalam satu test picture itu.
HL: Nah jadi lo ga selalu bisa di karena barang lo available maka. Setelah kata maka itu bisa kenapa pakai test method.
RW: Dan ini buat memastiin bahwa lo sudah nge cover berbagai macam outcome nya yah. Jadi walaupun lo nge cover scenario yang sama tapi mungkin lo bisa menanyakan oh postive nya gimana, negative case nya gimana, neutral case nya gimana.
HL: Benar, dan ending nya sendiri punya tool, jadi kalau lo run dia bisa generate report yang lo bisa baca sebagai document biasa. Dia bisa ngubah camel casing di document lo menjadi kata kata yang bahasa inggris.
RW: Kayanya kita nge jump satu fakta yang paling penting. Semoga podcast pendengarnya ga pada bingung which is kita nulis grammer behaviour nya lebih sering sebagai nama methodnya yah. Kita menggunakan camel casing atau bahkan dipisahin dengan underscore dan sebagainya yah. Jika bla bla maka bla bla. dan ini nama methodnya. Dan yang lo bilang barusan adalah beberapa Behaviour Driven Development akan mengubah nama tersebut menjadi sebuah document yang mudah di baca.
HL: Iyah, benar banget, kurang lebih begitu.
RW: Okay, very cool. Terus ada hal lain yang mungkin lo pengen ngomongin soal Test Driven Development. mungkin ada kesulitan kesulitan atau tips tips tertentu yang lo biasa pake dalam melakukan Test Driven Development.
HL: Sebenernya yang paling susah dalam Test Driven Development adalah meyakinan tim lo. Jadi management lebih susah dari computer, dari pada technical stuff. Yang paling susah adalah banyak orang yang complain bahwa lo setelah pakai TDD masih ada bugs juga, jadi buat apa lo pakai TDD. Atau juga gw sudah punya tester dari vendor lain. Jadi tester itu khusus kerjaannya tester jadi buat apa kita mesti nulis test panjang panjang. Ini sebenernya sama presepsinya karena kata kata test ini. Jadi ini sebenernya yang paling penting buat highlight bahwa sebiasa mungkin gw menghindari kata kata test.
RW: Okay. Dan ini gw juga pengen tied in sama beberapa discusi yang gw punya yah, which is sama persis sama scenario lo dimana timnya lebih cendurang ejay in sense of timnya ngelakuin scrum, nge keep track velocity nya dan sebagainya tapi pada saat yang bersamaan karena projectnya cukup besar akhirnya butuh testing team dan karena kata kata Test Driven Development itu sendiri menjadi blur siapa yang melakukan testing, siapa yang responsibility nya apa dan sebagainya. Kalau kata test itu berubah jadi mungkin Behaviour Driven Development atau apa pun kata kata yang lain mungkin bisa mengatasi salah kaprah itu yah bahwa ini all about coming up with good design and less about quality. Walaupun akhirnya nge impact quality juga gitu kan.
HL:Jadi jangan sampai orang, makanya yang paling berbahaya itu kan orang sudah nulis ini test, ga nge test lagi applicationnya, Karena unit test itu sebenernya bukan nge test. Jadi kalau misalnya lo ngeliat bug setelah Test Driven Development sebenernya ga berhubungan. sebenernya itu sudah beda discusi,
RW: Okay terima sudah ngobrol sama temanmacet.com. Mungkin lain kita bisa ngobrol tentang topic yang berbeda.
This page is wiki editable click here to edit this page.
[...] transkrip [...]