Build a Stock Tracker App

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.