1. Using BDD Language
in Unit Tests
True North PHP UnCon
Matt Frost - @mfrost503
2. What is BDD?
Behavior Driven Development
Think user stories
Language all stakeholders will use
3. Why BDD Language
Keeps your unit tests focused
Prevents tests from trying to do too
much
Translates business requirements into
technical requirements
4. Business Requirements
Come from non-technical people
Non-technical people trying to be
technical
Can be very difficult to understand...
13. Have a plan!
Know what you are testing!
Know why are you testing it!
Use the info available to test
intelligently
Business requirements aren’t always
great, find testable scenarios
14. FYI
BDD Language is NOT an annotation
Functions as test documentation,
doesn’t effect the test at all
Introduction\n Who am I?\n Who unit tests?\n Not a talk on how to write unit tests!\n
\nWhat is BDD?\n Definition of a feature in common language\n If you use scrum, think Scrum user stories\n In language that all stakeholders will use - non-technical language\n Anyone should be able read it and understand what's going on, not just developers\n
Why BDD Language?\n Communicates to other developers and acts as alert system if you try to do too much\n Business requirements are coming from non-technical people (marketing, clients)\n They're rarely good, complete or useful out of the gate\n Cut through the buzzwords\n Using common language allows everyone to translate requirement to what they need\n What you need and what marketing needs are NOT the same thing\n
Business Requirements\n Schizophrenic user experience\n This and then this but they should be able to do that\n Often buzzword heavy\n Non-technical people, trying to be technical\n
\n
User Story\n Declare your assumptions (Given)\n Trigger the start of your scenario(When)\n State the expected Outcome (Then)\n And\n This is not the same user story that you're getting in your scrum\n You have to do the work to determine what your story for that unit is!\n We're talking unit testing here, but functional and integration can implement it too\n
Focus\n If we're writing simple, focused code, our tests should be the same\n Single responsibility\n
Example #1\n This is how this might be communicated to us….if we're lucky\n Still not horribly technical, but we can work with this\n
Story 1\n Talk through the setup\n
\n
\n
\n
Have a plan\n Testing first provides a plan for our development\n Know what you are testing\n Good data\n Bad data\n Invalid data\n Know what's supposed to happen in all scenarios\n Know why you are testing it?\n This corresponds to a strategy\n You're testing it because you want to know that it works or why it doesn't \n Use the information that you have\n It may not always be exactly what you need\n If you don't have the info, get it\n If you can filter the buzzwords, you can usually find testing scenarios\n
\nFYI\n These are not PHPUnit annotations\n this language has no effect on your test at all\n tests are great documentation\n this language is documentation for your documentation\n helps to clarify things to everyon\n
Questions\n Rate me\n Tweet me\n Come talk to me\n