Dive Into Python-Chapter 15. Refactoring

Tham khảo tài liệu dive into python-chapter 15. refactoring, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Dive Into Python-Chapter 15. Refactoring Chapter 15. Refactoring15.1. Handling bugsDespite your best efforts to write comprehensive unit tests, bugs happen.What do I mean by “bug”? A bug is a test case you havent written yet.Example 15.1. The bug>>> import roman5>>> roman5.fromRoman() 101 Remember in the previous section when you kept seeing that anempty string would match the regular expression you were using to checkfor valid Roman numerals? Well, it turns out that this is still true for the finalversion of the regular expression. And thats a bug; you want an empty stringto raise an InvalidRomanNumeralError exception just like any othersequence of characters that dont represent a valid Roman numeral.After reproducing the bug, and before fixing it, you should write a test casethat fails, thus illustrating the bug.Example 15.2. Testing for the bug (romantest61.py)class FromRomanBadInput(unittest.TestCase): # previous test cases omitted for clarity (they havent changed) def testBlank(self): fromRoman should fail with blank string self.assertRaises(roman.InvalidRomanNumeralError,roman.fromRoman, ) 11 Pretty simple stuff here. Call fromRoman with an empty string andmake sure it raises an InvalidRomanNumeralError exception. The hard partwas finding the bug; now that you know about it, testing for it is the easypart.Since your code has a bug, and you now have a test case that tests this bug,the test case will fail:Example 15.3. Output of romantest61.py against roman61.pyfromRoman should only accept uppercase input ... oktoRoman should always return uppercase ... okfromRoman should fail with blank string ... FAILfromRoman should fail with malformed antecedents ... okfromRoman should fail with repeated pairs of numerals ... okfromRoman should fail with too many repeated numerals ... okfromRoman should give known result with known input ... oktoRoman should give known result with known input ... okfromRoman(toRoman(n))==n for all n ... oktoRoman should fail with non-integer input ... oktoRoman should fail with negative input ... oktoRoman should fail with large input ... oktoRoman should fail with 0 input ... ok======================================================================FAIL: fromRoman should fail with blank string----------------------------------------------------------------------Traceback (most recent call last): File C:docbookdippy omanstage6 omantest61.py, line 137, intestBlank self.assertRaises(roman61.InvalidRomanNumeralError,roman61.fromRoman, ) File c:python21libunittest.py, line 266, in failUnlessRaises raise self.failureException, excNameAssertionError: InvalidRomanNumeralError----------------------------------------------------------------------Ran 13 tests in 2.864sFAILED (failures=1)Now you can fix the bug.Example 15.4. Fixing the bug (roman62.py)This file is available in py/roman/stage6/ in the examples directory.def fromRoman(s): convert Roman numeral to integer if not s: 1 raise InvalidRomanNumeralError, Input can not be blank if not re.search(romanNumeralPattern, s): raise InvalidRomanNumeralError, Invalid Roman numeral: %s % s result = 0 index = 0 for numeral, integer in romanNumeralMap: while s[index:index+len(numeral)] == numeral: result += integer index += len(numeral) return result1 Only two lines of code are required: an explicit check for an emptystring, and a raise statement.Example 15.5. Output of romantest62.py against roman62.pyfromRoman should only accept uppercase input ... oktoRoman should always return uppercase ... okfromRoman should fail with blank string ... ok 1fromRoman should fail with malformed antecedents ... okfromRoman should fail with repeated pairs of numerals ... okfromRoman should fail with too many repeated numerals ... okfromRoman should give known result with known input ... oktoRoman should give known result with known input ... okfromRoman(toRoman(n))==n for all n ... oktoRoman should fail with non-integer input ... oktoRoman should fail with negative input ... oktoRoman should fail with large input ... oktoRoman should fail with 0 input ... ok----------------------------------------------------------------------Ran 13 tests in 2.834sOK 21 The blank string test case now passes, so the bug is fixed.2 All the other test cases still pass, which means that this bug fix didntbreak anything else. Stop coding.Coding this way does not make fixing bugs any easier. Simple bugs (likethis one) require simple test cases; complex bugs will require complex testcases. In a testing-centric environment, it may seem like it takes longer to fixa bug, since you need to articulate ...