Professional IronPython

Testing Applications
 
❘
 
401
to test it, so the code doesn’t call 
ShowDialog()
. If you do decide to show the form, you’ll actually 
need someone to work with it. The script is suspended during the time the form appears onscreen.
The next step is to perform some tasks with the form. The code performs a default add
and subtract. The two value fields, 
MyForm.txtValue1.Text
and 
MyForm.txtValue2.Text
,
contain default values that you can use for testing. Actually, it’s good application design to
always include default values for the user so that the user has some idea of what kind of content
to provide.
The 
MyForm.btnAdd_Click()
and 
MyForm.btnSubtract_Click()
event handlers perform the actual 
addition and subtraction. In order to call these two methods, you must supply both a sender object 
and event arguments. The sender object can simply be an object because the code doesn’t use it.
The final test in the example is to change one of the values and perform another addition. To perform 
this task, the script changes the value of 
MyForm.txtValue1.Text
and calls 
MyForm.btnAdd_Click()
. 
Normally, you’d provide a wealth of additional tests to check various values and see how they react 
with the code. For example, you might provide some negative values to ensure that the event handlers 
work properly with them. You might also test incorrect input, such as providing a string. The point is 
that you can completely automate any level of testing using this IronPython script technique.
Performing the Application Test
At this point, you have an application to test and the script to test it. It’s time to run the application. 
One of the problems you could encounter is not making something public (such as an object, control, 
or property) that you need to test (the default is to create private objects, controls, and properties). 
Unfortunately, the need to make class members public is one of the problems of using IronPython for 
desktop application testing. It’s not a big problem, but you need to consider it. When working with an 
extremely large application, changing the required member visibility could prove problematic. In addi-
tion, making some members public could pose security risks.
Let’s hope everything works as anticipated when you run the test. Figure 18-4 shows typical output 
from this application.
As with the DLL testing script, this script outputs text that’s easy to read and results that are easy 
to decipher. You know immediately whether certain tests have failed and precisely what inputs were 
used to conduct the test. As with DLL testing, you may need to use some other form of output, such 
as an XML file, when performing testing on complex applications because the content won’t fit 
entirely onscreen.
Applications can present a number of problems for this kind of testing. For 
example, you wouldn’t want to make the password field of a security dialog 
box public because someone else could possibly intercept user passwords as a 
result. It’s always a good idea to return the members that you’ve made public 
to private status to ensure that the application works in a secure manner when 
you put it into production. 
548592c18.indd 401
2/24/10 12:49:47 PM
www.finebook.ir

---