Tag: testing

Paperclip and Rspec: Stubbing Paperclip/ImageMagick to make specs run faster, but with image resolution validation

I always test my Paperclip stuff. Mostly because quite often, I need to ensure proper images resolution or other image-based conditions. Unfortunately, it takes some time, mostly because ImageMagick is performing resource consuming operations. Each resolution test needs to get valid image to determine width and height. After that, Paperclip will try to create all the thumbs and save them. This takes a lot of time! Luckily there's a Quickerclip that stubs Paperclip methods, allowing it to run faster. There's one small issue with this code: it stubs the image, so there's no way to test resolution validations. In order to make it work, but without any additional callbacks and without images converting, we need to stub two things:

First the Paperclip.run method:

# We stub some Paperclip methods - so it won't call shell slow commands
# This allows us to speedup paperclip tests 3-5x times.
module Paperclip
  def self.run cmd, params = "", expected_outcodes = 0
    cmd == 'convert' ? nil : super
  end
end

This will ignore convert command, so thumbnails won't be created on save.

Also we need to stub the Paperclip::Attachment.post_process:

class Paperclip::Attachment
  def post_process
  end
end

Don't forget to add this to your spec_helper or test_helper file!

After that, your tests/specs should run 3-5x times faster (it depends on how heavily you app is Paperclip based.

UPDATE FOR PAPERCLIP > 3.5.2
For Paperclip newer than 3.5.2 please use code presented below:

module Paperclip
  def self.run cmd, arguments = "", interpolation_values = {}, local_options = {}
    cmd == 'convert' ? nil : super
  end
end

class Paperclip::Attachment
  def post_process
  end
end

Błąd “Errno::EMFILE: Too many open files” w testach jednostkowych

Dzisiaj pisząc kolejną porcję testów do Senpuu v5, po odpaleniu ich pod RCovem i Rubym 1.8.7 napotkałem na taki oto błąd:

Errno::EMFILE: Too many open files

Błąd ten związany jest z ilością otwartych jednocześnie plików (co ciekawe nie wystąpił podczas odpalania testów pod 1.9.2). Okazuje się, że tego typu wywołania:

file = File.new(File.join(Rails.root, "sciezka/do/pliku"), 'rb')

nie są nigdy zamykane, więc otwierając przykładowo 100 plików, żaden z nich nigdy nie zostanie zamknięty (przy zamykaniu aplikacji zostana). Z czasem ilość otwartych plików narasta i po pewnym czasie następuje zgłoszenie wyżej wspomnianego wyjątku. Rozwiązanie jest nader proste: zamykajmy otwierane pliki :)

W przypadku aplikacji jest to dość proste (robimy coś na pliku, kończymy i zamykamy). Jak jednak zapanować nad otwartymi plikami w testach? Przyznam szczerze, że jestem zbyt dużym leniem aby pamiętać o zamykaniu każdego pliku otworzonego w każdym teście. Z tego względu warto zbudować sobie prosty garbage collector który zajmie się tym za nas. Jak to zrobić pokaże na przykładzie podpięcia takiego kodu pod ActiveSupport::TestCase. Nic nie stoi na przeszkodzie aby tę metodę stosować także dla innych frameworków jak np. RSpec.

W metodze setup deklarujemy zmienną instancyjną, która przechowywać będzie nasze otwarte pliki:

  def setup
    super
    # Jakis inny kod ...
    @opened_files = []
  end

W metodzie teardown zamykamy wszystko:

  def teardown
    super
    # Jakis inny kod
    @opened_files.each { |f| f.close }
  end

I ostatnia z metod - metoda otwierająca pliki i zapamiętująca je w naszej zmiennej:

  def open_file(file = nil)
    return nil if filename.nil?
    file = File.new(File.join(Rails.root, file), 'rb')
    @opened_files << file
    file
  end

Od teraz, korzystając z metody open_file nie musimy się martwić otwartymi plikami. Zostaną automatycznie zamknięte podczas wywołania metody teardown.

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑