There is a lot of great work out there on how to think about the different types of tests, how to proportion them, the test pyramid, for example. What I want to make sure you leave with, though, is a really practical, actionable intuition about how all this stuff really works in an actual application. So we have a piece of sample code we're going to look at here. And we're going to look at what it's supposed to be doing, sort of the underlying why are be building this thing, because that should really drive everything else, our focus. We're going to look at how the application works right now and then we're going to look at how we test it. Now, if you are not interested in coding or the details of code, I still think that you'll find this really helpful. We're going to go through kind of the general contours of how these things work. We're not going to worry about the details, though this code is available to you online if you do want to dive in and take a look. And either one of those options is perfectly okay. I think you'll get a lot out of it in either case. Now, our subject company in our example is called HVAC in a hurry. HVAC stands for heating, ventilation, and air-conditioning. And basically, what these folks do is for the commercial building that wants to have somebody else fix their HVAC system so they could do it themselves but instead our proposition is, hey, we'll do it better and cheaper for you. HVAC in a hurry delivers this service of fixing and maintaining these systems. And so a typical interaction is Frida, the facilities manager of one of these buildings says, hey Danielle, the dispatcher, or Dan the dispatcher, my track is broken. Can you cone help me fix it? And she says, hey Trent, can you go out there and figure out what's going on and sort it out? Trent and Frida interact to get this repaired on. Now, the specific experience that the team has zeroed in on, the software term, our crew, our protagonist, is this question of how Ted the technician can find the availability and pricing for a replacement part. And we have here a user story that's helping us drive the focus around what we're going to do. If you're not familiar with Agile User Stories, there is a reference in the course resources. And so kind of the trigger event that initiates this story is Ted finds he needs to replace a part. Now he may either, A, know the part number, and just want to look it up. He may, B, not know the part number but thinks he can maybe sort it out from the make and model of this particular HVAC unit. Or he may just be stumped. And C, he wants to just take a photo, send it back to HQ and get help. His next step, then, is he wants to figure out how much this is going to cost and how the availability of this part is going to interact with his ability to get back and finish the job. So that he can sort this out with Freda and they can decide what to do. Freda, again, is our customer, the owner or manager of this building. All right, now, the way that I've put together this application for you is that it is a client on a system called JS Fiddle. This is just a website on the Internet, where you can put code and fiddle with it, if you will. And it's really nice, because you can interact and look at this code without having to set up your own development environment or do anything special on your computer. It's all Web-based, universally available. And it is a client in the sense that it sends requests and gets responses from a server, which is a service on Google called Firebase. And Firebase does a whole bunch of different things. It's in this general category, referred to sometimes as backend as a service. And the idea is that rather than building your own APIs and databases and all this kind of core foundation infrastructure, Google has it put together in a configurable way. So you can just go ahead and use what they've already gotten there as a service. And so basically what this client does is a lot of, it's sort of core interactions or sending requests and getting responses from Google Firebase. That's what you'll be seeing when we look at the code. The unit of code that we're going to look at is called a function and basically the way you think about a function is that it has a certain input like, hey, here's an email address and some passwords, or a password that I want you to use to register a user on Google Firebase, it does a bunch of stuff. And these are referred to as algorithms. And then it has a certain output like, yep, all set or no, something's wrong, for example. And so this is a good way to think about these functions. How do these functions relate to the types of test we talked about? Well, a unit test, we want to really isolate the individual function, fake the input, so we want to fake this input, that'd normally be coming from an external source and we just want to see how this thing works by itself. When we integration test, we're looking at this algorithm calling another function, we'll just label this F1, this is F2. In integration tests, we're looking at the interaction between one or more functions, usually two but not always. And then in a system test, we're kind of looking at the broader user experience and how whole bunch of functions interact together to provide a certain user experience, usually testing from either the front end or some kind of API that exposes the whole functional space of the application. All right, so that's how all that works in concept. Now let's take a look at the actual code.
