Genre: eLearning | MP4 | Video: AVC, 1280x720 | Audio: aac, 48 kHz
Language: English | Size: 555 MB | Duration: 14 episodes (2h38m) | Intermediate
In this series, we'll build a command line application to track the availability of in-demand products across any number of retailers. Perhaps you want to be notified the moment a Nintendo Switch becomes available for purchase? Let's do it!
Section 1 Setup
Find the Nouns
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.
Section 2 Initial Behavior
Initial Relationships
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.
Product Tracking
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.
04
Refactoring To Database Seeders
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.
Section 3 Retailer Clients
05
Different Strategies for Different Clients
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.
06
Fake it Till You Make it
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.
07
Techniques for Testing Against a Real API
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.
08
Start a Bug Fix With a Test
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.
09
Manual Review
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.
Section 4 Product History
10
Record Product History
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.
11
History Refactoring
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.
Section 5 Notifications
12
Notification Testing and Previewing
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.
Section 6 Clean Code
13
Simpler Code With UseCase Classes
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.
14
Detailed Console Output
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.
