Skip to content
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

Simplify mockery and add check to include state in failure message #449

Closed
wants to merge 13 commits into from

Conversation

nitishr
Copy link
Contributor

@nitishr nitishr commented Dec 25, 2019

While most of the changes here are refactorings, there're 2 things in particular that go beyond and I think are useful irrespective of the other changes:

  • consistently terminate Mockery#mocha_inspect with \n here 2a5ecdc, since the old code would terminate the mocha_inspect output in all cases except when there's states to be output.
  • a test check for including states in the mocha_inspect output here: 031309f

Some of the refactorings like inlining temps might be considered merely stylistic preference, although I did them based on my (admittedly limited) understanding of cognition, and I'd happily revert those if need be. Others like the ones to do with @instances are, to my mind, genuine simplifications.

@floehopper
Copy link
Member

@nitishr

You've created quite a few pull requests like this one which seem to be focussed on refactoring the code to make it simpler and/or remove duplication. I really appreciate all the time you've spent working on the project.

However, it would help me if I understood the motivations behind pull requests like this one. For example, are you making the changes to make adding some specific new functionality easier or is it more for an abstract idea of making the code better...? Can you try to explain these motivations in the relevant pull request descriptions...?

Also, if you're interested, I'd like to invite you to a Slack channel where we can more easily discuss the project. Can you send your email address to me (james "dot" mead "at" gofreerange "dot" com)?

@nitishr
Copy link
Contributor Author

nitishr commented Jan 21, 2020

Sure, @floehopper. I have a few motivations for PRs like this:

  • I'm trying to understand mocha (as a mocha developer, not a mocha user), and my most effective way of trying to understand code is comprehension refactoring.
  • If I've refactored some code in the process of (or after) understanding it, and I think I've been able to "put my understanding back into the code", I think it'd be a shame to then just throw away that understanding and not let current or future maintainers benefit from it. Hence, rather than throwing away those changes, I'm submitting PRs in the hope that they'd be useful. If they aren't useful, or are a drain on your time for no obvious or immediate benefit, I'm totally fine with them being rejected. They're, after all, pull requests, not pull demands.
  • Secondly, it's not just about putting the understanding back in the code, but also, one often finds, that in the process, you end up with something useful that you weren't aiming for or even anticipating (such as spotting and fixing a bug and adding a missing test/check in this PR, refining the UbiquitiousLanguage (stubbee, callee and method_owner) in Stub method shared tests #458 and stubbee -> stubba_object, mock_owner -> stubbee #463 through an aha! moment in Shared tests for potential violations (stubbing non-existent/public methods, etc.) #460).
  • One of the reasons I'm playing around with and trying to understand mocha (besides the pulls from bug reports and feature requests) is to see if I might be able to improve it (even if it's just in my own playground) by adding features like contract testing ala bogus.
  • And lastly, the more abstract idea of making the code better and more responsive for the next change.

Hope that gives you some context. Let me know if you'd like to dig into any of those further. And again, if you don't find such PRs useful, let me know and I can lower the noise.

@floehopper
Copy link
Member

@nitishr Thanks so much for explaining - it's really helpful to understand what you're trying to achieve. And, once again, I'd like to make it clear that I very much appreciate all the work you've put in. I will do my best to review your PRs as and when I have time.

@floehopper floehopper self-assigned this Feb 10, 2020
Copy link
Member

@floehopper floehopper left a comment

Choose a reason for hiding this comment

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

There are a couple of commits which I'm not sure about, but by and large these changes look good. I'm going to look at getting them merged now.

backtrace = if unsatisfied_expectations.empty?
caller
else
unsatisfied_expectations[0].backtrace
end
raise ExpectationErrorFactory.build(message, backtrace)
raise ExpectationErrorFactory.build("not all expectations were satisfied\n#{mocha_inspect}", backtrace)
Copy link
Member

Choose a reason for hiding this comment

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

I'm not convinced about the long lines this generates.

else
unsatisfied_expectations[0].backtrace
end
backtrace = unsatisfied_expectations.empty? ? caller : unsatisfied_expectations[0].backtrace
Copy link
Member

Choose a reason for hiding this comment

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

Again I'm not convinced about the long lines this generates.

['states', state_machines]
].each do |label, list|
message << "#{label}:\n- #{list.map(&:mocha_inspect).join("\n- ")}\n" unless list.empty?
end
Copy link
Member

Choose a reason for hiding this comment

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

While removing the duplication here is good, I'm not convinced that the resultant code is very easy to follow.

@floehopper
Copy link
Member

As a first step, I've rebased the branch against master and resolved the conflicts in this branch.

@floehopper
Copy link
Member

As a first step, I've rebased the branch against master and resolved the conflicts in this branch.

I've now removed a couple of commits, re-written some of the commit messages, and force-pushed in preparation for merging.

@floehopper
Copy link
Member

Manually merged.

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