Systems come in all shapes, colors and forms. Some are big, some are small, and each requires a different strategy when it comes to testing, so it shouldn’t be a surprise that object oriented testing is a bit different than your regular testing.

We’ve talked about object-oriented programming a bunch, we know what it is, and how popular it is, yet there is not a lot of material on testing for object oriented systems. The beauty of OO testing is that it can be divided into three different branches, and we will cover all of them.

Let’s start with class testing, because of course we will start with class testing. A class is a key component of OO, it is the blueprint of how we will build stuff, and a beautiful way to organize code. So when we do class testing, we are basically checking each of our classes for errors or bugs that may give us headaches down the line. It is the way to validate that our class is following the design we have, and it ensures that every little part of our class, wether that be an attribute, a method, or an interface, is 100% bug free.

Then we have inter-class testing, and it’s a bit more complex than class testing. Your classes may be bug free when tested individually, but OO is all about interaction between classes and modules, so now you have to verify that all is well when the classes in a system are working together. Our system should be integrate, and inter-class testing is used to verify integrity.

Finally, we have system testing. At this point in our testing, we should have an integrate system, since we’ve already passed the inter-class testing. Now is the time to check upon the system’s compliance with the specified requirements that were defined in the analysis phase. Black Box testing is generally used to validate our tests during this stage.

As you can see, that’s a lot of testing! And I’m kind of tired of using the word testing, so that’s the last you will hear from it, ha.

Be sure to check out my website at grupoargon.co