FREELessons: 13Length: 1.3 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.3 Behavior-Driven Development

Next, we'll now learn about Behavior-Driven Development, where we'll write tests in a human-readable format to describe how our site is expected to run. After writing our tests, we then can start writing the application-specific code.

2.3 Behavior-Driven Development

In the last lesson, we learned the basics of using test-driven development. Where we write tests before any application code's written to ensure application runs as expected. In this lesson, we're going to review a similar testing approach called behavior-driven development, or BDD for short. In which we'll still write our tests first. But the main difference being is that our tests are written as human-readable sentences called stories. Rather than looking like regular code. These stories describe the behavior of our application. This allows both programmers and non-technical people to write out features and scenarios about how an application should run using one notation style. We can then use those exact same features and scenarios to test our application with. By using behavior-driven development, we can accomplish the same end result as test-driven development. Except that it makes our tests more understandable to all of those who are involved in the application development cycle. Not just the programmers who can read the code. Now, implementing behavior-driven development from scratch without a framework would be beyond the scope of this lesson. But in the last section of this course, where we'll learn about acceptance testing, we'll dive right into coding BDD style using the Behat framework. For now, let's just get a good understanding of the BDD principals so we'll be ready to code when we get to that acceptance testing lesson. So basically, just like with test-driven development, the idea with BDD is to let our tests drive our application development process. We'll work in the same fashion by writing a failing test, watching the test fail. Then writing the application code, and re-running the tests to verify a successful test. The biggest difference really is in how our tests are written. BDD allows all of those involved to understand the tests, not just the programmers. The tests read as plain text, just like it was written in sentence form to describe the application's business outcomes. So here's some sample code of what a feature may look like to test the feature of seeing if the current date is my birthday. Here, the feature just says, in order to see if it's my birthday, as a regular user, I need to be able to call the isItMyBirthday method. So as you can see, feature simply described the behavior that you'd like to implement in a human-readable sentence format. Containing a benefit of the feature, a role for who's performing the behavior, and then the actual feature itself. So just by reading this feature, it's very clear what we're wanting to happen here, even to non-programmers. Now, after writing our feature, we need to tell the feature how it should behave given different scenarios. A scenario is just another set of human-readable sentences that contain a context, an event, and an outcome of the scenario. So your feature can have as many different scenarios as needed to test your application thoroughly. And here's an example of a scenario. Here it says, given that I have a birthdate of May 12, 1902 and today's date is October 3, 1927. When I call isItMyBirthday, then it should display, No, today is not your birthday. So here, you can see that the scenario's context is, given that I have a birthdate of 5-12-1902, and today's date of October 3rd, 1927. Now, the event is when I call the isItMyBirthday method. And then finally, the outcome is that it should display, No, today is not your birthday. So this scenario is what would be used to test for the described behavior. Now, hopefully, you're seeing how helpful tests can be. Whether you're writing just manual tests or using TDD or BDD, testing will help you in trying to identify problems in your application. Or when you need to re-factor your code. So that, you know, you didn't introduce any new bugs. And you can also always refer back to your tests should anything go wrong with your application. You can run your tests when something's acting buggy to see if any of the tests fail. If there are any failures, your tests will point you in the right direction. Now remember, this was just an introduction to the BDD principles. What I've discussed here was just the basics. And don't fret because you didn't get to code with BDD in this lesson. We will be implementing an example of PHP script using BDD later on in the course, in the acceptance testing lesson. But next up, we'll take a look at some of the popular PHP testing frameworks that are available to you to ease the process of creating, running and interpreting tasks in PHP. So that you don't have to do so much manually. I'll see you there.

Back to the top