Before we write a line of code, let's brainstorm for a bit. We'll begin by describing the general purpose of this application. This should reveal a number of nouns and terms that we should work into the code.
Now that we have a handful of terms in our minds, let's start with a test and flesh out the basic behavior for our application.
View the source code for this episode on GitHub.
Now that we have a basic idea of where we're going, let's write a feature test for the Artisan command that will track all products in our system.
View the source code for this episode on GitHub.
Before we move on to our next task, let's take a few moments to refactor our tests. We'll extract most of the setup work for our primary test into a custom database seeder class.
View the source code for this episode on GitHub.
Let's begin extracting each retailer client into its own class. As part of this episode, we'll review a variety of object-oriented techniques, including strategies, interfaces, factories, and more.
View the source code for this episode on GitHub.
Let's write one more test to confirm that, after we check availability, the local stock database is updated to reflect this new information. Once again, we don't want to hit an actual third-party API. Instead, we'll learn how to manually prepare fakes.
View the source code for this episode on GitHub.
So far in this series, we've faked the third-party API. There's no sense in hitting a real API every single time you run your feature tests. However, we do need to ensure that each Client
works the way we expect. Let's tag a set of API-specific tests that will assert against real requests sent to the BestBuy
API.
View the source code for this episode on GitHub.
Our tests are currently passing, but there's still a bug in our code. This is usually an indication that you're missing a unit test. In this episode, we'll write a regression test to reproduce the bug, and then fix it.
View the source code for this episode on GitHub.
Amazingly enough, we haven't yet created a local database. However, because our test suite is at green, let's manually try our new Artisan command. According to the tests, when we run php artisan track
, it should ping the necessary APIs to update the local status of all stock that we're currently tracking.
It would be useful if we kept a history log for every product. This way, for example, you could chart the price variance for a product over the last six months. Let's knock that out over the next two episodes.
View the source code for this episode on GitHub.
We're now successfully creating history entries each time the stock is tracked, however, something feels a bit off. Before we move on, let's take a few moments to refactor our code into a shape that makes a bit more sense.
View the source code for this episode on GitHub.
If the goal is for this Artisan command to run every five minutes, then we should think of a way to notify the user each time an important stock change occurs. For example, if an item was out of stock yesterday, but is now in stock, we should email the user so they can go buy it right away.
Let's test out a typical event + listener approach, before adopting use-cases in the following episode.
View the source code for this episode on GitHub.
It's true that our tests are currently passing, but that doesn't mean the code is perfect. Not by a long stretch. Consider the fact that one of the core abilities of this application is to track stock. And, yet, if we browse the source code, is there a single point of entry we could visit to learn exactly what happens when this tracking takes place? The answer is unfortunately, "not really." What if we could change that by creating a TrackStock
use case class that describes the important steps.
View the source code for this episode on GitHub.
The general purpose of this Artisan command we've created is to run automatically behind the scenes every five minutes or so. However, when you do run the command manually, it might be nice if it provided a bit more feedback. In this lesson, we'll review progress bars and table-based output.
View the source code for this episode on GitHub.
*Series still in development. Check back often for updates.