Testing in Object-Oriented Programming

This is Building Better Developers, the Develop-a-newer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We're continuing our season where we're talking about practical object-oriented programming. In this episode, we are going to talk about testing. We're going to talk about the quality assurance side of building out and designing our programs, our solutions if we want to call it that. This is actually a very critical piece. It is almost never really specifically at least addressed in the object-oriented programming books that I've read and articles and stuff like that. It always focuses on the object-orientedness of our design and our code. However, since the goal is code reuse, then one of the things that becomes very critical in us doing this correctly is testing. We don't want to reuse broken code. Now, we do get a side effect of more reliable code or stuff that we're more confident in because we do reuse it. If you use it in multiple places, you are effectively testing it. You're testing it in location A, location B, location C. That's all well and good. It does mean that over time, we should have better, higher quality code. We should have stuff that works better, faster, and with less bugs. However, that's over time. Early on, we need to prepare to do that testing and to assume that this code is going to be reused, which begs the idea of regression testing. Unit testing is probably the most common form of this in a pure coding point of view. We go in, we build out our objects, we build out our methods, and then we have some unit tests that we run against it. That's actually really what we need in the object-oriented world. The system level types of tests where you're going through and testing it within all of its interactions and things like that, those really come when those objects are being used, when those classes are being used in various applications. What we do need is to consider as we are going through our development and our design, we need to include the test side of it. We need to include some validations so that when somebody does use our class, they have something that they can do as a sanity check, essentially, to say, okay, is this still working the way I think it does? They should be able to kick off those unit tests and those should all successfully run through. Obviously, if there's an error, there's a problem. We need to consider this as part of our design because this is going to be essentially our interfaces. When we think about how our class is going to be used, there are certain aspects of it that will need to be validated. We're going to have certain things that a user is going to expect to be able to check. That means we need hooks of some sort or feedback or return values or system messages or something that will allow a user to see that. This actually then points us back to our design side of stuff. It goes the idea of proper exception handling and returning values so that we don't have stuff that we just really almost ever, we should not have methods that we're calling that do not have some sort of return value. With that, not only the value return, but maybe some way to check that it was run valid in a valid sense. We would need to have something that we can kick back. If it's just a value, we should have something we can kick back that's maybe an error code kind of value or something like that. If that doesn't make sense, then use an exception. Most languages, especially the object-oriented ones, do provide for exceptions. That's what you're going to end up doing. Let's say you've got a simple method that adds two numbers. Well, the exceptions would probably be things like maybe I don't have a number. One of those values is null or maybe one of the values is a letter instead of a number, something like that. Well, I can't really return. If I do A plus B, then I can't return the string A plus B or AB as a string or something like that because I'm returning a number. Instead, I would kick out an exception that says, hey, invalid parameters or something along those lines. This is where we need to embrace the health check type of stuff that we have in our code, which typically is going to be return values and then also exceptions. We need to embrace using those. We need to be thinking about those as we are designing our classes because not only are we designing for the happy path, essentially, we also need to be taking into account what can go wrong as part of our design. When we build out a class, are there certain invalid states, essentially, that we need to warn the user of? All of this does go back to prior conversations. We talked about constructors and destructors and things like that. These exceptions in that become a part of that discussion because we talked about the idea of a constructor that then is followed by an initializer. If you do the constructor and you don't initialize the class, is it still valid? It may be that there's certain methods that are not valid and therefore, there would need to be some sort of check that says, hey, this has not been initialized, in which case it's going to throw the uninitialized exception or something along those lines. Users need to understand those. They need to have some idea of what is it that's coming. That's part of your signature. That's part of your design just as much as method names and parameters and return values and all of that kind of good stuff. All of those things combine to be essentially the interface that the developer has for our system, for our solutions. This is a two-part series of episodes. We're going to get a little bit more into the next episode. We're going to get a little bit more into the idea of using our tests to help drive our design. Now, definitely, we're already seeing that because as we're going through these tests, as we're building out our tests, those are probably going to highlight areas where we don't have the cleanest hooks. We don't have the best signature. We don't have something that is fully featured enough for someone using it. This goes into the reuse side as well. Typically, when we first design our solution, we design our classes for a specific solution. We can think high and mighty all we want, but really what we're doing is we're putting these together to solve a specific solution. The secondary thing should be that we're looking at those that we've put together and considering where else might they be useful and thus fleshing out essentially our classes in a way that allows these things to be a little bit more of a general purpose solution as opposed to specific to our case. Now, if we have internally used classes that are used multiple places and maybe even multiple situations, that's going to help. However, for example, go back to the idea of maybe a customer. If we have a customer class for whatever the application is we're building, that customer is going to be very highly tied to our approach, our customer for this solution. It may not be as flexible in general a class and thus not very useful for reuse, but if we step back a little bit and think about it and how it could be used in other places, it's going to improve our design a bit. We will swing back around to some of these concepts when we talk about just overall designing our object-oriented solution. For now, I just wanted to get us started on the idea of testing. In the next episode, we're going to continue this thought and really focus on, talk about test-driven development. Again, testing is not, for both of these, they're not really object-oriented issues as much as general software development issues, but I think as we walk through these, you're going to see where these are important. These are vital pieces for us to build truly object-oriented code. If we don't spend the time and think through the testing and the interface itself basically that we're building, then we're not really fully embracing object-oriented. We're really just using it as a way to solve our specific problem as opposed to thinking about it as more of a general solution into what we're looking at. But that does bring us to a fun challenge for the day. Typically when we talk about our weekly daily challenges, it's a few minutes here, a few minutes there. This could lead you into something a little bigger. When was the last time, really, what kind of unit tests do you have? When was the last time you actually walked through your code and put together, designed a comprehensive set of unit tests, such that you're covering all of the bases for your classes and what are the valid states and the invalid states and what are the various types of return codes or return values and messages and making sure that all of that does work and works in the way that you designed it, that you planned it. This could be something that could lead you to quite a bit of work because you may look at it and say, oh my gosh, I am way behind. I'm way deep in technical debt. I say that because most places are. Now there are some places out there and there's some processes that people use where they do a great job of keeping up with tests. But I think most of you will agree that that's not the common thing to do. If we're going to work in an object oriented world, if we're going to really reuse these classes we need those test beds around them so that as we extend stuff we should be able to then extend the tests and validate that we have done so properly. That being said, let's go ponder your level of QA-ed-ness in your code. And as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Nord podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernord.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Nord. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Nord site. You can also find it on Amazon, search for Rob Broadhead, or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week, and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernord.com if you would like more information. Now go out there and have yourself a great one.