Support unit testing Perform funcs which push jobs

[mperham]

See #51 for details. WDYT?

[bploetz]

@mperham I'll have to pull this down and try it for real, but this looks like it solves the problem nicely! 👍

[mperham]

If you can think of a clean way to trigger Push() errors, that might be a nice addition to this better testing support.

[bploetz]

@mperham could you simply add an additional argument to the ExecuteWithResult function:

func (tp *testExecutor) ExecuteWithResult(specjob *faktory.Job, p Perform, simulatePushError bool) (ExecuteResult, error) 

Then pass the simulatePushError flag down to the internal methods accordingly, and if it's set to true have Push return an error.

[bploetz]

@mperham do you have any plans to release something like this to support testing jobs that enqueue other jobs? Since you suggested using helper.With() to push jobs within jobs, I'm now back to this original problem where I can't test doing it that way.

[mperham]

I add features based on demand these days. If no one asks for it, I don't add it. Send a PR if you have an initial spike we can collaborate on.

[bploetz]

Isn't this PR an initial spike?

[mperham]

Sorry, didn’t notice the context, just replying on my phone.

…

On Fri, Oct 28, 2022, at 11:15, Brian Ploetz wrote: Isn't this PR an initial spike? — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAWX54EWFTCH2E5BP5NEDWFQJ4TANCNFSM4VZQ2CRQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mperham]

Instead of creating a separate type which doesn't implement much of the interface, maybe use the standard jobHelper type with a swappable Push() fn?

[mperham]

Wait, I created this PR??? 😆 I'm very confused.

[mperham]

Unfortunately I'm not going to be able to get to this for a while. If you want to create a new PR which solves your issues, I'd be happy to review.