Good morning, and welcome to the week three announcements video for CC 410 in spring 2021, this has been a busy second week of the class. But hopefully at this point you should be, you should have already met with me for your final project milestone one where we discuss some ideas for your final project. I believe I’ve covered almost everybody in this class at this point. But if you have any questions about final project anytime, feel free to schedule a meeting with me or shoot me an email or catch me on Discord. And I’d be happy to chat with you about that. You should have also completed the second module in this class, which is a deep dive into object oriented programming. We did a short example on object oriented programming. And then you should have started working on the first milestone of the restaurant project. And so in that milestone, you’ll create a whole bunch of object oriented classes. It’s about 1500 to 2500 lines of code. And hopefully you’ve got that done in submitted but if not, keep working on it and make sure you get it submitted earlier early this week. Remember that the late penalty in this class is 10% off per day that it’s late. So you can still keep on working on it and get a lot of the credit if you submit it either today or tomorrow. So make sure you keep working on that.
Coming up this week, we’re going to have three different little modules on documentation, unit testing and UML diagrams. And so there’s three little example modules that you work on. There’s three little tutorial modules that you work through. And then there’s one example project on mostly testing, but it covers a little bit of documentation as well. Specifically, you’ll make a UML class diagram as part of that example. And then you’ll work on the second milestone of the restaurant project. This one is where we add unit tests and code documentation to our restaurant project. And so it can be very substantial. At the end of that project, I estimate that you’ll have anywhere from 3500 to 4000 lines of code in your project. So it is a significantly large chunk. But the nice thing is you can repeat a lot of that code. So some quick updates, I did create a channel on discord for this class. So feel free to go check it out. I’ve seen most of the students there at least once so make sure if you have any questions, you can post there and you might be able to get a response from me pretty quickly. If you don’t hear back from me or you want to make sure you get a response, you can always also email your question to the cc410-help email address, I guarantee that I will respond to those within one business day. for grading, don’t forget that the rubric itself will be found on canvas. And so you’ll find your point values on canvas. But a lot of the code itself, I will review via GitHub. And so you might find code comments in that feedback, pull requests that every GitHub repo has for GitHub classrooms. So feel free to look at that. If you don’t find that or you’re not sure where that is, let me know. And I’d be happy to help you find that inside of GitHub. Otherwise, I think so far, so good. I haven’t heard any major issues in the class yet. I’m very curious to see how my milestone one on the restaurant project went. I’ll be looking at those later today and getting those gradients. So hopefully, you’ll get some good feedback for me in the next couple of days on that.
So talking a little bit about milestone two, in milestone two, you’ll be writing unit tests. My sample solution for this has around 423 individual unit tests that I wrote, which is a very staggering number of unit tests, I will admit, you also need to write documentation comments for everything to the point where it passes either the Java check style or the Python flake style checker. Your documentation comments for your actual source code in the source directory should be pretty complete. In the test directory, they can be a little bit more incomplete. mainly just talking about what the unit test does, they don’t have to be too descriptive. But that way, you have a little bit of a note of what each unit test and each unit test class does. Also, don’t forget, it’s kind of buried in the requirements. But you do need to create a UML class diagram for this milestone. So make sure you create that and store that in the root of your Git directory somewhere. Next, your README file where I can find it. Again, like I said, this is going to be 3500 to 4000 lines of code. In any feedback you have is welcome. Let me know if this feels a little bit too big or too redundant or if there are other things that I can do to help clarify or simplify this project a little bit.
One thing I want to talk about, though, real quickly is hints for milestone two. These are all in the milestone document itself, but I wanted to cover them really quickly in this video. First and foremost, when you’re writing your unit tests, do not look at the source code that you wrote for milestone one, go back and look at the requirements from milestone one and make sure that your unit tests actually test those requirements. Basically, you want to test what you should have written not what you actually wrote. In fact, in in practice, you might actually do this backwards where you write the unit tests first following test driven development, and then you write the source code. But it’s really important that you don’t look at your source code while you’re writing these unit tests. For example, in my first model solution for milestone one, I went through and wrote unit tests for milestone two and I found no less than six errors in my own model solution for milestone one. So It is very important that you catch and find those errors using your unit tests. The second thing I will say is use global attributes in your unit test classes to help make copy pasting a little bit easier. I’ll show you an example of what that looks like on the next slide here. Also, don’t be afraid to try and generalize things. For example, if you need to check all the condiments, you can, in your global attributes have a list of what the condiments should be. And then in your unit test, you basically have an if statement that says if the condiment is in the list of condiments that should be there, you check to see if it’s there, or else you check to see if it’s not there. And so that way, in one unit test, you can cover all eight condiments. However, the ingredients do become tricky, it is possible to generalize the ingredients like ham and cheese and sausage and bacon. But you have to do that using either Java reflection or meta programming in Python, it gets very, very complicated, I didn’t even try and do this for my model solutions. It can be done, but I really don’t recommend it. Instead, I would just explicitly write the unit tests for all the different ingredients like ham and cheese and sausage, it gets a little repetitive. But it’s much simpler than trying to do the meta programming or the reflection tricks needed to actually look up an attribute by name instead of one that’s stored in a list or a dictionary. And finally, don’t forget to look at parameterize tests, you can parameterize your tests based on enums. In the document, I gave a link for how to find that for each language. So make sure you do that. But anytime you’re writing a test across all of the different enums, like bread types, or sizes or condiments, there’s usually a way that you can parameterize that down to a single test. So keep that in mind.
So when I’m talking about generalized tests, this is what I’m talking about. These are snippets of code actually taken from my model solution. So congratulations, I’m giving you a couple of freebies here. But basically what I’ve done in my test class, at the very top of the class, I define a whole bunch of global attributes things for like the price and the calories. And the you could do this for the different sizes for sides and drinks, you could list all of the condiments that are expected on an item, things like that, the default bread type, the default size. And so I have all these lists at the top, and then toward the bottom. In my unit tests, I just refer to those attributes when I’m testing. So if I test that the price is correct, instead of having the price typed in in that unit test, I just assert that the price I get from the item is the price value that I have the top of my class. And so in that way, I can copy paste large chunks of this class. And the only thing I have to change are the items at the top, I go back to the menu, I change the price, the calories, the condiments, whatever. And then I can use the same test code in multiple places. So this is a really smart way to make this project a little bit simpler. So be thinking about ways that you can quickly generalize your tests and make it a little easier to copy paste code between the different objects.
So looking ahead real quick. This is module three, covering unit testing and documentation. Next week, we’ll cover module four, which has a lot of inheritance. Then we’ll have module five, which covers debugging and it also is the second final project milestone. So you’ve got about three weeks to work on your final project and be thinking about classes and inheritance and things like that. module four will be due next week, module five, and the final project two will be due all the way at the end of February. So keep that in mind. And then we’re going to move into graphical user interfaces or GUIs. And so I’m hoping to post module six later this week, and possibly also module seven, which will cover GUI design basics and Event Driven Programming. And then as we go further in the class, we’ll do some more work with GUIs. We’ll also look at Web API as possibly serialization, all sorts of different ways that we can reuse our project code.
So that’s all I’ve got for this week. You’ll be basically feeling like a test printer writing all these unit tests this week. So I hope that you enjoyed this project. As always, if you have any questions, feel free to let me know via cc410-help or on Discord. Otherwise I look forward to hearing from you and good luck this week.