-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing strategies? #45
Comments
@bokmann Yeah, basically. For example, in one app this code: def foobar(id)
Propono.publish(:videos, { entity: "video", action: "processed", video_id: id})
end might get tested in rspec with: Propono::Publisher.expects(:publish).with(:videos, { entity: "video", action: "processed", video_id: "123" } )
foobar(123) If you don't know a param in advance (e.g. if you're testing a callback), it gets slightly trickier. For example, we test this extract: class KnowledgeBank::QuestionCreator
#...
def create
@question = @user.knowledge_bank_questions.create(@params)
message = { entity: "question", action: "created", question_id: @question.id}
Propono.publish(:knowledge_bank, message)
end
end with this: let(:user) {create :user}
let(:title) {"Foobar"}
it "should publish to Propono" do
Propono::Publisher.should_receive(:publish).once.with do |topic, payload, options|
question = KnowledgeBank::Question.last
topic == 'knowledge_bank' &&
payload == { entity: "question", action: "created", question_id: question.id} &&
options == {}
end
KnowledgeBank::QuestionCreator.create!(user, title: title, content: content)
end That make sense? |
And yeah, the listener is similar: From a project that uses minitest: topic = "my-topic"
queue_suffix = "_test"
queue_name = "#{topic}#{queue_suffix}"
id = "9"
message = { id: id, action: "send_email"}
Propono.expects(:listen_to_queue).with(queue_name).yields(message, {:id => "1234"}) |
Thanks for the feedback! I'm days away from using this for realz. I'd like to contribute something back to the readme once I work out the testing... I might even build some kind of capture for development, kinda like the letter_opener gem does for email. |
Hey @bokmann. Just wondering if you ever did get round to using this in production? :) |
Using the gem? kinda. Short story - using the acts_as_state_machine gem, we are running code triggered by the entry into a state. We know when we get volume on the site this will be a pain-point; the code runs within the rails request/response cycle as it stands currently. Ideally I want to change that so that entry into the state publishes an event, and a propano listener does something with it later. We haven't had the volume that makes us worry yet, so we haven't introduced this yet. The tests we wrote simple expect a Propano.publish; we haven't done anything to test receiving the events, and I haven't explored the 'capture' concept I was previously talking about. |
Thanks for the update. If you do start using it more fully and want to bounce any ideas or questions around, please let us know! |
Have you seen ActiveJob? https://github.com/rails/activejob This isn't quite a full job-queue implementation, but it would be an interesting piece of one... |
Hey @iHiD pretty cool gem, I'm wondering how you guys do tests around listeners, specifically in the callbacks. do you happen to have an example with rspec or another library? Thanks so much. |
This is likely addressed with a section in the readme, but what are some guidelines for testing without relying on a live SQS instance? Do you mock the Propano.publish and .listen_to_queue methods and check for the messages you expect?
The text was updated successfully, but these errors were encountered: