[ Pobierz całość w formacie PDF ]
.Proxy(r'/path/to/local/GoogleSearch.wsdl')>>> results = server.doGoogleSearch('foo', 'mark', 0, 10, False, "",.False, "", "utf-8", "utf-8")Dive Into Python 180 Traceback (most recent call last):File "", line 1, in ?File "c:\python23\Lib\site-packages\SOAPpy\Client.py", line 453, in __call__return self.__r_call(*args, **kw)File "c:\python23\Lib\site-packages\SOAPpy\Client.py", line 475, in __r_callself.__hd, self.__ma)File "c:\python23\Lib\site-packages\SOAPpy\Client.py", line 389, in __callraise pSOAPpy.Types.faultType:Can you spot the mistake? There's nothing wrong with the calling syntax, or the number of arguments, or thedatatypes.The problem is application-specific: the first argument is supposed to be my application key, butfoo is not a valid Google key.The Google server responds with a SOAP Fault and an incredibly long error message, which includes acomplete Java stack trace.Remember that all SOAP errors are signified by SOAP Faults: errors inconfiguration, errors in function arguments, and application-specific errors like this.Buried in theresomewhere is the crucial piece of information: Invalid authorization key: foo.Further Reading on Troubleshooting SOAP" New developments for SOAPpy(http://www-106.ibm.com/developerworks/webservices/library/ws-pyth17.html) steps through trying toconnect to another SOAP service that doesn't quite work as advertised.12.9.SummarySOAP web services are very complicated.The specification is very ambitious and tries to cover many different usecases for web services.This chapter has touched on some of the simpler use cases.Before diving into the next chapter, make sure you're comfortable doing all of these things:" Connecting to a SOAP server and calling remote methods" Loading a WSDL file and introspecting remote methods" Debugging SOAP calls with wire traces" Troubleshooting common SOAP-related errorsDive Into Python 182 Chapter 13.Unit Testing13.1.Introduction to Roman numeralsIn previous chapters, you "dived in" by immediately looking at code and trying to understand it as quickly as possible.Now that you have some Python under your belt, you're going to step back and look at the steps that happen before thecode gets written.In the next few chapters, you're going to write, debug, and optimize a set of utility functions to convert to and fromRoman numerals.You saw the mechanics of constructing and validating Roman numerals in Section 7.3, ÝCaseStudy: Roman NumeralsÛ, but now let's step back and consider what it would take to expand that into a two-wayutility.The rules for Roman numerals lead to a number of interesting observations:1.There is only one correct way to represent a particular number as Roman numerals.2.The converse is also true: if a string of characters is a valid Roman numeral, it represents only one number(i.e.it can only be read one way).3.There is a limited range of numbers that can be expressed as Roman numerals, specifically 1 through 3999.(The Romans did have several ways of expressing larger numbers, for instance by having a bar over a numeralto represent that its normal value should be multiplied by 1000, but you're not going to deal with that.For thepurposes of this chapter, let's stipulate that Roman numerals go from 1 to 3999.)4.There is no way to represent 0 in Roman numerals.(Amazingly, the ancient Romans had no concept of 0 as anumber.Numbers were for counting things you had; how can you count what you don't have?)5.There is no way to represent negative numbers in Roman numerals.6.There is no way to represent fractions or non-integer numbers in Roman numerals.Given all of this, what would you expect out of a set of functions to convert to and from Roman numerals?roman.py requirements1.toRoman should return the Roman numeral representation for all integers 1 to 3999.2.toRoman should fail when given an integer outside the range 1 to 3999.3.toRoman should fail when given a non-integer number.4.fromRoman should take a valid Roman numeral and return the number that it represents.5.fromRoman should fail when given an invalid Roman numeral.6.If you take a number, convert it to Roman numerals, then convert that back to a number, you should end upwith the number you started with.So fromRoman(toRoman(n)) == n for all n in 1.3999.7.toRoman should always return a Roman numeral using uppercase letters.8.fromRoman should only accept uppercase Roman numerals (i.e.it should fail when given lowercase input).Further reading" This site (http://www.wilkiecollins.demon.co.uk/roman/front.htm) has more on Roman numerals, including afascinating history (http://www.wilkiecollins.demon.co.uk/roman/intro.htm) of how Romans and othercivilizations really used them (short answer: haphazardly and inconsistently).Dive Into Python 183 13.2.Diving inNow that you've completely defined the behavior you expect from your conversion functions, you're going to dosomething a little unexpected: you're going to write a test suite that puts these functions through their paces and makessure that they behave the way you want them to.You read that right: you're going to write code that tests code thatyou haven't written yet.This is called unit testing, since the set of two conversion functions can be written and tested as a unit, separate fromany larger program they may become part of later.Python has a framework for unit testing, the appropriately-namedunittest module.unittest is included with Python 2.1 and later.Python 2.0 users can download it frompyunit.sourceforge.net (http://pyunit.sourceforge.net/).Unit testing is an important part of an overall testing-centric development strategy.If you write unit tests, it isimportant to write them early (preferably before writing the code that they test), and to keep them updated as code andrequirements change.Unit testing is not a replacement for higher-level functional or system testing, but it is importantin all phases of development:" Before writing code, it forces you to detail your requirements in a useful fashion." While writing code, it keeps you from over-coding.When all the test cases pass, the function is complete." When refactoring code, it assures you that the new version behaves the same way as the old version." When maintaining code, it helps you cover your ass when someone comes screaming that your latest changebroke their old code.("But sir, all the unit tests passed when I checked it in.")" When writing code in a team, it increases confidence that the code you're about to commit isn't going to breakother peoples' code, because you can run their unittests first.(I've seen this sort of thing in code sprints.Ateam breaks up the assignment, everybody takes the specs for their task, writes unit tests for it, then sharestheir unit tests with the rest of the team.That way, nobody goes off too far into developing code that won'tplay well with others.)13.3.Introducing romantest
[ Pobierz całość w formacie PDF ]
