If we have two Eloquent models... and we need them to interact with one another... and these interactions create and modify database records...well, how do we go about testing that? Let's answer this question, while, in the process, continuing our review of TDD, PHPUnit, guards, and more.
If you'd like to try your hand at the homework assigned at the end of the video, here's a link to the source code.
setUpextractions, global testing helper functions, and a reusable
In this lesson, we'll build a fluent wrapper around the confusing regular expression syntax (using this project as inspiration). Similar to all other lessons in this series, the basic process remains the same: design the API you want (through tests), and then create the necessary production code to make it work!
View the source for this lesson on GitHub.
So you need to write some assertions to ensure that the necessary email is delivered when you hit a particular route? Well, at the time of this writing, Laravel doesn't offer any such functionality out of the box. Let's roll up our sleeves, and learn how to write and organize a custom set of assertions for this very task!
View the source code for this lesson on GitHub.
In this lesson, we'll review how to take a hardcoded Redis reference in our controllers, and extract its logic to a first class citizen. Beyond improved readability, an immediate benefit to this refactor is that it allows us to construct custom fakes for our tests. If we'd prefer that a particular test not hit Redis, we can now do so quite easily.
We all recognize that clarity is vital for any project, but often this clarity is set aside when preparing our tests. Be careful. When you return to that confusing test six month from now, you'll kick yourself for having to spend so much time re-learning how it works. In this episode, we'll discuss a few techniques for improving clarity within a test.