{'fraction_non_alphanumeric': 0.029873039581777446, 'fraction_numerical': 0.0, 'mean_word_length': 5.261682242990654, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
The Problematics of Testing Object-Oriented Software

Within object-oriented methods, testing has received less attention than analysis, design, and coding. However, object-orientedness does not make testing obsolete and can even introduce new problems into the production of correct programs and their testing. Most work in testing has been done with "procedure-oriented" software in mind. Traditional methods, despite their efficiency, cannot be applied without adaptation to object-oriented systems. In an object-oriented system, the basic test unit is a class instead of a subprogram; hence, testing should focus on classes and objects. Moreover, it is not possible to test the operations of a class in isolation, as they interact with each other by modifying the state of the object which invokes them. However, some traditional techniques can still be applied, though indirectly. Sometimes, testing object-oriented software can benefit from objectoriented technology, for instance, by capitalizing on the fact that a superclass has already been tested, and by decreasing the effort to test derived classes, which reduces the cost of testing in comparison with a flat class structure. The object-oriented paradigm can also be a hindrance to testing, due to some aspects of its very nature: encapsulation, inheritance and polymorphism.