Fall '24 Week 3

Resources

• Slides

Edited Transcript

Hello, and welcome to the week three announcements for CC410 in Fall 2023. So this week you should be wrapping up module two, which is on object oriented programming. There’s a small object oriented programming example where you’ll make a menu item for a fictional ice cream restaurant. And then you’ll be working on the first restaurant milestone where you’ll be making the object oriented classes for the menu of the restaurant project that you’ve chosen to work on. So after you’ve got that done this week, we’re going to go back to that code. We’re going to add some documentation and unit testing to it. We’re also going to create a UML diagram that oversees exactly how that code looks. So you’ll do a small example of adding documentation and unit testing to an existing project. And then you’ll go to the second restaurant milestone to do all of that work in your code.

The second milestone, you’re going to add unit tests to your code. Depending on how you implement the unit tests, I say there’s around 400 unit tests in the model solution that I wrote a few semesters ago. You’re also going to add documentation comments to every class file, every method that’s in the class. Those documentation comments are really important because that helps you understand what your code does and how it works so that if you come back to it years later, you understand the thought process and the design behind how you did it. You’re also going to create a simple UML class diagram. Make sure you get that done. A lot of students forget that and lose points for not doing the class diagram. Your work on this milestone, again, should take anywhere between three to eight hours of work depending on your comfort level working with these tools. And this one tends to be the largest one. It’s about 3 ,000 to 4 ,000 lines of code. But again, you’re doing unit tests. Unit tests themselves are very verbose. And once you write a unit test for a particular use, you may be able to copy it between multiple unit test files in order to actually get things to work. So there’s a lot of cool things you can do to make this coding go a lot better. And that’s part of the reason these milestones are so big is to kind of force you to learn some of these more efficient ways of coding instead of sitting down and trying to go line by line, file by file, because that will take forever. You need to think a little bit bigger about how you can reuse pieces of code. And then we’ll come back in and do some refactoring to kind of simplify that. once we’ve built everything out. And as always, feedback is welcome on the milestones. If there’s anything that’s unclear, just let me know and I will happily take a look at that.

So, some big hints for the milestone. First things first, I really tell you for milestone two, do not look at the source. And what I mean is do not look at your source code while you’re writing unit tests. In theory, you should be able to write the unit test for your source code without looking at the code itself to make sure that it works. And the reason I tell you that is let’s say in the menu, you accidentally got the price for an item wrong. If you’re looking at your source code to figure out what the price is, your unit test is always going to pass. That’s not the point. The point is to go back and look at the original documentation, the original design specs, and write your unit test based on that. So, if a menu item is supposed to be 325, and it’s really actually 375 in your code, the only way you would catch that is by writing your unit test looking back at the original documentation, not your source code. So hopefully that makes sense. It’s really one of the big things a lot of students get wrong with unit tests is they write these unit tests that confirm their code works, and those are just like tautologies. They don’t actually test anything other than that the code does what it looks like it does, not what it should do. Another big thing you can do is use global attributes, and I’ll give you an example here in just a second.

You can also generalize some unit tests. There’s a lot of unit tests that you can parameterize or generalize across the toppings or the base layers that you use. Anything that is part of an enum is really easy to generalize. Do not try and generalize the individual ingredients. So for example on the sandwiches, if you have individual ingredient attributes like ham and cheese and meatballs, don’t try and generalize those. You have to hard code those. We’re not really going to get into code reflection in this class where you could generalize those. It’s much more difficult than it sounds. So look at doing some parameterized tests, and here’s kind of a good example of using global attributes and using global attributes in your code. For example here, this is a test for a menu item called the riker in Starfleet subs, and up here at the top I’ve just made these global variables for price and calories, and then I referenced them later on in the test itself. And so the cool part is you can copy this entire piece of code for another class, do a find and replace replace riker with something else, and then at the top of the file just update these price and calories variables. You don’t have to go through and change the source code itself. That’s really the big power here. In the document, I also have an example of using enum parameterized tests. I really, really encourage you to do that. So instead of having one test for each topping or each item that you can add in an enum, you can just do for every item in the enum, check to see if it’s there, check to see if it’s not. There’s some really cool test strategies that you can use around that.

So the other big thing I want you to keep in mind in this class is that this class really is meant to be a challenging class. And it really requires you to come in having a growth mindset. I don’t want you to look at the things like the milestones and the quizzes as as busy work that you have to do. They are assessments that I’ve carefully designed to challenge you to help you grow as a programmer and grow as a software developer. And so if you come into this idea that you can learn and grow from these milestones, I think you’ll have a much better opportunity to really succeed in this class. And so because of that, the milestones themselves are challenging. They’re meant to be challenging because if I gave you all the answers and you just mimic what I give you, you’re not really learning and understanding what’s going on. You’re just following the leader. And so I really want you to see these milestones as challenging for a good reason to help you grow as a programmer. In the milestones themselves, there’s a lot of hints. There’s a lot of subtle things that I put in there to try and direct you in the right way to do things. So make sure you read the milestones very carefully. If there’s any extra documentation linked from there, I encourage you to go read that and check that out. If any of those links are broken, let me know and I’ll go fix them. But it’s really, there’s a lot of hints in those milestones that are there for a reason if you read carefully and find them. But. Don’t be afraid to ask for clarification, especially some of the later milestones. I leave a lot of things up to your own design. You can always ask me for clarification if there’s a particular way that you want to do something and you need a little help with it.

As with all of my classes, these classes are not designed for you to be able to pass them without asking questions. It’s really not an expectation at all that you can fly through this course without asking a question unless you really have a big background in software engineering and programming. So don’t be afraid to come and ask questions. That’s how this class is designed. The other big thing, hopefully I’ve said this enough, but on all of these milestones, it pays to start early and work methodically. I know that for some of you that might be really difficult given your schedules, but do the best you can to start early and work methodically on these milestones so you’re not trying to do them all in one weekend. That gets really, really tough. And then the last big thing, take advantage of the tools that you have. We’re using Git and GitHub and GitHub Classroom in this class. So anytime you’re working on code, save and commit your work often, especially if you’re like, oh, I don’t know how to do this. Let me commit what I’ve got, work on it a little bit. If it works great, I can commit that. If it’s not, I can roll back to that previous commit and try again. It’s so much easier to do that than to try and undo all of the changes that you made across your code, especially when you’re working across multiple files. If you look at the Git documentation, you can do things like branching and merging. So you can have multiple different branches that you’re testing out and then pulling them all together to submit. I can help you with that if you have any questions about that as well. So some tips to help you as we get into the big part of the class here where we have these few restaurant milestones.

So after this module, we’re gonna do some stuff on inheritance. We’re gonna spend some time in module four, refactoring our code to take advantage of object -oriented programming inheritance. We’re gonna spend module five talking about debugging a little bit. We’ll have a final project milestone meeting here toward the end of September. And then we’ll go into a couple of modules on design patterns and test doubles. If there’s one thing that you take away from this class, it is module six and module seven on design patterns and test doubles. Those are by far the most important thing that I want you to learn in this class. And so we’ll get to those here toward the end of September, early October. And then we’ll add some stuff about user interfaces, web interfaces, and et cetera. So hopefully everything’s going well. This milestone is all about writing unit tests. So hopefully it’s a really good experience for you. I know unit tests are pretty new for a lot of you, but they’re a really important part of any code that you write. If you have any questions, let me know. Otherwise, good luck this week and I will see you again next week.