Premises for a testable software

Asked

Viewed 140 times

8

Based on development in object-oriented language, what would be the premises for software to have robust testability (coverage and testing facility) ?

oop testing functional-testing unit-testing
  • 2

    What would be the definition of robust testability?

  • 1

    Coverage and ease of testing.

  • 1

    Thank you for accepting the answer, but sometimes it is interesting to wait a day or two to give the chance to other users to do better, so you don’t lose points for exchanging the accepted answer for another. : D

  • 1

    Yeah, I wish it was like the gringo forum where we get dozens of answers and sometimes they’re even blocked. : ) When I like the answer I usually mark it as accepted, I don’t want to commit the injustice of falling by the wayside. If you have any other legal answers you’ll get my vote.

  • 1

    The answer is great. I don’t think you need to worry. I would just add that it’s important to use the test tools and coverage existing for each language.

1 answer

7


TL;DR

There are many different types of testing at different levels of system abstraction, from unit testing to user acceptance testing. See more details in this other answer.

Testability is the software’s ability to be tested at all those levels, being greater the easier it is to implement and run the test and the less difficult it is to do this.

However, however, however, there is no method or set of methods that can effectively guarantee the quality of a software.

Intrinsic complexity

The first and strongest reason for the difficulty of exhaustively testing software is that software is an abstract and extremely complex entity by nature. Swap a bit between the data and the next behavior is unpredictable.

The number of variables (not to be confused with the variables declared in the code) when a system runs leads to an almost incalculable number of execution possibilities, being humanly impossible to test or even define all these possibilities.

Quality is subjective

The other reason, which haunts testers around the world, is that quality is an extremely subjective metric.

A system can have 100% test coverage and still not meet user needs. On the other hand, a virtually untested and bug-ridden system may be more useful than the first.

Better not test anything

Joking. It’s not because something is difficult and complicated that we shouldn’t do.

Of course we should test software, always, but we should do this consciously without relying blindly on some library, framework or methodology.

How to create object-oriented code with good testability

If we look at the point of view of the code, forgetting for a moment the highest level tests like integration or user, in fact, there is not much secret.

Although there are various techniques and good practices that can be observed, I will stick to what I consider to be the central point.

Division of responsibility between classes

If each class/object of the system has a unique and well-defined responsibility, it will be very easy to test each one individually.

Simple as that.

However, it is not always easy to achieve such an ideal in a complex system, so we must expand this universe a little to other important principles.

SOLID

I consider the principles known as SOLID the most elementary and important when designing and coding systems.

Nor will I dwell on each, as there are entire books on the subject and some questions right here in the OS, such as:

(if anyone finds more, you can add here)

It’s interesting when you study these principles, because sometimes it seems like everyone talks about the same thing. It can be confusing, but at the same time it makes perfect sense, as all converge to the same end.

For example, the principle of single responsibility makes it easier to use and test a class because it has a well-defined purpose, fewer usage variables, so fewer possibilities of problems.

The open/closed principle helps us not to need to change existing code, which prevents rework when testing and new test combinations in existing code.

The the principle of Liskov’s replacement works together with open/closed, making it possible to extend classes without modifying existing classes and without unpleasant surprises, as following it you must ensure that new subclasses can be used without breaking existing functionalities.

The principle of segregation of interfaces has much to do with single responsibility, avoiding that an interface presents disconnected behaviors and therefore is difficult to use and testing.

Finally, the principle of inversion of dependencies or inversion control decreases the coupling between classes and allows us to test objects in isolation using mocks, stubs or whatever, taking away from the class the responsibility of finding their dependencies.

Considerations

Tests are not a silver bullet for the quality of a system, but are necessary in so far as they help us determine whether the system do what you should be doing.

At code level, an object-oriented system whose classes are cohesive and loosely coupled, each with simple and well-defined responsibilities ensures good testability in unit tests and also integration.

At other levels, different techniques can be applied, but this is independent of the programming paradigm.

Browser other questions tagged oop testing functional-testing unit-testing

You are not signed in. Login or sign up in order to post.