Birim testi ve alay

Question

"Ne zaman alay edileceğine" ilişkin pek çok soru var gibi görünüyor. Ama şu ana kadar soruma cevap alamadım. Olabilir, beni cevaba yönlendirecek belirli bir arama talebini bilmiyorum.

Bir sınıfımız olduğunu hayal edin (MyClass). Bu sınıfın hem std :: string hem de bir sarmalayıcı sınıf (başka bir kitaplıkta tanımlanmış MyStringWrapper) nesnesini döndürebilen yöntemlere sahip olduğunu düşünün. MyStringWrapper tam olarak toplayıcı değildir (burada struct kullanmayı düşünebiliriz, ancak bu belirli örnek için bir sınıf tercih edelim), çünkü onun ayarlayıcısının bir if ve birkaç kopyalama işlemi vardır. Şimdi, MyClass ve MyStringWrapper sınıfını kullanan 3. bir sınıf (UserClass) var.

İyi bir yazılım geliştiricisi olarak, Kullanıcı Sınıfımı birim test etmek istiyorum (çoğu "bir kodu koklamak" anlamına gelir). Birim testi için, MyClass'ın bir alayını oluşturmak için gtests ve gmock kullanırdım (buna MyClassMock diyelim). Ancak, bir yerlerde "başka bir kitaplıkta / 3. parti kitaplıkta tanımlanan her şeyle alay etmelisiniz" dendiğini hatırlıyorum. Hem std :: string hem de MyStringWrapper 3. parti kütüphanelerde tanımlanmıştır.

Şimdi soru. Öyleyse, bu durumda hem std :: string hem de MyStringWrapper için alaylar oluşturmalı mıyım?

Döndürülen std :: string / MyStringWrapper nesnesinin kullanımını şu şekilde hayal edebilirsiniz:

if(myreturnedstdstring.empty())
  return 1;

if(mywrapperobject.failed())
  return 100;

Burada yorumlarda bana soruldu. Her şeyi halka açıklayan ve alay eden birim testlerinin bir anlamı var mı?

başka bir konu oluştur.

Answer 1

Std :: içindeki herhangi bir şey dilin bir parçasıdır ve alay edilmemelidir. Dize sarmalayıcınız, test edilen "birimin" bir parçası değilse alay edilebilir ancak IMHO olabilir ve bunun gibi bir sarmalayıcı deneyimi o kadar hafiftir ki, taklit aslında kodu yeniden üretir. Bu durumda alay etmem. Bununla birlikte, paketleyici gelecekte değişebilirse, kararlı bir birim testi istiyorsanız, onunla dalga geçmelisiniz. Öte yandan, paketleyicide uyumsuz bir değişiklik yapıldığında bir testin başarısız olması iyi olur, ancak hata başka bir birimde olacağından izlenmesi daha zordur.

Answer 2

Bir yerde "başka bir kitaplıkta / 3. parti kitaplıkta tanımlanan her şeyle alay etmelisiniz" dendiğini hatırlıyorum.

Bir zamanlar bu tavsiye olabilir, ancak bugün genel olarak verilen tavsiye değildir.

Şu andaki tavsiye, birim testinin bu hedeflerine yardımcı olmak için az miktarda alay kullanmaktır:

• Testler hızlı, paralel veya herhangi bir sırada ve herhangi bir zamanda gerçekleştirilebilir. Bu, kalıcı depolama (veritabanları, dosya sistemleri), yavaş (ağ) bağlantılar veya kolayca kontrol edemediğiniz çevresel koşullar (örneğin, zaman) ile etkileşime giren bileşenlerin alay konusu olmaya aday olduğu anlamına gelir.
• Test edilen kod aracılığıyla tüm yollar kullanılabilir. Bir bağımlılıktan belirli bir (hata) yanıtı gerçek kodla kolayca tetiklenemezse, bu bağımlılıkla alay etmek için bir neden olabilir.

Dizeler, MyStringWrapper veya konteynerler gibi basit veri türleri bu noktalara uymadığından, onlarla dalga geçmek için bir neden yoktur.