Specs ve ScalaTest, mutlu kullanıcılar için iyi araçlardır, ancak birkaç yönden farklılık gösterirler. Muhtemelen Scala'da ana test aracınız olarak birini seçmek isteyeceksiniz, ancak diğerinden vazgeçmenize gerek yok çünkü her ikisinin de parçalarını kullanabilirsiniz. Eğer ScalaTest en gibi FeatureSpecsözdizimi ve özellikleri mockito sözdizimi, örneğin, size sınıf yolunda hem kavanoz dosyalarını koyabilirsiniz ve ikisini aynı anda kullanın. Burada, özellikler ve ScalaTest arasında fark ettiğim ana tasarım felsefesi farklılıklarını yakalamaya çalışacağım.
Muhtemelen araçlar arasındaki temel felsefi fark, özelliklerin Davranış Odaklı Geliştirme (BDD) için tasarlanmış olması, ScalaTest'in ise daha genel olmasıdır. ScalaTest, BDD dahil olmak üzere test sınıflarınızda tercih ettiğiniz davranışı elde etmek için bir araya getirebileceğiniz özellikler sağlar ve farklı bir şey istiyorsanız kendi davranışınızı da kolayca tanımlayabilirsiniz.
Aracılığıyla ScalaTest destekler BDD onun Spec, FeatureSpec, WordSpec, FlatSpec, ve GivenWhenThenözellikleri, hem de güzel bir eşleştirici sözdizimi almak için karışabileceğiyle özellikleri vardır. Eğer "should" ı seviyorsanız, ShouldMatchers ile karıştırın. Eğer "olmazsa olmaz" ı seviyorsan, karışırsın MustMatchers. Ancak BDD'yi seviyorsanız ancak eşleştirici sözdizimini sevmiyorsanız, bir eşleştirici özelliğinde karıştırmadan ScalaTest'in Spec özelliklerinden birini kullanabilirsiniz. Specs, genişlettiğiniz bir Specification sınıfına sahiptir ve eşleştirici ifadelerinizde "must" kelimesini kullanmanız gerekir. Burada belirgin olan büyük bir felsefi fark, ScalaTest'in size çok daha fazla seçenek sunmasıdır. Bu seçim alanında gezinmeyi kolaylaştırmak için burada bir karar ağacı sunuyorum:
http://www.scalatest.org/quick_start
Eşleştirici sözdizimi, ScalaTest ve özellikler arasında da farklıdır. ScalaTest'te operatör notasyonu ile ne kadar ileri gidebileceğimi görmeye çalıştım ve sonunda kelimeler arasında boşluklar bulunan, İngilizce cümleler gibi okunan eşleştirme ifadeleri buldum. Specs matcher sözdizimi, deve durumuyla birlikte kelimeleri daha çok çalıştırır.
Spesifikasyonların ScalaTest'ten daha fazla eşleştiricisi var ve bence tasarım tutumundaki farklılığı yansıtıyor. Aslında oluşturduğum ve yayınlanması için düşündüğüm eşleştirici sözdiziminin muhtemelen 2 / 3'ünü kestim. Gelecek sürümlerde daha fazla eşleştirici ekleyeceğim, ancak kullanıcıların eklemeden önce gerçekten bir şey istediklerini bildiğimden emin olmak istedim. Ancak ScalaTest'in eşleyicileri dinamik bir özellik eşleştirici sözdizimi içerir, bu boşluğun bir kısmını alır. Örneğin, Teknik Özellikler'de aşağıdakilere yazabilirsiniz java.io.File:
file must beDirectory
Bu, çağırır isDirectoryve doğru olduğundan emin olur. ScalaTest'in java.io.Filesşu an için herhangi bir özel eşleştiricisi yoktur , ancak ScalaTest'te aşağıdaki gibi dinamik bir kontrol kullanabilirsiniz:
file must be a ('directory)
Daha sonra bir sembolü her ilettiğinizde be, adlandırılmış bir yöntemi veya alanı directoryveya adlandırılmış bir yöntemi (bu durumda) aramak için yansımayı kullanır isDirectory. Bir de tanımlayarak bunu statik yapmanın bir yolu vardır BePropertyMatcher(genellikle sadece 2 veya 3 satır kod gerektirir). Temel olarak ScalaTest'te daha az API ile daha fazla işlevsellik sağlamaya çalışıyorum.
Spesifikasyonlar ve ScalaTest arasındaki diğer bir genel tasarım tutumu farkı, örtük dönüştürmeleri içerir. Varsayılan olarak, ===operatörü her şeye koyan ScalaTest'i kullandığınızda yalnızca bir örtük dönüşüm elde edersiniz . (Gerekirse, bu örtük dönüşümü bir satır kodla "kapatabilirsiniz". Bunu yapmanızın tek nedeni, kendi ===operatörü olan bir şeyi test etmeye çalışıyor olmanız ve bir çelişki ile karşılaşmanızdır. ) ScalaTest, diğer birçok örtük dönüştürmeyi tanımlar, ancak bunları kullanmak için, bir özelliği karıştırarak veya içe aktararak bunları açıkça kodunuza "davet etmeniz" gerekir. Sınıfı uzattığın zamanSpecificationSpesifikasyonlarda, varsayılan olarak düzinelerce örtük dönüşüm elde ettiğinizi düşünüyorum. Bunun pratikte ne kadar önemli olacağından emin değilim, ancak insanların kendi çıkarımlarını kullanan bir kodu test etmek isteyeceklerini ve bazen test çerçevesinin sonuçları ile üretim kodunun sonuçları arasında bir çatışma olabileceğini düşünüyorum. Bu olduğunda, ScalaTest'teki sorunu çözmek teknik özelliklerden daha kolay olabilir.
Tasarım tutumunda fark ettiğim bir diğer fark, operatörlerle rahatlıktır. Amacım, ScalaTest'i kullanan bir başkasının test koduna bakan herhangi bir programcının, ScalaTest belgelerine bakmadan anlamın ne olduğunu tahmin edebilmesiydi. ScalaTest istemci kodunun açıkça belli olmasını istedim. Hedefin kendini göstermesinin bir yolu, ScalaTest'in operatörler konusunda oldukça muhafazakar olmasıdır. ScalaTest'te yalnızca beş operatör tanımlıyorum:
===yani eşittir>, bu daha büyük anlamına gelir<, daha az>=, büyüktür veya eşittir<=, az veya eşit.
Bu kadar. Yani bu şeyler hemen hemen ne anlama geliyor gibi görünüyor. Başka birinin kodunda görüyorsanız:
result should be <= 7
Umudum, bunun ne anlama geldiğini tahmin etmek için API belgelerine gitmenize gerek olmamasıdır <=. Aksine, teknik özellikler operatörler için çok daha özgürdür. Bunda yanlış bir şey yok, ama bu bir fark. Operatörler kod daha özlü yapabilirsiniz, ancak takas gibi şeyler bulduğunda belgelere çalıştırmak gerekebilir olduğunu ->-, >>, |, |>, !, veya ^^^iş arkadaşınızın testi kodunda (tümü Özellikleri özel anlamları olan olan).
Diğer bir felsefi fark ise, ScalaTest'te bir fikstürü paylaşmanız gerektiğinde işlevsel bir stil kullanmayı biraz daha kolaylaştırmaya çalışmam ve Specs varsayılan olarak JUnit tarafından popüler hale getirilen setUpve tearDowndeğişkenleri yeniden atadığınız yaklaşım geleneğini sürdürmesidir. her testten önce. Ancak bu şekilde test etmek istiyorsanız, ScalaTest'te de çok kolaydır. Sadece BeforeAndAfterözelliği karıştırmanız gerekiyor .
ScalaTest hakkında daha fazla bilgi için, 2009 Devoxx konferansında verdiğim "ScalaTest ile Daha Yükseklere Geçin" sunumunu buradan izleyebilirsiniz:
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about