Professional IronPython

fIgURE 18-5: 
Make sure you check the actual content of the DLL against the expectations you have for it.
If you remember from Chapters 16 and 17, the 
__doc__()
function is undefined for an assembly 
that you import into IronPython, but the 
help()
function does produce a result. One of the next 
checks you should perform manually is to verify that the assembly provides the kind of information 
you expect from help. Figure 18-6 shows the output of the 
help()
function for the 
Accounts
class. 
Notice that it contains all of the information you expect, including the fact that there are two forms 
of 
__new__()
, the constructor, and the read/write state of the various properties.
Of course, you’ll want to perform other sorts of manual testing that could eventually appear in your 
test script. For example, you might decide to check whether the 
Accounts
class will let you create an 
account with a negative starting amount (it will).
It would be also helpful to know whether someone could circumvent some of the properties in the 
Accounts class. You wouldn’t want someone to use code such as 
Account2 = Account2 + 20
to 
overcome the protections in the Deposit property. In this case, the test displays an error. Another 
check might include adding two accounts together, such as 
Acccount3 = Account1 + Account2
.
By now, you should have the point of using manual testing. You can creatively think of ways that 
someone might try to overcome protections in your code. It probably isn’t possible to find every 
avenue of entry into a DLL, but testing in this way helps you think through more potential prob-
lems that other forms of testing allow. Interactively probing your code is a unique method of test-
ing the impossible.
548592c18.indd 403
2/24/10 12:49:47 PM
www.finebook.ir

---