> For the complete documentation index, see [llms.txt](https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_83.md). # Test, Yazılım Geliştirmenin Mühendislik Zorluğudur Geliştiriciler, aile üyelerine, eşlere ve diğer teknik olmayanlara ne yaptıklarını açıklamaya çalışırken işkence görmüş metaforları kullanmayı severler. Sıklıkla köprü inşasına ve diğer "zor" mühendislik disiplinlerine başvururuz. Tüm bu metaforlar, onları çok fazla zorlamaya başladığınızda hızla düşüyor. Yazılım geliştirmenin birçok önemli yönden "zor" mühendislik disiplinlerinin çoğu gibi *olmadığı* ortaya çıktı. "Zor" mühendislikle karşılaştırıldığında, yazılım geliştirme dünyası, ortak stratejinin bir köprü inşa etmek ve ardından üzerinde ağır bir şey yuvarlamak olduğu zamanki köprü inşaatçılarının bulunduğu yerdedir. Kalırsa, iyi bir köprüydü. Değilse, çizim tahtasına geri dönme zamanı. Son birkaç bin yılda mühendisler, ne yaptığını görmek için inşa etmek zorunda kalmadan yapısal bir çözüm için kullanabilecekleri matematik ve fizik geliştirdiler. Yazılımda böyle bir şeye sahip değiliz ve belki de asla olmayacak çünkü yazılım aslında çok farklı. Yazılım "mühendisliği" ile normal mühendislik arasındaki karşılaştırmanın derinlemesine bir incelemesi için, ["Yazılım Tasarımı Nedir?"](http://www.developerdotstar.com/mag/articles/reeves_design.html), Jack tarafından yazılmıştır. 1992'de *C++ Journal*'da yayınlanan Reeves, bir klasiktir. Neredeyse yirmi yıl önce yazılmış olmasına rağmen, yine de dikkate değer ölçüde doğrudur. Bu karşılaştırmada kasvetli bir tablo çizdi, ancak 1992'de eksik olan şey, yazılım için güçlü bir test etme anlayışıydı. "Zor" şeyleri test etmek zordur çünkü onları test etmek için inşa etmeniz gerekir, bu da sadece ne olacağını görmek için spekülatif yapıyı caydırır. Ancak yazılımdaki yapım süreci gülünç derecede ucuzdur. Bunu yapmayı kolaylaştıran eksiksiz bir araçlar ekosistemi geliştirdik: birim testi, sahte nesneler, test koşum takımları ve daha birçok şey. Diğer mühendisler, bir şeyler inşa etmeyi ve gerçekçi koşullar altında test etmeyi çok isterdi. Yazılım geliştiricileri olarak, yazılımın birincil (ancak tek değil) doğrulama mekanizması olarak testi benimsememiz gerekir. Yazılım için bir tür hesap beklemek yerine, iyi mühendislik uygulamalarını sağlamak için zaten elimizde araçlar var. Bu açıdan bakıldığında, "Test için zamanımız yok" diyen yöneticilere karşı artık mühimmatımız var. Bir köprü inşaatçısı patronundan asla "O bina üzerinde yapısal analiz yapmakla uğraşmayın - son teslim tarihimiz kısıtlı" diye bir şey duymaz. Testin gerçekten de yazılımda tekrarlanabilirlik ve kaliteye giden yol olduğunun kabul edilmesi, geliştiriciler olarak bize, profesyonel olarak sorumsuz olduğu için buna karşı çıkan argümanları geri itmemize izin veriyor. Yapısal analizin zaman alması gibi, test etme de zaman alır. Her iki faaliyet de nihai ürünün kalitesini garanti eder. Yazılım geliştiricilerin ürettikleri şeyin sorumluluğunu üstlenmelerinin zamanı geldi. Tek başına test etmek yeterli değildir, ancak gereklidir. \* **Test etme** \* yazılım geliştirmenin mühendislik titizliğidir. [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford) Tarafından --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_83.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.