RSpec vs Test :: Raylardaki Ünite

Ruby on Rails'deki Test :: Unit'ten RSpec'e geçiş yaparak elde ettiğiniz avantajlardan gerçekten ikna olmadım (RSpec hakkında zaman zaman okumaya rağmen).

Çoğu Rails projesinin bunu kullanıyor gibi görünen RSpec ile ilgili ne var?

(birinin diğerine göre avantajlarını açıkça gösteren bazı kod örnekleri çok takdir edilecektir)

Bu büyük ölçüde bir zevk meselesidir ve tuz testlerine değer test araçlarının çoğu. Kişisel tercihim Test :: Unit üzerinden RSpec için çünkü a) testlerin çıktısı ve düzeni, test edilen nesnenin ne yapması gerektiğine odaklanır (kodun aksine) ve b) 'X Y olmalı' bana 'X'in Y'yi önermiş olduğunu iddia etmekten' daha mantıklı geliyor.

Yukarıdaki noktalar için size bir bağlam vermek için, burada RSpec kullanılarak, diğeri de Test :: Unit kullanılarak yazılmış iki işlevsel olarak eşdeğer birim testinin çıktı / kaynak kodunun karşılaştırması (oldukça tutarlı).

Test edilen kod

class DeadError < StandardError; end

class Dog
  def bark
    raise DeadError.new "Can't bark when dead" if @dead
    "woof"
  end

  def die
    @dead = true
  end
end

Testi :: Birimi

 require 'test/unit'
  require 'dog'

  class DogTest < Test::Unit::TestCase
    def setup
      @dog = Dog.new
    end

    def test_barks
      assert_equal "woof", @dog.bark    
    end

    def test_doesnt_bark_when_dead
      @dog.die
      assert_raises DeadError do
        @dog.bark
      end
    end
  end

RSpec

require 'rspec'
require 'dog'

describe Dog do
  before(:all) do
    @dog = Dog.new
  end

  context "when alive" do
    it "barks" do
      @dog.bark.should == "woof"
    end
  end

  context "when dead" do
    before do
      @dog.die
    end

    it "raises an error when asked to bark" do
      lambda { @dog.bark }.should raise_error(DeadError)
    end
  end
end

Test :: Ünite çıkışı (yapabildiğim kadar dolu)

Ξ code/examples → ruby dog_test.rb --verbose
Loaded suite dog_test
Started
test_barks(DogTest): .
test_doesnt_bark_when_dead(DogTest): .

Finished in 0.004937 seconds.

RSpec çıkışı (belge biçimlendirici)

Ξ code/examples → rspec -fd dog_spec.rb 

Dog
  when alive
    barks
  when dead
    raises an error when asked to bark

Finished in 0.00224 seconds
2 examples, 0 failures

2 tests, 2 assertions, 0 failures, 0 errors

PS Bence Berin (önceki yanıtlayan) Salatalık (RSpec projesinden çıkıp bağımsız olan) ve RSpec'in rollerini karıştırıyor. Salatalık, BDD tarzında otomatik kabul testi için bir araçtır, RSpec ise test için birim, entegrasyon ve fonksiyonel seviyelerde kullanılabilen ve kullanılabilen bir kod kütüphanesidir. Bu nedenle RSpec kullanmak ünite testini engellemez - sadece ünite testlerinize 'özellikler' adını vermeniz yeterlidir.

Son zamanlarda, Salatalık Rails topluluğunda daha fazla destek alıyor gibi görünüyor. İşte RSpec'in öncülüğüyle (eski bir Ruby on Rails Podcast'tan) yapılan bir röportajdan duyduğum kısaca tartışma.

Çevik toplulukta (o sırada), bir şeyi değiştirmek zorunda olduğunuzu kanıtlamak için önce teste önem vererek Test Odaklı Gelişim için büyük bir baskı vardı. Bunda felsefi olarak yanlış bir şey vardı. Özünde, test, uygulamanızın doğru olduğunu doğrulamanın bir yoludur, bu nedenle sürüş tasarımı hakkında nasıl farklı düşünüyorsunuz? RSpec'in öncülü ilk önce belirttiğinizi tahmin etti ve şartname uygulamanızın sonuçlarını da kontrol ettiyse harika olmaz mıydı?

Basit yeniden adlandırma assert, shouldspesifikasyonları yazmak ve tasarımı düşünmek için zihni doğru şekilde odaklamaya yardımcı olur. Ancak, bu denklemin sadece bir parçası.

Daha da önemlisi, birçok TDD beleisti testlerin tasarımı belgelediğini iddia ettiğinden, çoğu dokümantasyon en iyi ihtimalle zayıftı. Testler, dili bilmeyen geliştirici olmayanlar için oldukça opaktır. O zaman bile, tasarım çoğu testi okumaktan hemen belli değil.

Dolayısıyla ikincil bir hedef olarak, RSpec şartnamelerden yazılı dokümantasyon üretmenin bir yolunu tasarladı. RSpec'e bir uygulamanın tasarımını yönlendirmek için basit Test :: Unit'e üstünlük sağlayan bu yazılı şartnamedir. Tasarım tutarlılığını aynı anda belgeleyip doğrulayabildiğinizde neden birden fazla şey yazmalısınız?

Anladığım kadarıyla, daha sonra gelip RSpec'ten ders öğrenmenin faydası olan Salatalık, birincil hedefi kaybetmeden (uygulamayı şartnameden test etme yeteneği) bu ikincil hedefte daha iyi bir iş çıkarıyor. Salatalık bunu, programcı olmayanların makul bir şekilde yapabileceği oldukça İngilizce benzeri bir API ile yapar. Yeni doğrulama yöntemlerinin bazı tanımlarını doldurmak için programcılardan biraz yardıma ihtiyaçları olabilir, ancak genişletilebilir olarak tasarlanmıştır.

Sonuç olarak, RSpec / Salatalık birim testini tamamen değiştirmemelidir. Tasarımınızı belgelemek ve doğrulamak için daha uygun olabilirler - ancak yine de yapılması gereken birkaç uygulama testi vardır, özellikle uygulamanın tasarımından değil, uygulamadan kaynaklanan ince hatalarla. Yine de yazmanız gereken test sayısını azaltır.