Skip to content

Conversation

@JonaMX
Copy link

@JonaMX JonaMX commented Sep 27, 2016

I had to run some A/B testing on my project sending some emails at specific time and others at a specific interval, but then I ran into the issue of how to test this behavior on my specs, that's why I've created a new matcher at_or_in to test against both options either enqueue_at or enqueue_in method

let(:scheduled_at) { Time.now + 30 * 60 }

before(:each) do
if [true, false].sample
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @JonaMX,

Thanks for the PR. Using sample in a spec is problematic as the spec is not deterministic from run to run. One alternative would be to extract the two examples into a shared group. Then run the shared group with enqueue_at and enqueue_in.

@leshill
Copy link
Owner

leshill commented Sep 29, 2016

Hi @JonaMX,

Made a comment on one of the files, but am wondering if this is a case of dropping down to more specific examples? The code under test must be choosing between enqueue_at and enqueue_in, is it not possible to write an example that is specific enough to set the appropriate expectation?

@JonaMX
Copy link
Author

JonaMX commented Oct 24, 2016

Hi @leshill thanks for the feedback, I attended your comments.

@leshill
Copy link
Owner

leshill commented Oct 25, 2016

Hi @JonaMX,

Thanks for updating the spec.

On a similar note, instead of creating a new matcher, perhaps the same can be done in your app’s specs?

For example, if the decision on whether to enqueue_at or enqueue_in depends on the first job parameter, then there would be two specs with a different first parameter, each expecting the appropriate enqueue method.

Does that make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants