Black-box testing is testing conducted from outside the application, with access no higher than the user or the operating system. The application is the “black box”, but it can be made more transparent. Many types of testing software attempt to do this at least for a restricted type of application. TestComplete is unique in the level of access it provides to external tests, as well as internal objects, properties and methods (even private ones) of the application under test.

To skip to the TestComplete most powerful functionality in this line, see Debug Info Agent™. Using this feature, testing with TestComplete can truly be called white-box testing. Very little remains masked. The test engine’s access to the application is similar to that of a debugger, which has more access than other parts of the application.

You can view an application’s internal parts (objects, properties and methods) in the Object Browser if you compile the Open Application examples in a way that enables the Debug Info Agent™.

This only applies to the Debug Info Agent™. TestComplete has varying levels of insight into an application. At the simplest level, TestComplete uses and intelligently organizes the available Windows information for a random system application that is not under test, such as Notepad.exe. The next level is for applications compiled with one of the supported development tools. TestComplete has knowledge about the way a development tool compiles code, and therefore, provides a further degree of insight. The third level refers to applications that use one of the more common UI libraries for their language, for instance the VCL for applications compiled with Borland Delphi. Here, TestComplete again exploits further encapsulated knowledge. All of the above applies to applications, whether they are loaded for a test or not.

The next level applies only to the application under test. If it is compiled as an Open Application, much of its more-public information will be wrapped into OLE interfaces, which TestComplete will have access to. In the case of Visual Basic, practically all of the application’s internal interfaces are already ActiveX interfaces, so a Visual Basic application is nearly transparent to TestComplete. The same logic applies to .NET applications and Java applications compiled with AWT, SWT and Swing libraries -- these applications are always “open” to TestComplete, that is, your test tests have access to application’s internal objects, methods and properties. For Microsoft Visual C++, Borland Delphi and C++Builder, the transparency of an Open Application depends on several elements, but especially on the libraries used.

The last level applies only to those three tools, since Visual Basic, .NET or Java do not need any further degree of transparency. This is the Debug Info Agent™. When the application under test is an open application compiled with external debugger information, TestComplete can interpret that information at run time in the same way a debugger would. Therefore, it gains access even to private elements.

White-box testing is not a testing approach, rather a tool that uses a variety of internal approaches. Some white-box uses are discussed in Unit Testing and Functional (or User Interface) Testing. The white-box capability makes testing easier, because it provides insight into what the tester is doing. In many cases, this capability makes a classic approach more productive, independent of the tester.

To be able to test your application with ease, TestComplete must recognize it as Open. Note that most applications are “open” to TestComplete. However, in some cases, you will have to recompile your application as Open. It takes almost no effort, and it makes many things simpler. Also, no matter which testing method you choose, there are points where you will get into a bind, for example, you cannot figure how to test something, or you cannot figure why a test fails. In such cases, working with an open application will make it much easier to get out of the bind.

Developers often do much less testing than they should. This tendency is more the result of work stoppages caused by testing, rather than the effort required to set up and run the tests. These work stoppages are why it is important to compile open builds by default for testing. This approach makes constant, routine testing practicable in any normal work environment, so it is the best guarantee that developers will actually do the testing they should.

Do not test haphazardly just because you have a great tool in your hands, but do use a disciplined, systematic approach. Do not shun TestComplete capabilities, especially Open Applications, even though some textbooks and articles claim no such capability is necessary for the method. It's not necessary for the method, but it can be essential for the testers. More often than not, it can make the difference between an ongoing, systematic testing program, and minimal testing “because you have to”.

To this point, this topic has discussed systematic testing. Systematic testing is also the focus of the other “testing” topics in this section. But there are other forms of testing that can be useful at times. These forms become far more productive with a white-box testing tool. Taken together, you might call them ad-hoc testing.

One such form is called exploratory testing. Such testing can be used to look into a problem, to decide what most urgently need improvement, to experiment and learn things for later development, and to simply view the application at work, using the most powerful light available. Use the Debug Info Agent™ here if you can.

In fact, you can do “exploratory browsing” first, again, with an open application and the Debug Info Agent™. No test is needed, just study the Object Browser while you run the application directly.

Another use for the Debug Info Agent™ falls somewhat outside of what is normally seen as “testing”. You can use the Debug Info Agent™ with the Test Log as a kind of logging debugger. It is a strong tool for separating the most useful messages in the Test Log -- an example of TestComplete filtering and reporting capabilities. This advanced debugger can be helpful in scripting and when creating keyword tests.

This is by no means a complete list of the advantages of TestComplete white-box testing capabilities. With experience, you will find more uses for them. But remember, most of these capabilities are no substitute for systematic testing. They are simply different, fruitful ways to work at your application.

White-Box Testing

See Also