Professional IronPython

388
❘
CHAPTER 18
Using ironPython for APPlicAtion testing
The techniques in this chapter don’t imply that your old testing tool is worthless or 
that IronPython is somehow superior to everything else on the market. Like any 
other tool, IronPython excels in some areas and not in others. As a good developer, 
you want to have multiple testing tools in your arsenal to ensure you create useful 
applications that won’t immediately break under heavy usage. IronPython is sim-
ply another tool in your toolkit and you should treat it as such.
UNdERSTANdINg WHy yoU WANT To 
USE IRoNPyTHoN foR TESTINg
Every testing technique you’ve ever used has some drawback. For example, if you include debug 
statements in your code, you must ensure that you perform a release build to remove the statements 
before you release the code. Otherwise, the application will run slowly. In addition, using debug 
statements can cause the application to perform differently from the way it performs when you use 
it in a production environment, which makes it possible that the very tests that you depend on to 
check the application will actually hide problems from view.
Using IronPython for testing has a considerable number of benefits over other testing tools. The 
biggest benefit is that you don’t have to do anything special to the application. The test harness 
you create exists outside the application and doesn’t affect the application in any way. All the test 
harness does is monitor application behavior and report on it to you. As a result, if the test harness 
reviews every aspect of the application and verifies that it runs correctly, the application will run 
correctly in the production environment, too, because nothing will have changed.
As you’ve seen throughout the book, IronPython is an interpreted environment. That means you don’t 
have to create the test harness in one piece — you can create it a little at a time as you try things out 
with the application. In fact, the very nature of IronPython makes it possible for you to play “what if” 
analysis on your application. You can see just how bad you can make the application environment and 
try things that users do, such as create unreasonable execution conditions.
Using an IronPython script for testing means that all the testing code is in one place. If you decide that 
you need to add another test, you don’t have to delve into the inner workings of the application to add it 
and then create another build. Instead of using this time-consuming process, you simply add a few more 
lines to an external script using any text editor that you like. There’s nothing complicated about the 
process — anyone knowledgeable about your application should be able to do it without any problem.
The external nature of IronPython also makes it impossible for your test code to add problems (such as 
errors, performance issues, or reliability concerns) to the application. In some cases, adding test code 
actually introduces an application error, making it hard to know whether the error is in the test harness 
or the application. If there’s a problem in the IronPython test harness, you’ll see an IronPython error 
telling you about it. In short, you have separation between the test harness and the application, which 
ensures one won’t affect the other.
There are a few downsides to working with IronPython as a testing tool. The most important of 
these issues is that IronPython treats your application like a series of black boxes. It provides input 
548592c18.indd 388
2/24/10 12:49:43 PM
www.finebook.ir

---