Testability has two key facets: controlability and observability. To test a component, you must be able to controlits input (and internal state) and observe its output.
If you cannot control the input, you cannot be sure what has caused a given output. If you cannot observe the output of a component under test, you cannot be sure how a given input has been processed [1].
[1] Binder, R. V. (1994). Design for Testability in Object-Oriented systems (Vol. 37). New York, NY, USA: ACM.
“Ruby has appeared on other projects too, there’s a lot of recent developments using ruby for build automation or functional testing for Java projects. Almost all these projects have involved Rails, and most of them are web site projects where Rails is at least as important as Ruby.” (Martin Fowler)
http://martinfowler.com/articles/rubyAtThoughtWorks.html
Several specialists talk about the importance of software testability for software developement. In special, when applied for large-scale systems, this attribute should be fundamental to project success. Jungmayr (Jungmayr, 2002) compile some important references about this issue:
During the design of new systems we do not have only to answer the question ‘can we build it?’ but also the question ‘can we test it?’. Good testability of systems is becoming more and more important (Pol, Koomen, & Spillner, 2000 apud Jungmayr, 2002).
The absence of design for testability in large systems can greatly reduce testing effectiveness (Binder, 1999).
Design for testability, although rarely the first concern of smaller projects, is of paramount importance when successfully constructing large and very large C++ systems (Lakos, 1996 apud Jungmayr, 2002).
Lakos, J. (1996). Large-Scale C++ Systems. Addison-Wesley.
Binder, R. V. (1999). Testing Object-Oriented systems: models, patterns and tools. Addison Wesley.
Pol, M., Koomen, T., & Spillner, A. (2000). Management und Optimierung des Testprozesses: Praktischer Leitfaden für erfolgreiches Software-Testen mit TPI und TMap. Verlag.
Jungmayr, S. (2002). Design for Testability. Nürnberg, DE: CONQUEST.
Among the most common factors:
• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project’s status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project’s complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures
CHARETTE, Robert N. Why Software Fails. IEEE Spectrum, September 2005.
Wanderlei Souza
