Closed dpoetzsch closed 5 years ago
For what it's worth, there are other tools, like clockwork-test, that provide this functionality as well. Should clockwork provide information about all of them?
I certainly understand making it easy for people to surface and find information relevant to the gem. I just wouldn't want to overburden people with too much information, nor do I know if the maintainers of this repo want to have to stay up-to-date on the other tools out there for what to, or not to, recommend. I'll leave it up to the maintainers to decide.
Disclaimer: I'm the creator and maintainer of clockwork-test.
It's cool to see there are other people doing similar things and having similar needs though. I'll have to take a look at clockwork-mocks and see what I can learn from it. Congrats on shipping!
Ah, I did not know about clockwork-test, probably had the wrong google terms when looking for that. Thank's for showing it to me :) Maybe this makes the point clear why I'd suggest to add this section in the readme :)
From short scan over the library it seems very well suited for unit testing clockwork - far more improved than my gem. I'm not yet sure about integration testing - does it actually execute the tasks?
Concerning this PR: I don't care if in the end clockwork-test is the superior alternative that will be recommended, I just think having information on testing might help a lot of people and prevent people like me from re-implementing it ;-)
If I understand your question correctly, you can take a look at the block_for feature. You can find an example of calling block_for
in the README here. By default, the gem will not execute any code that should be invoked as a result of the scheduling (by design).
From the Usage section of the README:
a job running in Clockwork::Test will not actually execute its event's handler code. That is suppressed, but made available via the block_for method.
If you have any other questions or thoughts, feel free to use the issues list on that repo, or submit a PR if you find that there's functionality in clockwork-mocks that clockwork-test is missing.
Ok, this is what I understood. I guess we have different objectives with our libraries then: Yours seems to be mostly targeted for unit testing clockwork to check if certain tasks would be executed in certain intervals. Mine is targeted for integration testing where as much as possible should execute without being stubbed (I only stub external interfaces like third-party services).
I guess it is still possible to learn from each other and maybe even integrate with each other (maybe the integration feature could be merged into your gem for example). I will have a look at that.
Concerning this PR: I feel both functionality might be interesting to the user. What do the maintainers think about informing them?
I've added the two testing libraries, so: no jealous. Good for the two of you?
I like clockwork a lot. However, for our system, I felt the need to test it as a whole including scheduled jobs with clockwork.
So I created a small helper gem that provides a simple manual scheduler for clockwork which allows to do exactly that. Please check out the example section in the readme of the gem, it should make the use case clear.
Because I believe this could be of interest for other users of your gem I propose to add the possibility to you readme. What do you think?