This course has been updated! We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.
Transcript from the "Exercise 3: Enhancing our Data Model" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kevin Whinnery: So now we're going to be moving on to our third exercise of the day, which is enhancing our data model to use some additional properties. So, if we head out to GitHub,
>> Kevin Whinnery: You'll notice that there are two issues remaining. Both are tagged with exercise three. And both will get you into a little bit meatier parts of the of this application.
[00:00:34] The first is, and it could be that you'll be able to knock these out both at once, because maybe you'll want to write a test which exercises your new functionality that you're adding. But the first issue that I have is that right now is that there's no way to track the status of a Todo model once you mark it as complete.
[00:00:57] So, many of you were astute enough to note,
>> Kevin Whinnery: That when we actually run our application here in development mode.
>> Kevin Whinnery: When you mark a todo item as complete, and refresh the page it doesn't actually do anything. Now the way the user interface part of this will actually get to get to tomorrow.
[00:01:28] That will be a sort of our entree into learning a little bit about how VGS works. However, the backend part of this is something that I'd like to for us to address today. So, what I would like for folks to do is to take a D model for the todo, and add a Boolean flag for whether or not it's been completed.
[00:01:50] And in addition to adding that flag, we also need to modify our API in Express. Implement it with Express to accept a completed field, along with the current title field, which is the only one that's persistent at the moment. And again I wouldn't spend too much time, I wouldn't spend any time because we'll do that tomorrow.
[00:02:17] I'm trying to update the user interface. I would just look to test these URL's directly. And if you're into doing that, the go to, for me, I mean, if you're like Curl, that's great, but if you're using Chrome there is an app called Post Man. And Postman I feel is kind of the bee's knees if you're testing a rest API, because it gives you a nice GUI that lets you construct HTTP requests with different HTTP methods against your backend.
[00:02:52] So here and it sort of saves your history as well which is also kind of nice. So here we can do a GET request against /TODOs and hit Send, and then we can see the JSON that comes back from the server. We can do a POST request to todos, and then along with that, pass in some form encoded.
[00:03:11] And they do need to be form encoded, by the way if you do decide to use this tool, cuz that's the way that we're parsing the body. If we pass in some values like, hey there front end masters, and hit Send, we can create a todo that way.
[00:03:33] We get that representation back, and if we list them out again we can see that the front end masters record is in the database. So after you add that property using something like Postman to test the API, would be it would be useful. In addition to that, the second issue that I would like for folks to take a look at during this time, Dovetail's kind of nicely into that, which is adding some integration tests which we don't have yet in the application.
[00:04:06] We have like one kind of crappy unit test for our back end right now. Test coverage in this application is not great yet. So we could definitely do more unit tests as we add more functionality to the application, but if our test pyramid should be fat at the bottom with unit tests, and kind of skinnier in the middle with integration tests, that's the part of the pyramid that we're gonna be implementing next.
[00:04:33] And then, of course, at the top of the pyramid you have some end to end tests, which we will talk about later. But we're at this point looking to add to the middle of that test pyramid. I'm adding an integration test where we're testing that, controller logic is working with model logic in the way that we expect.
[00:04:52] So I would like for us to write an integration test that covers our controller logic. So write at least one test, the challenge here is to write at least one test for the todos controller that exercises one of the crud operations. Now to do that, you're gonna have to mock an express request and response object, and provide some values that can be used to satisfy the requirements of the of the controller logic that we have in that file.
[00:05:25] So that'll be part of the challenge there. So we'll probably for this, since this is a meatier task, we'll take for sure 30 minutes, we'll probably say 40 minutes, to tackle this because this will be the first time that you've engage with these technologies. And if you have any questions on the testing front, you can just create if you'd like, create a new file in the test directory here.
[00:05:56] And if you run an NPN in test any test logic that you run will be picked up and executed. So if you'd like to take a crack at that first before modifying the model at all, you can certainly do that. Or if you'd like to modify the model first and update the API with this new property you can take a crack at that first.
[00:06:17] But I think would be a good opportunity to try to take a crack at both of these tasks. So adding one integration test for the controller and then also adding the addition to the todo model that we've been talking about.