Error types
Bu bölümün tüm kodlarını burada bulabilirsiniz
Kendi hata tiplerinizi oluşturmak kodunuzu düzenlemenin zarif bir yolunu oluşturabilir, kodunuzu kullanmayı ve test etmeyi daha kolay hale getirebilir.
Gopher Slack'ten Pedro soruyor:
Eğer
fmt.Errorf("%s must be foo, got %s", bar, baz)
gibi bir hata oluşturursam, string değerlerini karşılaştırmadan eşitliği test etmenin bir yolu var mı?
Bu fikri keşfetmeye yardımcı bir fonksiyon oluşturalım:
Farklı nedenlerle başarısız olabilecek bir fonksiyon yazmak nadir bir durum değildir ve her senaryoyu doğru şekilde ele aldığımızdan emin olmak istiyoruz.
Pedro'nun dediği gibi, durum hatası için şu şekilde bir test yazabiliriz:
Bu test her zaman StatusTeapot
döndüren bir sunucu oluşturur ve ardından DumbGetter
URL'sini argüman olarak kullanırız. Böylece 200
olmayan yanıtları doğru şekilde işlediğini görebiliriz.
Bu test etme yönteminin sorunları
Bu kitap, testlerinizi dinleyin'i vurgulamaya çalışıyor ve bu test iyi hissettirmiyor:
Bunu test etmek için, üretim kodunun yaptığı gibi aynı string'i oluşturuyoruz.
Bu okumak ve yazmak için rahatsız edici.
Tam hata mesajı string'i, aslında ilgilendiğimiz şey mi?
Bu bize ne anlatıyor? Testimizin ergonomisi, kodumuzu kullanmaya çalışan başka bir kod parçasına yansıyacaktır.
Kodumuzun kullanıcısı, döndürdüğümüz belirli hata türlerine nasıl tepki veriyor? Yapabilecekleri en iyi şey, son derece hataya meyilli ve yazması korkunç olan hata mesajına bakmak.
Ne yapmalıyız
TDD ile aşağıdaki düşünce yapısına girmenin faydasına sahip oluruz:
Ben bu kodu nasıl kullanmak isterdim?
DumbGetter
için yapabileceğimiz şey, kullanıcıların tip sistemini kullanarak ne tür bir hata oluştuğunu anlamaları için bir yol sağlamaktır.
Peki DumbGetter
bize, aşağıdakilere benzer bir şey döndürebilse:
Büyülü bir string yerine, çalışmak için gerçek verilere sahibiz.
Mevcut testimizi bu ihtiyacı karşılayacak şekilde değiştirelim:
BadStatusError
hata arabirimi uygulayacak şekilde değiştirmemiz gerekecek:
Test ne yapar?
Tam hata string'ini kontrol etmek yerine hatanın bir BadStatusError
olup olmadığını görmek için bir tür belirtimi (type assertion) yapıyoruz. Belirtimin geçtiğini varsayarak, hatanın özelliklerinin doğru olduğunu kontrol edebiliriz.
Testi çalıştırdığımızda, bize doğru türde hata döndürmediğimizi söylüyor:
Hata işleme kodumuzu kendi türümüzle güncelleyerek DumbGetter
'ı düzeltelim:
Bu değişiklik bazı gerçek olumlu etkiler yarattı:
DumbGetter
işlevimiz daha basit hale geldi, artık bir hata string'inin incelikleri ile ilgilenmiyor, sadece birBadStatusError
oluşturuyor.Testlerimiz artık kodumuzun kullanıcısının, yalnızca günlüğe kaydetme dışında daha karmaşık hata işleme yapmaya karar vermesi durumunda neler yapabileceğini yansıtıyor (ve belgeliyor). Sadece bir tür onayı yapın ve ardından hatanın özelliklerine kolayca erişin.
Bu halen "sadece" bir
error
olduğu için, istediklerinde bunu call stack'e geçirebilirler veya diğererror
'lar gibi kaydedebilirler."
Özetlersek
Eğer kendinizi birçok hata durumunu test ederken bulursanız, hata mesajlarını karşılaştırma tuzağına düşmeyin.
Bu, istikrarsız ve okuması/yazması zor testlere yol açar ve kodunuzu kullananların, meydana gelen hataların türüne bağlı olarak işleri farklı şekilde yapmaya başlamaları gerektiğinde karşılaşacakları zorlukları yansıtır.
Testlerinizin her zaman kodunuzu nasıl kullanmak istediğinizi yansıttığından emin olun. Bu nedenle, kendi hata türlerinizi özetlemek için hata türleri oluşturmayı düşünün. Bu, kodunuzu kullanan kullanıcılar için farklı türde hataların ele alınmasını kolaylaştırır ve aynı zamanda hata işleme kodu yazmayı daha basit ve okunması kolay hale getirir.
## Ek Bilgi
Go 1.13'ten itibaren, Go Blog'da standart kütüphanede hatalarla çalışmanın yeni yolları ele alınmaktadır.
Bu durumda, hatayı denemek ve çıkarmak için errors.As
kullanıyoruz ve hatamızı custom type'ımıza çıkarıyoruz. Bu, başarı durumunu temsil etmek için bir bool
döndürür ve bizim için got
içine çıkartır.
Bu sayfa @rasimthegrey tarafından çevrildi.
Last updated