1.0 Discussion

[davedevelopment]

Just creating this as a place holder for discussions pertaining to a 1.0, will formalise something eventually.

Things I've been thinking about:

• Spies
  • Rough implementation in Basic/naive spy implementation #283
  • API needs discussing and finalising
• Docs
  • Structured Documentation #90
  • @GrahamCampbell and @wouterj have made some progress, looking to start on migrating to sphinx shortly
• API
  • Whole public API needs examining and finalising
• Stubs vs Mocks behaviours
  • IMO stubs should always be byDefault, i.e. you can override them
  • I would love to break the API completely, so that shouldReceive defaults to once, rather than zeroOrMoreTimes, along with a stub method, as I think the language is in conflict, but I think that's probably too much of a BC break.
• Issues
  • We need to fix and/or close issues as necessary
• User Feedback
  • Need to speak to user base to see what we're missing
• API Verifying mocks
  • Above and beyond allowMockingNonExistentMethods
  • Checks against method signature (for primitives and arg count etc)
  • Checks against docblock return type
  • Could be (configurably) silent when class/interface doesn't exist
  • Could be (configurably) silent when method doesn't exist

Newly added:

• PHP version support
  • PHP 5.3.x is EOL
  • See After commit a32c6ad986, having issue with loading multiple mocks of same class #297
• Coding Standards
• Review state of matchers Review state of argument matchers #129
  • I think strictness with regards to objects with($obj) and with(mustBe($obj)) are backwards compared to primitives.

[padraic]

I should be able to be pitch in soon. Finally ;). Running a team for over a year with a minimum of staff does not do wonders for your free time or stress levels. At the moment, I'm on a security crusade so I have a chunk of work to do for Composer and some other bits in private, but I'll start swinging through the open issues as I have time.

I haven't checked, but it's possible we might be able to leverage off the existing Markdown and use something like pandoc (http://johnmacfarlane.net/pandoc/) to convert pages to restructuredText as part of a build process.

[GrahamCampbell]

Can we follow PSR-1 for method names please. PSR-1 says they should be camel cased. This would mean renaming 31 public methods and 10 private or protected methods. Also, we get rid of the underscore prefixing on private/protected methods/variables?

[davedevelopment]

@GrahamCampbell I don't see why not, might want to hang fire on it until we finalise the API, any changes we make at that stage can make the necessary changes.

[GrahamCampbell]

Sure. I am can make a pull in a few weeks/months for that transition if you like?

[padraic]

@GrahamCampbell Most of the PSR-1 issues are the prefixed methods for mocks, e.g. mockery_reservedMethodName() - it was probably overkill on my part. Underlined methods are allowable under PSR-1. Yes, I know phpcs gives a warning, but a warning is not an error ;).

[GrahamCampbell]

Ok. Sure. :)

[davedevelopment]

Updated with php version support and coding standards.

[davedevelopment]

Added note about stubs vs mocks, specifically with regards to byDefault, see #307 and my comments on http://everzet.com/post/72910908762/conceptual-difference-between-mockery-and-prophecy

[fedecarg]

Hi Dave/Paddy, what about stubs checking the return value but not the data type, do you see this as a problem when it comes to state verification in PHP: https://gist.github.com/fedecarg/10223193

[davedevelopment]

@fedecarg I don't know if I see it as a problem per se (others might), but I definitely see it as something that would be nice to have.

We already have the allowMockingNonExistentMethods config setting, but I'd definitely like to have other functionality such as what you have mentioned along side it. More importantly though, I'd like to have the option for it more like a sniffer, so the violations can be just reported. We can then go on to make best practice recommendations as well. But time, effort etc.

[fedecarg]

Hi @davedevelopment Yes, my 2 biggest concerns at the moment are:

1. Behaviour verification: Mockery cannot provide guarantees about what is being verified because it uses normal doubles instead of verifying doubles (see RSpec Mocks 3.0).

2. State verification: Mockery cannot provide guarantees about what is being returned (in php you can dynamically type the return value within the body of the method).

[davedevelopment]

@fedecarg roger, added a section about "API verifying mocks" for discussion.

[davedevelopment]

Added note about argument matchers #129