Dive Into Python-Chapter 13. Unit Testing

Tham khảo tài liệu dive into python-chapter 13. unit testing, 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 13. Unit Testing Chapter 13. Unit Testing13.1. Introduction to Roman numeralsIn previous chapters, you “dived in” by immediately looking at code andtrying to understand it as quickly as possible. Now that you have somePython under your belt, youre going to step back and look at the steps thathappen before the code gets written.In the next few chapters, youre going to write, debug, and optimize a set ofutility functions to convert to and from Roman numerals. You saw themechanics of constructing and validating Roman numerals in Section 7.3,“Case Study: Roman Numerals”, but now lets step back and consider whatit would take to expand that into a two-way utility.The rules for Roman numerals lead to a number of interesting observations: 1. There is only one correct way to represent a particular number asRoman numerals. 2. The converse is also true: if a string of characters is a valid Romannumeral, 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 Romannumerals, specifically 1 through 3999. (The Romans did have several waysof expressing larger numbers, for instance by having a bar over a numeral torepresent that its normal value should be multiplied by 1000, but youre notgoing to deal with that. For the purposes of this chapter, lets stipulate thatRoman numerals go from 1 to 3999.) 4. There is no way to represent 0 in Roman numerals. (Amazingly, theancient Romans had no concept of 0 as a number. Numbers were forcounting things you had; how can you count what you dont 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 Romannumerals.Given all of this, what would you expect out of a set of functions to convertto and from Roman numerals?roman.py requirements 1. toRoman should return the Roman numeral representation for allintegers 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 numberthat 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 thatback to a number, you should end up with the number you started with. SofromRoman(toRoman(n)) == n for all n in 1..3999. 7. toRoman should always return a Roman numeral using uppercaseletters. 8. fromRoman should only accept uppercase Roman numerals (i.e. itshould fail when given lowercase input).Further reading * This site has more on Roman numerals, including a fascinating historyof how Romans and other civilizations really used them (short answer:haphazardly and inconsistently).13.2. Diving inNow that youve completely defined the behavior you expect from yourconversion functions, youre going to do something a little unexpected:youre going to write a test suite that puts these functions through their pacesand makes sure that they behave the way you want them to. You read thatright: youre going to write code that tests code that you havent written yet.This is called unit testing, since the set of two conversion functions can bewritten and tested as a unit, separate from any larger program they maybecome part of later. Python has a framework for unit testing, theappropriately-named unittest module.Noteunittest is included with Python 2.1 and later. Python 2.0 users candownload it from pyunit.sourceforge.net.Unit testing is an important part of an overall testing-centric developmentstrategy. If you write unit tests, it is important to write them early (preferablybefore writing the code that they test), and to keep them updated as code andrequirements change. Unit testing is not a replacement for higher-levelfunctional or system testing, but it is important in all phases of development: * Before writing code, it forces you to detail your requirements in a usefulfashion. * While writing code, it keeps you from over-coding. When all the testcases pass, the function is complete. * When refactoring code, it assures you that the new version behaves thesame way as the old version. * When maintaining code, it helps you cover your ass when someonecomes screaming that your latest change broke their old code. (“But sir, allthe unit tests passed when I checked it in...”) * When writing code in a team, it increases confidence that the codeyoure about to commit isnt going to break other peoples code, because youcan run their unittests first. (Ive 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 shares their unit tests with the rest of the team.That way, nobody goes off to ...