If you are involved in the computing/software areas, you’ve definitely heard about the binary system. You probably also know that there are infinite ways of representing every number by changing the base of the representation. Binary, Octal, Decimal and Hexadecimal are some of the most common representations for numbers nowadays, each has their own advantages depending on what they are going to be used for. Either way, they are all different ways of doing the same kind of representation and can be used to perform the same operations.
As I’ve been doing since I started this blog, I’ll be comparing the first paragraph to an OO topic. This time, I’ll explain the testing performed in OO languages and, as always, my focus will be Java. For the rest of this entry I’m assuming you already know basic concepts like classes or objects.
As I was doing my research for this entry I stumbled upon many different approaches to object oriented testing, and since I really don’t know which one’s best, I wanted to include all three of them. That’s why I mentioned the different numerical representations in the beginning: there are multiple ways of testing and all of them are valid. Of course, some are more detailed or strict than others, but they all serve the same purpose.
First, according to Minigranth, object oriented testing can be classified into three different categories depending on how extensive the actual tests are.
The first category is called Class testing, but is also known as Unit testing (which is actually the name I see the most). It consists in testing individual classes to look out for errors or bugs that help us decide whether our classes were implemented as they were designed or not.
The second type of test is Inter-class testing or Subsystem testing. This one is pretty easy to understand, since it only tests compatibility between modules or classes and makes sure everything works as it should.
Finally, there’s System testing. Which tests all of the classes as a whole unit and makes sure both functional and non-functional requirements are met.
This seems like an interesting way of testing, since it’s incremental and hence, more intuitive.
Second, Ambysoft has included a diagram that corresponds to each one of the steps of the Full Life Cycle Object-Oriented Testing Method (FLOOT). Unlike the previous classification, this approach is more like a series of steps that must be followed and repeated constantly. There are six different stages included in this cycle:
Requirements testing, analysis testing, architecture/design testing, code testing, system testing and user testing.
Each one of these steps involves making use of certain techniques to complete them. I’ll briefly explain the most common ones.
Model review. An inspection, which can be as informal or strict as one wishes.
Prototype review. Testers pretend to be in real situations and use the user cases to get through them.
Black-box testing. Verifies that certain inputs actually give us the expected outputs.
This one provides us with many tools for each of the steps, which it also gives. There are many options, so this can be useful when not sure of what to do. Since I didn’t list nearly as many techniques as in the original website, I’d suggest checking them out, because the information is pretty vast.
Finally, there’s another way of classifying testing methods for the OOP. This one was provided by EComputerNotes and revolves around a similar idea to the first one and is also classified into three different categories.
State-based testing. Verifies whether the methods of a class are interacting properly with each other. Finite-state machines are often used for this, since they allow to represent different states and their transitions. Also that’s where the name comes from.
Fault-based testing. Determines a set of plausible faults and detects the possibility of bugs in the code. The testing is mainly done to find these errors in the chosen implementation of the program. The effectiveness of this test depends heavily on the ability of the tester to detect possible bugs.
Scenario-based testing. Detects errors that are caused due to incorrect specifications and improper interactions among various segments of software. This is a common approach, since it’s really easy to think of how the system/program is supposed to be working, so coming up with the cases that lead to those situations is very easy too.
This last classification of testing focuses on more technical aspects, so these techniques may be more useful for formal reports, although the practicality of these methods could make it so they’re used for informal testing too.
Whatever classification you choose to follow, the important thing is to test your software. I’ve never seen a single person writing code and not testing it immediately afterwards. This is a crucial step in every sense, and I believe that’s also the reason for the high number of different methods, techniques and types of testing that exist. And that’s only considering the OOP! That’s really fascinating to me.
TL; DR: Just test your code, please.