Bakar mısınız? Önden bir test söylemiştik ama…

Fotoğraf, Fabrizio Magoni tarafından çekilmiş, Unsplash’den indirilmiştir.

Test-Driven Development

Önce testi yaz, sonra fonksiyonu! yaklaşımı, işin en başından beri bana hep zor ve imkansız geldi. Düşünsenize, ortada bir fonksiyon yok ve siz olmayan bir fonksiyonu, olmayan parametrelerle çağırıyorsunuz; olmayan çıktıyı, olmayan bir sonuçla test ediyorsunuz. Bu imkansızlık senaryosu, yukarıda alıntıladığım cümleciği okuyana kadar geçerliydi ve oldukça zorlandım, açıkça itiraf etmek gerek. Sonra şunu farkettim:

Hadi şimdi gel de bunun testini yaz!?!

Yine içgüdüsel olarak fonksiyonun patlamaması için case’ler hazırladınız, değil mi? 48. satırda null kontrolü yapmışım, dur bir null geçeyim parametreyi, bakalım patlayacak mı?

Test yönelimli geliştirseydim, nasıl olurdu?

Şu alıntıya tekrar dönelim mi? Diyor ki “davranışlar”. Eğer önce kodu yazmak yerine davranışı düşünseydim içimden şöyle bir cümle kurardım:

“Behind the Scenes”

Bu işin bir de kamera arkası var tabii. Bu işin arkasında “red — green — refactor” denilen teknik var. Kısaca şöyle özetlemek gerekirse;

  • (RED) Olmayan sınıfın instance’ını oluştur — 26. satır —
  • (RED) Olmayan sınıfın olmayan fonksiyonunu çağır — 27. satır —
  • (RED) Olmayan fonksiyonun olmayan geri dönüş değerini teste tabi tut — 28. satır —
  • Build hatalarını düzelt — olmayan sınıf ve fonksiyonları oluştur — ve ilk RED aşamasını tamamla.
  • (RED) Testleri çalıştır ve fail olmalarını izle!
  • (GREEN) Fonksiyona dön ve beklediğin değeri hard-coded olarak geri döndür. Tebrikler! Artık artık testlerin başarıyla geçiyor.
  • (REFACTOR) Şimdi tekrar fonksiyona dön ve kurguladığın algoritmalar ile fonksiyonunu refactor et.

“Director’s Cut”

Yukarıdaki örnek bir .NET Framework örneğiydi. .NET Core bu konuda sizi “doğruya yönlendirmek” adına tabiri caizse sürüklüyor. Örneğin, fonksiyonlarınız içerisinde HttpContext diye bir sınıf kullanamıyorsunuz, çünkü yok. IHttpContextAccessor sınıfından türeyen HttpContextAccessor sınıfına ihtiyacınız var, bunu da mecburen DI ile ilgili sınıfa iletmeniz gerekiyor; gibi gibi senaryolar ile size yardımcı oluyor.

Sonuç

Yazılım geliştirme alışkanlıklarımızı değiştirmek oldukça güç ama unutmayın ki bu alışkanlığı da “edindiniz” ve yeni bir alışkanlıkla değiştirmemeniz için hiçbir neden yok. Üstelik daha değerli ve yararlı bir yöntem olduğunu bilmeniz motivasyon konusunda size yardımcı olacaktır. Değişim sürecine girmeye karar verirseniz, şimdiden başarılar! Bir sonraki yazıya dek, aperitifleriniz bol olsun — buraya kebapçı reklamı alınacaktır — :)

--

--

Engineering Manager (at) Hepsiburada. Former trainer & consultant. Tweets are mostly about tech and coding. https://superpeer.com/selcukusta

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Selçuk Usta

Selçuk Usta

Engineering Manager (at) Hepsiburada. Former trainer & consultant. Tweets are mostly about tech and coding. https://superpeer.com/selcukusta