Създаването на такъв тест не би трябвало да е голям проблем. Генерирайте 100 имейла с висок приоритет, след това 100 с нисък. Или обратното. Не започвайте работниците си, преди да сте проверили базата данни, за да видите, че всяка работа е там и е отчетена. Стартирайте вашите работници и наблюдавайте как се изпълняват задачите - и в правилния ред. Не забравяйте, че приоритетът в d_j е възходящ, така че приоритет 1 е по-висок от 10.

Сега 200 работни места не са много. Вашите работници вероятно ще ги екзекутират всички доста бързо. Ако наистина искате да проверите дали вашите имейли с нисък приоритет все още се изпращат, вероятно ще трябва да разчитате на това какво друго имате в опашката си - при условие, че използвате d_j за нещо повече от имейл. Бих посъветвал да попълните опашката с поне няколко хиляди работни места - или каквото можете да си представите като "най-лошия сценарий" - и да изпълните теста с това. Ако задачите, които не са свързани с имейл, имат по-висок приоритет от имейлите с нисък приоритет, е по-вероятно те да повлияят на доставката на имейли, отколкото 100-те такива с висок приоритет.

Ако се интересувате да разберете колко бързо тези имейли ще достигнат до реални получатели там, можете да направите само едно нещо: Изпратете тези имейли. Без действително преминаване през целия процес на доставка, няма абсолютно никакъв начин да се каже колко от тези имейли ще бъдат забавени поради сив списък, неправилно работещи MX, претоварени MX, повредени скенери за съдържание (или по-лошо, повредени скенери за съдържание в SMTP прокси режим), прекъсната интернет връзка на получаващите сървъри и т.н.

Всъщност внедрих теста, за да тествам обработката на DelayedJob при изпращане на имейли. Тестът всъщност е доста прост.

Трябва да поставите 2 задачи в опашка (вместо 100), една с висок приоритет и една с по-нисък приоритет. След това можете да използвате метода "Delayed::Job.work_off", за да изпълните първото задание, след което да потвърдите, че заданието с по-нисък приоритет все още е в чакащата база данни. Ако все още не сте сигурни как да изпълните задача, разгледайте библиотеката. Кодът е доста добре написан.

Ето извадката от кода от моето приложение. По принцип трябва да изпращам напомнящи имейли до потребителите, така че трябва да се уверя, че задачите се изпълняват правилно и мейлъра няма да избухне. Поставих този тест във файла за тестване на модула напомняне_test.rb, тъй като моделът Reminder знае всичко за това как да поставя в опашка и да изпраща имейли.

# enqueue the jobs here

assert_difference 'Delayed::Job.count', -1, 'Job should execute successfully' do
  assert_difference 'ActionMailer::Base.deliveries.count' do
    Delayed::Job.work_off
  end 
end

# make sure the email was properly delivered
email = ActionMailer::Base.deliveries.last
assert_equal email.to[0], @user.email
assert (Time.now - @reminder.reload.sent_at) < 1.seconds

наздраве! Надявам се това да помогне

Алекс