[MUSIC] Hello, welcome back. In this topic, we're going to finish out the technical architecture, talking about some of the remaining topics that aren't in the core application. And we deal with testing and development. And then we'll move on to some more deployment topics. And the actual architecture of deploying the API and the database to the web. And then some other options having to deal with the web client deployment. And that will finish up our overall topics. I'm sure you noticed as we were going through the technical architecture that there was quite a few things that we were addressing within our application that we have to pull together. And the only sane way to be able to do that Is to be able to direct our development towards our goal, and to be able to verify that our application works as we work through the different levels and complexities. And the way we do that is through testing. Our testing is at three levels. Model, think database when I say that, requests, think the rest to API to the controller to the database when I say that. Feature, think from button click to API to controller end database and back when I say that. We will be doing no mocks as a part of the capstone. Everything will go from our point of testing down to the database and back. The first two levels are handled pretty much by the RSpec core. RSpec is a Ruby test framework with rich expression. And when I say rich expression, think English. There is a way that you can, through non-technical terms, really talk about what the application needs to do under certain conditions. And that can make up our acceptance test-planning. This is what we need to do. And we'll follow some of that acceptance test-planning as we get a little bit later in the course, and we pretty much get in the groove of how we're going to do our testing. Very soon after acceptance testing we start to develop the details of test. How it's going to pass, under what conditions and how we're going to verify certain things. And then with those written tests we go off and we write implementations that are looking to pass those tests. And then do a couple of gyrations to make sure that we.ve refined things. Supporting our spec are a couple of libraries. First of which, I'm going to talk about is factory girl. Many times in the test you need an example object. Give me an image, give me a thing, give me an address. And you need some rules of how you're going to build things. FactoryGirl is a factory of objects that allows us to describe or define how those are going to get built. And they can be as simple or complex as we want them to be. Faker, it's a fun little library. Random data is just fun. You can think of, you make up team names, you make up addresses, you make up thing names, or captions, It gives us sort of like a, instead of one, two, three, or a, b, c, d, e, f filling p a page, it will make up data. And it has lots of different types. As I said, it's a fun library to kind of toss in. So as you see, some nonsensical words, and some things that I'm going to put up there, they were all generated through Faker. Database cleaner, when we do our tests, we typically want to have the database clean when we start, and the database clean when we end. And we don't always know what things to clean, what things are there. So Database Cleaner pokes into the database, understands what's there, understands what it shouldn't touch, like migration data. And has the ability to destroy all information that's in there that we need to get rid of in order to conduct our tests. Cabybara rise on top of RSpec and allows us to do the feature testing. Which was the last one third of the layers that I have described earlier. It is focused at Web UI Testing, which means it understands mouse clicks and filling in fields, and things like that. It is probably the hardest thing to get your head around, because testing web UIs is difficult because of their asynchronous behavior. When you make a request you don't know whether something's going to come back in 1 second, 5 seconds or 25 seconds. And whether you should be timing that out and failing, or you should be waiting longer because the platform that you're running on operates at different speeds. So, there are times where if you're dealing with a native app browser and you're in your development environment and you're running at one speed. Or you're dealing with a headless browser, check into a build server, and you're running at much slower speeds. I will admit upfront that it's probably one of the hardest things to get your head around, but it does get better with practice. As a I eluded to earlier, our tests are going to run in different environments, in which there are about three different drivers that help support that. The RackTest driver is the default driver of RSpec and Rails and it's the driver that we're going to use when we communicate via the API test. It has poor support for Vanilla HTML and web services, but it has no support for JavaScript. So in order to do JavaScript we are going to need the two drivers that we're going to talk about next. Everything runs in the same process. So if you wanted to take advantage of database rollbacks as a part of your cleanup, you could, with a RackTest driver. One of the optional drivers to add in, or not so much optional if you're going to be doing JavaScript, is the Poltergeist gem. With that wraps around the PhantomJS native application that we're going to have to install locally on our boxes by having Poltergeist and PhantomJS installed. We're going to be able to write Capybara RSpec test that talk about going to a web page and making various button clicks. And nothing is going to appear on our screen. We may not author our tests that way, we may actually author it in Selenium. However, when we check it in, this is probably the most likely scenario which we're going to check things in in. It does run much faster than Selenium, but we can't see it. And so, when things go bad, what we have to do is rely on certain commands that will product images of what is on this headless display. Selenium on the other hand, the gem that allows us to talk to the core selenium and selenium is a wrapper around, basically chrome and Firefox, there is an actual browser involved. So when we write a text using Selenium, we'll see a browser pop up and buttons are clicking in mouse and everything is moving around the screen. If we want to slow it down, well we can put breakpoints in our code, and walk through that way. But it provides a nice interactive way to see what our test is doing, what's on the page, pause our tests using standard breakpoints, inspect the page, and to be able to complete our tests. We should all realize that testing your application is a very important part of developing an application. And testing is treated as a first place citizen within captcha. I just want to say few quick word about the development, environment and tools. We all should be aware that Rails Console on the IRB Shell there comes with it and we used that to the great extent in courses one, two and three. But there is also another optional shell that we can install into Rails called the Pry Shell. Which is very feature rich, we'll be able to do things like inspecting objects and looking at source code to objects as we are stopped in various break points. So thinking more about debuggers, we shouldl all be aware of the Byebug debugger from the earlier courses. Where we could define a Byebug breakpoint, rerun our application, and it will pause at that point, and then we can step through our code, look around at the state of our system while we're under test. We can also integrated Pry into Byebug, so that we have access to the Pry shell when we execute our tests. And then on the browser side, we of course can take advantage of Chrome Developer Tools, and Firefox Developer Tools, or any of the other ones. But I'll be primarily using the Chrome Developer Tools that allow us to look at the DOM elements, console logs, and the network activity that's going between the browser and our API. At this point, we pretty much finished describing the overall context of the technical architecture that was going to be involved in the course. And I'd like to get into more of the deployment aspects. When we deploy our application to the web, we're going to be deploying to two primary environments. Heroku and mLab. Heroku is going to deploy the both of the application. the Rails application server, Image Magick, image manipulation software, and Postgres through normal provisioning techniques. mLab is going to require some separate setup, and you went through that separate setup apart of course three. Now, what we're also going to do is not only have a production URI that we're accessing, but we also want to set up a staging environment. So the thought is that only completed code, only code that we want others to see, would go into production. Whereas staging, or we could have any number of staging environments, in our Heroku environment. From a single git repository, I could decide to push it to staging, staging, staging, and then we can look complete, I can then go to production. When we deploy our angular code as a part of our web client application, we have a few options. The first option is the simpler option where we deploy our web code as a part of our Rails application. What we do is we enable Asset Pipeline, and we deploy the web client within Asset Pipeline, like a standard Rails application. Except when it talks to the server, it talks to the external API, so the API really could be anywhere in the world. We still have separation of architecture. The nice thing about this is it's a single code base, single deployment, very easy to manage up and down. The bad parts are is we are within the asset pipeline. And it doesn't exclude use of tools, it just adds a unique aspect to it that may not be totally conducive to some of the external web development tools that want to stay agnostic to Rails. The other technique is more consistent with what you did in course five where the restaurant app is deployed to Heroku and is exposing just the API, and then we can deploy our web client to to let's say GitHub And do that communication. We can enable that in the caption as well. Nice thing about this is we does enable us to use a full suite of development tools, building modules and dependencies, and all kinds of things. However one of the down size is we've gotta repeat a lot of the things that Asset Pipeline gave us for free. A third way is a hybrid between the two. Where we develop our application as an external application. However, we finally package it up and publish it within the public folder of Rails, and just use Rails as a web server, and then deploy that to Heroku. In this third technique, the Asset Pipeline is not involved, we are just the application. Instead of being deployed at GitHub is deployed to Heroku within the public folder. Now we will cover all three techniques in the development area and we will have a chance to have some practice for those three. But when it comes time to developing the bulk of the code the application, I'm going to revert my examples back to the simpler asset pipeline technique. All the code will look and feel the same as if they were in any of the other three. So you're free to try or use those other techniques. However, my examples are going to stay in the Asset Pipeline, because its much simpler in environment to work with, and share the examples between you and I. That concludes our summary overview of the technical and deployment architectures. Where we finished up topics of testing and development in the technical aspect. And under deployment we looked at how we're going to deploy our API database and some options to the web client. Next, what we're going to do is go through some of the details of setting up the development environment that's supports a lot of the things we talked about in the technical architecture.
