Maugrim_The_Reaper wrote:assert* methods are completely counter to this standard since they require a "translation effort" to translate PHP code, into English, into a symbolic concept. BDD moves into a groove where the code you write reflects your thoughts as closely as possible.
That makes perfect sense, coding to a specification. It's eliminating some work by merging two practices...I write specifications already...usually slightly higher level than what BDD promotes but that is then translated directly into source. However I can BDD being used as a one stop shop kinda deal, where you use the same specs in testing as you deliver to your client. It's abstract enough that I"m sure with a little coaching any laymen could understand the concept of a "spec".
If that sounds shrinky , which it does, it's deliberate. People don't think in terms of PHP syntax, they think in terms of their native language. When you write a spec saying "next prime after 100 should be 101", it's easier to copy it word for word into a spec, and assemble the code as:
You lost me on the shrinky bit.
IMO, that's the single greatest benefit of BDD - it puts you into the right mode of thinking. Specify, write example, implement example, pass acceptance, finished. TDD muddles though on write test, implement code to pass test, etc. - you can interpret that far too flexibly. Most TDDers in PHP do - their suites go off the cliff on testing state, short numbered methods, close correlation of tests to code (behaviour rarely follows a 1:1 relationship to code - one method can exhibit n types of behaviour afterall), multiple assertions per method (clumped specs), Reflection to test private resources (brittle tests), testing to real objects or resources (interdependent tests - the domino effect), etc. On the flipside, it's rare to see that in BDD since the terminology is very specific, very small, and the frameworks discourage poor practice
BDD is certainly a good idea...I appreciate your sharing this with me (us - the community). Personally, I don't share good ideas it's usually bad for business.

All joking aside, BDD is certainly a radically different approach. I've always tested my code, even with external scripts which was similar to AUT in many ways. I see BDD as more innovation rather than invention. Unit testing spawn from necessity...as developers learned that implementation testing had problems, they gradually began testing interface instead. When this became problematic, testing frameworks were introduced. I see TDD as the collection of best practices when testing.
Some of my confusion is being caused by the lack of formal definition though - actually thats almost always my biggest trouble.
When I first started reading about TDD/BDD...most of the TDD stuff clicked right away as it was essentially what I already did but refined (ie: frameworks) and formalized (similar to when I started on design patterns). But BDD like I said IMHO is revolutionary and not something I have ever considered so it's proving to be more difficult to pick up - contrary to most BDD articles which claim the opposite.

Likely caused by lack of formal TDD experience, but still.
Definitions still elude me. The only article I have found which actually attempts to define term:
http://adams.id.au/blog/2007/10/what-is ... velopment/
And I'm not sure how accurate they are, but it's a start at least. A small suggestion, perhaps you could consider a glossary for your manual on PHPSpec (I couldn't find one)???
Originally, I thought behaviors were simply the result of mock objects. Capturing method invocations and having them verified against expectations is what I find really exciting. I see how this may have stemmed from TDD and how BDD was conceived through the notion of testing behavior, but under the context of BDD am I correct in assuming that behaviors are not *just* verifiying expectations, but also the specification (which is where my problem with definitions comes in)?
If the expectation is the contract for the implementation and the "spec" is the verification of the result or state of a method...what is the specification? I thought the specification was the term used to describe the method. But then is that not the behavior as well?
I'll try and explain with my own understanding of definitions.
You have a
context. This is the class which contains the
specifications. The specifications are the individal methods which verify
behavior.
Behaviors are both the assertion/specs AND mocks/expectations.
What do you call the "spec" or assertion if the specification is the method itself which contains the "spec" assertion AND expectations? Is it appropriate to refer to this as the "test" of state or the assertion? The use of the
$this->spec
Is this because your framework keeps mocks separate from specs? Thus the PHPMock/PHPSpec projects rather than project? That question actually just gave me the answer I think.
Verifying "specification" is different than verifying the "expectation" and is why you give no examples in the manual for PHPSpec of verifying expectations?
If my assumption is correct, that really clears up my definition problem above. A specification is the equivelant of assertion but more human friendly and promotes more fine grained, loosely coupled testing. Verifying expectations, is then done separately (
inside the specification???).
Think this was you one main concern there . You don't mock the one being specified - only other objects. The point is to maintain isolation. The only exception should be for simple, non-reusable classes which are not worth a) mocking and b) writing new specs for. This all has one key effect - you'll have less specs, than the equivelent as tests under TDD. BDD has in my experience made me more efficient about what I write specs for. Note: BDD therefore mixes a little from Unit Testing with Integration Testing - the two in spec terms aren't as independent as TDD suites tend to enforce.
Yes thank you, that was a important question for me. Perhaps another important point to make mention in any articles you write for newbies, as that question had me stumped. However, the question only arose after reading the wiki article, which was confusing. Someone should update that article.
Quick question: Why would you *not* mock all your collaborators? Isn't it worth verifying the expectations? It seems to me, that is one of the best things about mock objects, not that they avoid the over head of the real object (which is what every article I've read seems to promote) but you can observe the behavior of the implementation of the spec'ed method???
Finally my last question: I know you will likely see me as over eager and suggest that I practice with just writing simple specs for a while, but I'm stubborn and eager to get started using PHPSpec/PHPMock on my current project (I decided that full AJAX support was required so I re-designed the architecture to support it if javascript is enabled - hosted application so hopefully it saves me killer bandwidth) so the timing couldn't better as I refactor the codebase. So yea, the question...
Are they both ready for production use?
http://blog.astrumfutura.com/archives/3 ... ework.html
That blog has me thinking that the API will change which makes me nervous as I will likely have 1,000+ specs when done...
Actually I have one more question. LOL Sorry.
If my understanding is now correct, and that a spec is different from a expectation. If the PHPMock objects are not used within the specification to verifying collaboration, where is this done???
Thanks again, your time is truly appreciated. Your mentoring me has likely saved me literally months of struggle and unanswered questions.
Cheers
