Object-oriented testing (or OOT) is a collection of testing techniques to verify and validate object-oriented software. As we all probably know, testing is a crucial part in the development of a project, and if we don’t do it effectively we will be left with a high chance of having a buggy code, or a non-optimized program or one that doesn’t even work at all.
OOT are techniques designes specifically to better test object oriented programs, but not all of the extensive testing needs to be done , just parts that you see fit, which is why it will be explained here.
Of course testing is seen mostly in the final stages of a project, but these tests will put in observation every aspect of it. There are several aspects that need to be tested, we can represent them with the image below.
How to test:
There are different types of tests as stated avobe, but the different testing procedures can be classified into three main categories:
- Unit Testing: In unit testing, since it is object-oriented, we can separate each class by its own and test its functionality. This can tell us errors in the input output logic or in the interface environment. Since it is separated from other classes, it becomes a lot easier to spot logical problems.
- Subsystem Testing: This testing procedure involves testing a group of classes together (or a subsystem). This test focuses on the relations between classes, as well as the interaction with the system outside the testing subject.
- System Testing: This testing involves the whole system (as its name says). This test procedure takes in responsibility the quality of the system as a whole.
Tips and Tricks when testing:
- Don’t forget, the goal is to find defects. The focus of a test is to validate the correctness of the functioning of your classes. Finding bugs in the testing phase is better than finding them in the final release.
- You can validate all code. You can test all your assets in the project; do not just limit yourself testing the source code. It is not often but mild errors can occur in this part too.
- Test often and early. The longer it takes to find a bug in the development stage, the greater the cost to be able to correct it.
- Test to the risk of the module. The riskier something is, the more it needs to be reviewed and tested. In other words you should invest significant effort testing in an air traffic control system but not that much effort testing a “Hello World” application.
- One test is worth a thousand opinions. Same thing as one action speaks for a thousand words, showing a successful test result is far more valuable than just saying that it works.
Good Code Practices 