Spring '23 Week 3

Resources

• Slides

Edited Transcript

Hello, and welcome to the week three announcements video for CC 410 in spring 2023, this week you should be wrapping up module two, which is all about object oriented programming. There was an example project that went with that and you shouldn’t be wrapping up the first restaurant milestone, we’re really setting the stage for the project that we’re going to work on throughout the rest of the semester. Hopefully, you’ve turned in the first restaurant milestone by this point. But if you haven’t, please make sure you get that done as soon as possible. I’ll be going through your code and trying to give you feedback on structure and style as best I can. So it may take me a little while to get these graded, but I’ll shoot to have them graded by the end of this week. So you can look at that as you work on the next milestone.

This week, we’re going to shift gears a little bit and work on documentation and unit testing in our code. We’ll also look at UML diagrams, you’ll do a quick example on adding documentation and unit testing to a project. And then we’ll work on the second restaurant milestone, which is all about adding unit tests to our existing code. So for the second milestone, there are about 400 ish unit tests that you’ll end up adding. You’ll also add documentation comments, and you’ll create a UML class diagram for your project. Similar to the previous milestone, this takes anywhere from three to eight hours depending on how comfortable you are with the project and how much work you’ve done ahead of time. And this project can be significantly larger, because you’re really adding 3500 to 4000 lines of text to your source code. Again, much of that can be copy pasted, much of that is repetitive either between the unit tests as well as the documentation comments. So part of the reason that I make this project so big is to really give you the chance to work on your coding process. And think about ways that you can work smarter, not harder, I really don’t encourage you to try and type out every single line of code. Instead, I want you to think about parts that you can reuse and how you can simplify this. So you can work on a big project efficiently. And then as always, feedback is welcome. If anything is unclear on the milestone, please let me know.

So some big hints for the milestone to the first and foremost thing I’d say is when writing your unit tests, do not look at your source code to figure out what the test should do. Instead, you should go back and look at the original Milestone One assessment Milestone One requirements to figure out what you shouldn’t be doing for Milestone Two. A great example of this is the price for each menu item. If you’re looking at your source code for what the price should be, your unit tests will never actually find out if your price is wrong. Instead, you should get the prices and the calories and things from the original project description and put those in your unit tests. And that is a way that you can confirm that your source code actually has the right price in it. Hopefully that makes sense. It’s kind of a thing that once you think about it, it should be pretty obvious. But I really encourage you to write your unit tests solely based on the project description and not necessarily looking at the source code.

Another thing you can do in your unit tests is you can use Global attributes for things. This allows you to copy paste code a lot easier, where instead of having the price hard coded inside the unit test, you can have it stored in a global attribute at the top of the source file so that you can then change those attributes as you rotate around. And then you can try and generalize your unit tests, I show you how to make unit tests that generalize across enums. So anytime there’s an an enumeration or a list of things that you can generalize, please try and do that in your unit tests.However, I encourage you not to try and generalize across the ingredients. Anything that is listed as an individual ingredient attributes. You can generalize those, but it requires using code reflection, and I really don’t recommend trying that. So I really just recommend generalizing anytime you have an enumeration. So look at the enumeration parameterized tests.

Here’s kind of a quick example of one way that you can generalize your tests. This is a very simple test file from a few semesters ago. But notice at the top of the file in both Java and Python, I’ve created some global attributes to store the price and the calories for each item. And then the unit test below instantiates the item and then simply checks to see that the price is the correct number. Not that it’s anything else. And so when I copy paste this, I can basically do a find and replace for the Riker and replace it with whatever item we have. And then I can replace the price and the calories at the top of the file. And I can pretty much reuse most of these unit tests for any of the entrees in this project. So hopefully that gives you an idea of what I mean when I say you can generalize your unit tests a little bit to make it easier to move code in between those files.

Looking ahead from here, in module four, we’re going to talk all about inheritance and how we can add some inheritance to this project. We’ll spend module five looking at debugging and logging and lambda expressions. And you’ll do a little bit of work there. You’ll also have the second final project milestone at the end of module five, which aligns roughly with the end of February. Then we’ll get into the two new modules this semester, which are on design patterns and test doubles. This is content that previously existed in the course but it was later after we introduced graphical user interfaces. I’m pulling that content forward, if hopefully should stand alone really well, but there might be some weird references to things you haven’t seen yet. If you come across any of those, let me know and I’ll remind you when we get to those milestones about that.

So again, hopefully this is is a really useful one this is really the first time that you’re going to be working with unit tests so hopefully find that process very simple and helping you learn how to write code that is easier for you to test and debug as we go forward as always have any if you have any questions let me know and I look forward to seeing you again next week