Test yazmak \u00e7o\u011fu yaz\u0131l\u0131mc\u0131 ve asl\u0131nda dolayl\u0131 olarak \u015firketler i\u00e7in b\u00fcy\u00fck bir tabu. Bunun \u00e7ok\u00e7a sebebi var ama bug\u00fcn yaz\u0131l\u0131mc\u0131lar taraf\u0131nda \u00f6n plana \u00e7\u0131kan bir konuyu inceleyece\u011fim.<\/p>\n\n\n\n
\n\u201cTest yazmak istiyorum ama ne yazaca\u011f\u0131m\u0131<\/strong> bilmiyorum\u201d<\/p>\n<\/blockquote>\n\n\n\n
Bu konuyu s\u0131kl\u0131kla duyar\u0131z \u00e7\u00fcnk\u00fc ger\u00e7ekten ilk kez test yazmaya ba\u015flayan insanlar ne yazaca\u011f\u0131n\u0131 bilemiyor. Ben de bilmiyordum. Bu konuda herkes rahat olsun, ilk kez yazan \u00e7o\u011fu ki\u015fi bilmiyor ve test yazmak zamanla geli\u015fen bir\u015fey. Kulland\u0131\u011f\u0131n\u0131z dilin\/framework\u00fcn k\u00fclt\u00fcr\u00fc; \u015firketin\/ekibin k\u00fclt\u00fcr\u00fc ve tecr\u00fcbenizle geli\u015fiyor. \u0130lk yazd\u0131\u011f\u0131n\u0131z testler k\u00f6t\u00fc olabilir, gereksiz yere yaz\u0131lm\u0131\u015f olabilir. Bunlarda s\u0131k\u0131nt\u0131 yok. \u00d6nemli olan test yazma i\u015fini bir k\u00fclt\u00fcr haline getirebilmek.<\/p>\n\n\n\n
Neden test yazmal\u0131y\u0131z sorusu defalarca konu\u015fuldu. Hi\u00e7 bu konulara girmeyece\u011fim. Testin \u00f6nemini kavram\u0131\u015f fakat ne yazaca\u011f\u0131n\u0131 bilmeyenler i\u00e7in do\u011frudan konuya girmek istiyorum. Ben \u015fahsi test yakla\u015f\u0131m\u0131mda TDD (Test driven development) y\u00f6ntemini tercih ediyorum. \u00d6rne\u011fin API geli\u015ftiriyorsam, bunu postman ile test etmiyorum. Tamamen kulland\u0131\u011f\u0131m k\u00fct\u00fcphanedeki test yap\u0131lar\u0131 ile birlikte geli\u015ftiriyorum. Y\u00f6netti\u011fim projelerde, test konusunda izledi\u011fim \u00e7ok net bir yakla\u015f\u0131m var. Projede geli\u015ftirici arkada\u015flar TDD uygulam\u0131yor olabilir, ancak projenin en \u00f6nemli k\u0131s\u0131mlar\u0131 i\u00e7in \u00e7ok b\u00fcy\u00fck oranda test yaz\u0131lm\u0131\u015f olmal\u0131. Di\u011fer k\u0131s\u0131mlar i\u00e7in ise ekibin k\u00fclt\u00fcr\u00fcne ve yakla\u015f\u0131m\u0131na g\u00f6re planlama yap\u0131yorum.<\/p>\n\n\n\n
Ger\u00e7ek hayattan \u00f6rnekler<\/h3>\n\n\n\n
Peki nelere test yaz\u0131yoruz? Neler \u00f6nemli? Bu soru asl\u0131nda projeden projeye g\u00f6re de\u011fi\u015fir. Testin bi\u00e7imi de projeye g\u00f6re de\u011fi\u015fir. Ben burada biraz daha web tabanl\u0131 backend uygulamalar\u0131 \u00fczerine \u00f6rnekler verece\u011fim.<\/p>\n\n\n\n
Linklerimiz \u00e7al\u0131\u015f\u0131yor mu?<\/h4>\n\n\n\n
Her web tabanl\u0131 uygulaman\u0131n birinci test edilecek k\u0131sm\u0131 sayfalar\u0131m\u0131z do\u011fru bi\u00e7imde y\u00fckleniyor mu sorusudur. Bu asl\u0131nda \u00e7ok kolay bir test. Ayn\u0131 zamanda do\u011frulu\u011fu da zay\u0131f bir test. \u00c7\u00fcnk\u00fc local ortamda \u00e7al\u0131\u015f\u0131rken bir test veritaban\u0131 ile \u00e7al\u0131\u015f\u0131yorsunuz fakat production\u2019da farkl\u0131 datalar gelebiliyor ve linklerimiz o datalara uyum sa\u011flayamayabiliyor. Yine de, 1 > 0 <\/strong>diyerek ilk etapta \u201ct\u00fcm linkler \u00e7al\u0131\u015f\u0131yor mu\u201d testimizi yaz\u0131yoruz.<\/p>\n\n\n\n
Bunun i\u00e7in 2 y\u00f6ntem kullan\u0131labilir. Kulland\u0131\u011f\u0131n\u0131z framework, size bir route listesi sunuyor olabilir. Bu route listesi ile t\u00fcm linkleri tek tek test edebilirsiniz. Veya, kendi test ortam\u0131n\u0131z\u0131 crawl ettirebilirsiniz. Ben size ikinci \u00f6rne\u011fi verece\u011fim.<\/p>\n\n\n\n
class AutomatedTest extends TestCase\n{\n private $bulkUrls = [];\n\n public function testLinks()\n {\n $client = $this->get('\/');\n $client->assertStatus(200);\n $response = $client->baseResponse->getContent();\n $this->checkAllLinks($response);\n }\n\n private function checkAllLinks($html)\n {\n $skipLinks = [\n '\/login',\n '\/logout',\n ];\n $links = $this->getLinksFromHtml($html);\n\n foreach ($links as $url) {\n $req = $this->get($url);\n if (in_array($url, $skipLinks, false)) {\n continue;\n }\n\n $this->assertEquals(200, $req->baseResponse->status(), $url);\n $this->checkAllLinks($req->baseResponse->content());\n }\n }\n\n public function getLinksFromHtml($html)\n {\n $dom = new DOMDocument();\n\n @$dom->loadHTML($html);\n\n $urls = [];\n $links = $dom->getElementsByTagName('a');\n foreach ($links as $link) {\n $url = $link->getAttribute('href');\n if (starts_with($url, config('app.url'))) {\n $url = str_replace(config('app.url'), '', $url);\n if (!in_array($url, $this->bulkUrls, true)) {\n $this->bulkUrls[] = $url;\n $urls[] = $url;\n }\n }\n }\n\n return $urls;\n }\n}\n\n<\/code><\/pre>\n\n\n\n\u00d6ncelikle belirtmeliyim ki, yukar\u0131daki kod par\u00e7as\u0131n\u0131 10 y\u0131l \u00f6nce bir projede kullanm\u0131\u015ft\u0131m. Yani kod kalitesini g\u00f6rmezden gelmenizi \u00f6neririm :) Testimiz ise olduk\u00e7a basit. Anasayfaya bir istek at\u0131yoruz, 200 geldi\u011fini do\u011fruluyoruz. Daha sonra anasayfadaki t\u00fcm linkleri topluyoruz ve o linklere de istek at\u0131p 200 geldi\u011fini do\u011fruluyoruz. Bunu recursive bi\u00e7imde uygulay\u0131p sitedeki t\u00fcm linkleri \u201cbasit bi\u00e7imde\u201d test etmi\u015f oluyoruz. Bunu \u00e7ok kolay bi\u00e7imde \u00e7oklayabilirsiniz. Bir kullan\u0131c\u0131y\u0131, sonras\u0131nda farkl\u0131 roldeki ba\u015fka kullan\u0131c\u0131y\u0131 login edersiniz ve o \u015fekilde test edersiniz. T\u00fcm senaryolar\u0131 kar\u015f\u0131lamaz, sadece HTTP500 hatas\u0131 almad\u0131\u011f\u0131m\u0131z\u0131 do\u011frulam\u0131\u015f oluruz. Ya da data kaynakl\u0131 bir problem production ortam\u0131nda olabilir. Ama dedi\u011fim gibi, hi\u00e7 yoktan bu test ile bile onlarca sayfan\u0131n en az\u0131ndan happy path dedi\u011fimiz \u201cher\u015feyin do\u011fru oldu\u011funu d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcm\u00fcz senaryoda\u201d do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olaca\u011f\u0131z. Aman dikkat edin, her\u015feyin 200 d\u00f6nmesi sizi yan\u0131lg\u0131ya u\u011fratmas\u0131n.<\/p>\n\n\n\n
Burada maksimum detaya girmek sizin elinizde. Bulk bi\u00e7imde yapmak yerine, her sayfa i\u00e7in \u00f6zel testler yazabilirsiniz. Ben sadece basit bir HTTP200 kontrol\u00fcn\u00fcn bile ne kadar faydal\u0131 olabilece\u011fini aktarmak istedim.<\/p>\n\n\n\n
\u00d6nemli fonksiyonlar\u0131n testleri<\/h4>\n\n\n\n
Test ile ilgili yaz\u0131lan makalelerde genel olarak test fonksiyonlar\u0131n\u0131n nas\u0131l kullan\u0131laca\u011f\u0131 yaz\u0131l\u0131yor. assertTrue(true) \u00f6rnekleri verilip ge\u00e7iliyor. Ya da github \u00fczerinde repolar\u0131 gezdi\u011finizde, genelde k\u00fct\u00fcphanelerin internal testleri ya da paketlerin testleri oluyor. Dolay\u0131s\u0131yla \u201ctest yazmak istiyorum ama ne yazaca\u011f\u0131m\u0131 bilmiyorum\u201d sorusuna tam yan\u0131t bulam\u0131yoruz. \u00c7\u00fcnk\u00fc testler projelere \u00f6zeldir. Bu y\u00fczden burada biraz daha detaya inmek istedim. Asl\u0131nda \u00f6rne\u011fi g\u00f6rd\u00fc\u011f\u00fcn\u00fcz zaman \u201cne varm\u0131\u015f bunda\u201d diyeceksiniz muhtemelen. Ama backend uygulamar\u0131nda test yazmak bu kadar basit.<\/p>\n\n\n\n
\u00d6nemli olan \u015fey, test yaz\u0131labilir bir kod yazm\u0131\u015f olman\u0131z. \u00d6rne\u011fin t\u00fcm i\u015flemleri controller i\u00e7erisinde yapt\u0131r\u0131rsan\u0131z, bunu test etmeniz kolay olmayabilir. Yaz\u0131l\u0131m geli\u015ftirmedeki SOLID vb. prensiplere sad\u0131k kalmal\u0131s\u0131n\u0131z.<\/p>\n\n\n\n
\u0130kinci \u00f6nemli konu ise, sabit bir test veritaban\u0131n\u0131z\u0131n olmas\u0131. \u00c7\u00fcnk\u00fc testleri tekrar tekrar \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda hep ayn\u0131 sonucu vermeli. Veritaban\u0131 de\u011fi\u015firse, testleriniz do\u011fru sonu\u00e7 vermeyebilir.<\/p>\n\n\n\n
Sabit veritaban\u0131 konusunu, 2 y\u00f6ntem ile sa\u011flayabilirsiniz. S\u0131f\u0131rdan geli\u015ftirdi\u011fimiz projelerde, seeder yaz\u0131yoruz ve veritaban\u0131n\u0131n istedi\u011fimiz gibi dolmas\u0131n\u0131 sa\u011fl\u0131yoruz. Sonradan dahil oldu\u011fumuz projelerde ise, \u00f6nemli kullan\u0131c\u0131 verilerini \u00e7\u0131kartarak, test veritaban\u0131n\u0131n basite indirgenmi\u015f bir halini al\u0131yoruz ve onun \u00fczerinden testleri \u00e7al\u0131\u015ft\u0131rmaya ve datay\u0131 geli\u015ftirmeye devam ediyoruz.<\/p>\n\n\n\n
Gelin bir \u00f6rnek \u00fczerinden gidelim. <\/p>\n\n\n\n
public function testFamilyDiscount()\n {\n \/** @var ProductDiscountService $productDiscountService *\/\n $productDiscountService = app(ProductDiscountService::class);\n\n \/\/ Annem + Babam\n $person = [\n 'mother' => [\n 'isActive' => true,\n ],\n 'father' => [\n 'isActive' => true,\n ],\n 'sons' => [\n [\n 'isActive' => false,\n ],\n ],\n ];\n $product = Product::where('family_discount_percent', '>', 0)->first();\n\n $this->assertTrue(\n $productDiscountService->canGetFamilyDiscount(\n $product,\n $person\n )\n );\n\n $product = Product::where('family_discount_percent', '=', 0)->first();\n\n $this->assertFalse(\n $productDiscountService->canGetFamilyDiscount(\n $product,\n $person\n )\n );\n }<\/code><\/pre>\n\n\n\nYukar\u0131da g\u00f6rd\u00fc\u011f\u00fcn\u00fcz test, bir uygulamada \u00f6zel bir durumu test ediyor. Baz\u0131 \u00fcr\u00fcnler aileler i\u00e7in %X indirim uyguluyor. E\u011fer o \u00fcr\u00fcne anne+baba, anne+baba+\u00e7ocuk, anne+\u00e7ocuk, baba+\u00e7ocuk gibi bir ba\u015fvuru yaparsan\u0131z, size indirim uygulayacak. Buras\u0131 ger\u00e7ekten kritik \u00f6neme sahip. \u00c7\u00fcnk\u00fc, e\u011fer son kullan\u0131c\u0131ya yanl\u0131\u015f bir fiyat g\u00f6sterirseniz, ba\u015f\u0131n\u0131z a\u011fr\u0131yabilir. ,<\/p>\n\n\n\n
Bakal\u0131m test ne yap\u0131yor. \u0130ndirimlere karar veren bir methodumuz var:
canGetFamilyDiscount<\/code> Bu method, verilen \u00fcr\u00fcn ve ba\u015fvuran aile yap\u0131s\u0131 i\u00e7in true\/false yan\u0131t d\u00f6n\u00fcyor. Biz de yukar\u0131da bahsetti\u011fim \u00e7e\u015fitli formatlar\u0131, belirleyip hem indirim i\u00e7eren hem indirim i\u00e7ermeye \u00fcr\u00fcnleri fonksiyona g\u00f6ndererek do\u011fru yan\u0131t vermesini sa\u011fl\u0131yoruz.<\/p>\n\n\n\nBu test, kullan\u0131c\u0131ya indirim g\u00f6sterilece\u011fini %100 garanti alt\u0131na almaz. \u00c7\u00fcnk\u00fc onun i\u00e7in muhtemelen farkl\u0131 fakt\u00f6rler de vard\u0131r. En basitinden, frontend taraf\u0131n\u0131n bu veriyi do\u011fru i\u015flemesi gerekir. Ama en az\u0131ndan, biz bu methodun belirtilen ko\u015fullar i\u00e7in do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan %100 emin olmu\u015f oluruz. Bu methodda ileride yap\u0131lacak bir de\u011fi\u015fiklik, bizim sonu\u00e7lar\u0131m\u0131z\u0131 etkilemez ve do\u011fru \u00e7al\u0131\u015faca\u011f\u0131ndan emin oluruz. E\u011fer buradaki business logic de\u011fi\u015firse, testi de ona uygun bi\u00e7imde tekrar g\u00fcncelleriz. \u00d6rne\u011fin %X indirim i\u00e7in art\u0131k minimum 4 ki\u015filik ba\u015fvuru yap\u0131lmal\u0131d\u0131r gibi bir kural gelebilir. Yine bu kural\u0131n do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 da bu testler sayesinde garanti alt\u0131na al\u0131r\u0131z.<\/p>\n\n\n\n
Bir not: Bu test asl\u0131nda biraz basitle\u015ftirilmi\u015f durumda. Biz arkaplanda yakla\u015f\u0131k olarak 25 adet varyasyon yazm\u0131\u015f\u0131z. Her unique durumu ayr\u0131 ayr\u0131 test ediyoruz. Her biri bizim i\u00e7in \u00e7ok kritik. Yanl\u0131\u015f ba\u015fvuruya indirim uygulamak ya da indirim uygulanacak birisine uygulamamak \u00e7ok k\u00f6t\u00fc bir senaryo.<\/p>\n\n\n\n
\u0130kinci not: Bu test g\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi asl\u0131nda bir veritaban\u0131 ba\u011flant\u0131s\u0131 kullan\u0131yor. Burada bahsetti\u011fim gibi, test i\u00e7in veritaban\u0131n\u0131n haz\u0131r olmas\u0131 gerekiyor. Yoksa
$product = Product::where('family_discount_percent', 0)->first()<\/code>i\u00e7in bir yan\u0131t gelmez ve test \u00e7al\u0131\u015fmaz. Ya da bu konuda bizim kulland\u0131\u011f\u0131m\u0131z Factory s\u0131n\u0131flar\u0131 var. Test esnas\u0131nda, duruma \u00f6zel bir \u00fcr\u00fcn yaratman\u0131z\u0131 sa\u011fl\u0131yoruz.<\/p>\n\n\n\n$validProduct = factory(Product::class)->create([\n 'family_discount_percent' => 18,\n]);\n$invalidProduct = factory(Product::class)->create([\n 'family_discount_percent' => 0,\n]);<\/code><\/pre>\n\n\n\nYetki (authorization) testleri<\/h4>\n\n\n\n
Yetki testleri, olmazsa olmaz testlerimizin ba\u015f\u0131nda gelir. Hatta yukar\u0131daki her\u015feyi bo\u015fverin, ilk olarak buraya odaklan\u0131n. Yetki kontrol testleri; endpointleri, methodlar\u0131 yazarken ele al\u0131nmal\u0131, sonraya b\u0131rak\u0131lmamal\u0131. E\u011fer bir endpoint ya da bir method, kullan\u0131c\u0131n\u0131n rol\u00fcne ya da kullan\u0131c\u0131ya g\u00f6re farkl\u0131 davran\u0131yorsa orada mutlaka ba\u015fkas\u0131n\u0131n datas\u0131n\u0131n g\u00f6r\u00fcnmedi\u011finden, g\u00fcncellenmedi\u011finden, ba\u015fkas\u0131 ad\u0131na kay\u0131t olu\u015fturulamad\u0131\u011f\u0131ndan vs emin olmal\u0131s\u0131n\u0131z. (Buna \u00e7ok basit bi\u00e7imde IDOR a\u00e7\u0131klar\u0131na kar\u015f\u0131 \u00f6nlem diyebiliriz. Detaylar \u015furada: https:\/\/twitter.com\/fkadev\/status\/1720434008671055961<\/a>)<\/p>\n\n\n\n
Asl\u0131nda burada yap\u0131lacak \u015fey yukar\u0131da verdi\u011fim 2 \u00f6rnekten farkl\u0131 de\u011fil. Duruma g\u00f6re methodlara da test yazabilirsiniz, endpointlere de. Ben size endpoint \u00f6rne\u011fi g\u00f6sterece\u011fim. \u00d6rne\u011fin sipari\u015f detaylar\u0131n\u0131 g\u00f6steren bir endpointimiz olsun. Bu endpoint i\u00e7in yetki testi yazal\u0131m.<\/p>\n\n\n\n
$user1 = factory(User::class)->create();\n$user2 = factory(User::class)->create();\n$order1 = factory(Order::class)->create(['user_id' => $user->id]);\n\n\/\/ \u0130lk olarak tamamen yetkisiz bir istek yap\u0131yoruz, 401 almay\u0131 bekliyoruz.\n$this->get('\/api\/orders\/'.$order1->id)->assertStatus(401);\n\n\/\/ Success testi yapal\u0131m\n$this->actingAs($user1)->get('\/api\/orders\/'.$order1->id)->assertStatus(200);\n\n\/\/ Yetkisiz test yapal\u0131m\n$this->actingAs($user2)->get('\/api\/orders\/'.$order1->id)->assertStatus(403);<\/code><\/pre>\n\n\n\nYetki testlerini yazmak bu kadar basit. Ve b\u00fcy\u00fck hayat kurtar\u0131c\u0131. \u00d6rnekleri yazd\u0131\u011f\u0131m Laravel\u2019de factory s\u0131n\u0131flar\u0131 ile kolayca istedi\u011finiz senaryoyu \u00fcretebiliyorsunuz.<\/p>\n\n\n\n
Fail senaryolar\u0131 testleri<\/h4>\n\n\n\n
Genellikle yap\u0131lan testler happy path \u00fczerine yap\u0131l\u0131r. Belki ilk geli\u015ftirirken, fail senaryolar\u0131 test edilir. Ama daha sonra, regresyon testleri yaparken genelde success durumu kontrol edilir. Bu testlere ek olarak, hata durumlar\u0131n\u0131n da test edilmesi gerekiyor. Authorization testleri bunun bir par\u00e7as\u0131. Bunun yan\u0131 s\u0131ra, \u00e7e\u015fitli request senaryolar\u0131n\u0131 da test etmemiz gerekiyor.<\/p>\n\n\n\n
Yine basit bir \u00f6rnek ile ilerleyelim. Login sayfam\u0131zda email adresinin girilmesi zorunlu olmal\u0131.<\/p>\n\n\n\n
$this->post('\/api\/login', ['password' => '123456'])\n ->assertStatus(422)\n ->assertJsonValidationErrors(['email']);<\/code><\/pre>\n\n\n\n\u00c7ok basit bir test. Bu senaryoyu niye test etmeliyiz diye d\u00fc\u015f\u00fcnebilirsiniz. Yar\u0131n birg\u00fcn projenizdeki senaryolar k\u00f6kten de\u011fi\u015febilir. \u00d6rne\u011fin hem email hem de username kullanarak login \u00f6zelli\u011fi sisteminize gelebilir. Ve burada kodda yap\u0131lacak bir hata, yanl\u0131\u015f ki\u015fi olarak login olunmas\u0131n\u0131 sa\u011flayabilir. Bunun \u00f6n\u00fcne ge\u00e7ecek olan \u015fey bu testlerdir. Username geldi\u011finde muhtemelen buradaki test hata verecek. Siz d\u00f6n\u00fcp bakacaks\u0131n\u0131z ve buradaki testi g\u00fcncelleyeceksiniz. G\u00fcncelledi\u011finiz test ise her zaman olmas\u0131 gerekti\u011fi gibi \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olman\u0131z\u0131 sa\u011flayacak.<\/p>\n\n\n\n
Muhtemelen bunun gibi, kullan\u0131c\u0131 datas\u0131na g\u00f6re fail yan\u0131t d\u00f6nen senaryolar\u0131n\u0131z vard\u0131r. Bu senaryolar\u0131n ger\u00e7ekten fail etti\u011finden emin olun.<\/p>\n\n\n\n
Benim i\u00e7in testleri yazman\u0131n en b\u00fcy\u00fck g\u00fczelli\u011fi, manuel test etme y\u00fck\u00fcm\u00fc azaltmas\u0131. Kendinize bir format belirledi\u011finizde h\u0131zl\u0131 h\u0131zl\u0131 test yazabiliyorsunuz. Postman vb. ara\u00e7lar \u00fczerinde test etmek -ya da hi\u00e7 test etmemek- yerine, kodu yazarken testleri de yazarsan\u0131z kodlama yaparken bile rahat edersiniz. TDD bence genel olarak yanl\u0131\u015f anla\u015f\u0131l\u0131yor. \u00d6nce t\u00fcm testleri<\/em><\/strong> yaz\u0131yoruz sonra kodu yaz\u0131yoruz gibi bir alg\u0131 var. Asl\u0131nda buras\u0131 genel olarak senkron giden bir s\u00fcre\u00e7. Testi kod ile birlikte yaz\u0131yorsan\u0131z, \u201ctest g\u00fcd\u00fcml\u00fc geli\u015ftirme\u201d yap\u0131yorsunuz demektir. Burada \u00f6nemli olan geli\u015ftirme hayat\u0131n\u0131z\u0131n merkezine testi almak.<\/p>\n\n\n\n
Umar\u0131m test yazmak isteyenler i\u00e7in g\u00fczel bir ba\u015flang\u0131\u00e7 yapabilmelerine yard\u0131mc\u0131 olmu\u015fumdur. Sorular\u0131n\u0131z\u0131 her zaman bana \u00e7e\u015fitli mecralar \u00fczerinden (X, email vd.) \u00e7ekinmeden iletebilirsiniz. Bir soru sorabilir miyim harici t\u00fcm sorulara kap\u0131m a\u00e7\u0131k :)<\/p>\n","protected":false},"excerpt":{"rendered":"
Test yazmak \u00e7o\u011fu yaz\u0131l\u0131mc\u0131 ve asl\u0131nda dolayl\u0131 olarak \u015firketler i\u00e7in b\u00fcy\u00fck bir tabu. Bunun \u00e7ok\u00e7a sebebi var ama bug\u00fcn yaz\u0131l\u0131mc\u0131lar taraf\u0131nda \u00f6n plana \u00e7\u0131kan bir konuyu inceleyece\u011fim. \u201cTest yazmak istiyorum ama ne yazaca\u011f\u0131m\u0131 bilmiyorum\u201d Bu konuyu s\u0131kl\u0131kla duyar\u0131z \u00e7\u00fcnk\u00fc ger\u00e7ekten ilk kez test yazmaya ba\u015flayan insanlar ne yazaca\u011f\u0131n\u0131 bilemiyor. Ben de bilmiyordum. Bu konuda herkes […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[4],"tags":[389],"class_list":["post-2544","post","type-post","status-publish","format-standard","hentry","category-yazilim","tag-testing"],"blocksy_meta":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack-related-posts":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/posts\/2544","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/comments?post=2544"}],"version-history":[{"count":2,"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/posts\/2544\/revisions"}],"predecessor-version":[{"id":2546,"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/posts\/2544\/revisions\/2546"}],"wp:attachment":[{"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/media?parent=2544"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/categories?post=2544"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/guven.atbakan.com\/blog\/wp-json\/wp\/v2\/tags?post=2544"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}