Python10-Testing-your-program.rest

   1 [[Back To NumPy | Python9-NumPy]] - [[Forward To Home | Home]]
   2
   3 ----
   4
   5 **Presented By Tommy Guy**
   6
   7 **Based on materials by Katy Huff and Rachel Slaybaugh**
   8
   9 **What is testing?**
  10
  11 Software testing is a process by which one or more expected behaviors and results from a piece of software are exercised and confirmed. Well chosen tests will confirm expected code behavior for the extreme boundaries of the input domains, output ranges, parametric combinations, and other behavioral edge cases.
  12
  13
  14 **Why test?**
  15
  16 Unless you write flawless, bug-free, perfectly accurate, fully precise, and predictable code every time, you must test your code in order to trust it enough to answer in the affirmative to at least a few of the following questions:
  17
  18 Does your code work?
  19
  20 Always?
  21
  22 Does it do what you think it does?
  23
  24 Does it continue to work after changes are made?
  25
  26 Does it continue to work after system configurations or libraries are upgraded?
  27
  28 Does it respond properly for a full range of input parameters?
  29
  30 What about edge or corner cases?
  31
  32 What’s the limit on that input parameter?
  33
  34
  35 **Verification**
  36
  37 Verification is the process of asking, “Have we built the software correctly?” That is, is the code bug free, precise, accurate, and repeatable?
  38
  39 **Validation**
  40
  41 Validation is the process of asking, “Have we built the right software?” That is, is the code designed in such a way as to produce the answers we’re interested in, data we want, etc.
  42
  43 Where are tests ?
  44 Say we have an averaging function:
  45
  46 ::
  47
  48   def mean(numlist):
  49      total = sum(numlist)
  50      length = len(numlist)
  51      return total/length
  52
  53 The test could be runtime exceptions in the function.
  54
  55 ::
  56
  57   def mean(numlist):
  58      try :
  59          total = sum(numlist)
  60          length = len(numlist)
  61      except ValueError :
  62          print "The number list was not a list of numbers."
  63      except :
  64          print "There was a problem evaluating the number list."
  65      return total/length
  66
  67
  68 Sometimes they’re alongside the function definitions they’re testing.
  69
  70 ::
  71
  72  def mean(numlist):
  73     try :
  74         total = sum(numlist)
  75         length = len(numlist)
  76     except ValueError :
  77         print "The number list was not a list of numbers."
  78     except :
  79         print "There was a problem evaluating the number list."
  80     return total/length
  81
  82  class TestClass:
  83     def test_mean(self):
  84         assert(mean([0,0,0,0])==0)
  85         assert(mean([0,200])==100)
  86         assert(mean([0,-200]) == -100)
  87         assert(mean([0]) == 0)
  88     def test_floating_mean(self):
  89         assert(mean([1,2])==1.5)
  90
  91 Sometimes they’re in an executable independent of the main executable.
  92
  93
  94 ::
  95
  96  def mean(numlist):
  97     try :
  98         total = sum(numlist)
  99         length = len(numlist)
 100     except ValueError :
 101         print "The number list was not a list of numbers."
 102     except :
 103         print "There was a problem evaluating the number list."
 104     return total/length
 105
 106 Where, in a different file exists a test module:
 107
 108
 109 ::
 110
 111   import mean
 112   class TestClass:
 113       def test_mean(self):
 114           assert(mean([0,0,0,0])==0)
 115           assert(mean([0,200])==100)
 116           assert(mean([0,-200]) == -100)
 117           assert(mean([0]) == 0)
 118       def test_floating_mean(self):
 119           assert(mean([1,2])==1.5)
 120
 121
 122 **When should we test?**
 123
 124 The short answer is all the time. The long answer is that testing either before or after your software is written will improve your code, but testing after your program is used for something important is too late.
 125
 126 If we have a robust set of tests, we can run them before adding something new and after adding something new. If the tests give the same results (as appropriate), we can have some assurance that we didn’t break anything. The same idea applies to making changes in your system configuration, updating support codes, etc.
 127
 128 Another important feature of testing is that it helps you remember what all the parts of your code do. If you are working on a large project over three years and you end up with 200 classes, it may be hard to remember what the widget class does in detail. If you have a test that checks all of the widget’s functionality, you can look at the test to remember what it’s supposed to do.
 129
 130 **Who tests?**
 131 In a collaborative coding environment, where many developers contribute to the same code, developers should be responsible individually for testing the functions they create and collectively for testing the code as a whole.
 132
 133 Professionals invariably test their code, and take pride in test coverage, the percent of their functions that they feel confident are comprehensively tested.
 134
 135 **How does one test?**
 136
 137 The type of tests you’ll write is determined by the testing framework you adopt.
 138
 139 **Types of Tests:**
 140 *Exceptions*
 141 Exceptions can be thought of as type of runttime test. They alert the user to exceptional behavior in the code. Often, exceptions are related to functions that depend on input that is unknown at compile time. Checks that occur within the code to handle exceptional behavior that results from this type of input are called Exceptions.
 142
 143 *Unit Tests*
 144
 145 Unit tests are a type of test which test the fundametal units a program’s functionality. Often, this is on the class or function level of detail.
 146
 147 To test functions and classes, we want to test the interfaces, rather than the implmentation. Treating the implementation as a ‘black box’, we can probe the expected behavior with boundary cases for the inputs.
 148
 149 In the case of our fix_missing function, we need to test the expected behavior by providing lines and files that do and do not have missing entries. We should also test the behavior for empty lines and files as well. These are boundary cases.
 150
 151 *System Tests*
 152
 153 System level tests are intended to test the code as a whole. As opposed to unit tests, system tests ask for the behavior as a whole. This sort of testing involves comparison with other validated codes, analytical solutions, etc.
 154
 155 *Regression Tests*
 156
 157 A regression test ensures that new code does change anything. If you change the default answer, for example, or add a new question, you’ll need to make sure that missing entries are still found and fixed.
 158
 159 *Integration Tests*
 160
 161 Integration tests query the ability of the code to integrate well with the system configuration and third party libraries and modules. This type of test is essential for codes that depend on libraries which might be updated independently of your code or when your code might be used by a number of users who may have various versions of libraries.
 162
 163 **Test Suites**
 164 Putting a series of unit tests into a suite creates, as you might imagine, a test suite.
 165
 166 **Elements of a Test**
 167
 168 **Behavior**
 169
 170 The behavior you want to test. For example, you might want to test the fun() function.
 171
 172 **Expected Result**
 173
 174 This might be a single number, a range of numbers, a new, fully defined object, a system state, an exception, etc.
 175
 176 When we run the fun function, we expect to generate some fun. If we don’t generate any fun, the fun() function should fail its test. Alternatively, if it does create some fun, the fun() function should pass this test.
 177
 178 **Assertions**
 179
 180 Require that some conditional be true. If the conditional is false, the test fails.
 181
 182 **Fixtures**
 183
 184 Sometimes you have to do some legwork to create the objects that are necessary to run one or many tests. These objects are called fixtures.
 185
 186 For example, since fun varies a lot between people, the fun() function is a member function of the Person class. In order to check the fun function, then, we need to create an appropriate Person object on which to run fun().
 187
 188 **Setup and teardown**
 189
 190 Creating fixtures is often done in a call to a setup function. Deleting them and other cleanup is done in a teardown function.
 191
 192 **The Big Picture**
 193 Putting all this together, the testing algorithm is often:
 194
 195 ::
 196
 197   setUp
 198   test
 199   tearDown
 200
 201
 202 But, sometimes it’s the case that your tests change the fixtures. If so, it’s better for the setup and teardown functions to occur on either side of each test. In that case, the testing algorithm should be:
 203
 204 ::
 205
 206   setUp
 207   test1
 208   tearDown
 209   setUp
 210   test2
 211   tearDown
 212   setUp
 213   test3
 214   tearDown
 215
 216 ----------------------------------------------------------
 217 Python Nose
 218 ----------------------------------------------------------
 219
 220 The testing framework we’ll discuss today is called nose, and comes packaged with the enthought python distribution that you’ve installed.
 221
 222 **Where is a nose test?**
 223
 224 Nose tests are files that begin with Test-, Test_, test-, or test_. Specifically, these satisfy the testMatch regular expression [Tt]est[-_]. (You can also teach nose to find tests by declaring them in the unittest.TestCase subclasses chat you create in your code. You can also create test functions which are not unittest.TestCase subclasses if they are named with the configured testMatch regular expression.)
 225
 226 Nose Test Syntax
 227 To write a nose test, we make assertions.
 228
 229 ::
 230
 231     assert (ShouldBeTrue())
 232     assert (not ShouldNotBeTrue())
 233
 234
 235 In addition to assertions, in many test frameworks, there are expectations, etc.
 236
 237 **Add a test to our work**
 238
 239 There are a few tests for the mean function that we listed in this lesson. What are some tests that should fail? Add at least three test cases to this set.
 240
 241 *Hint: think about what form your input could take and what you should do to handle it. Also, think about the type of the elements in the list. What should be done if you pass a list of integers? What if you pass a list of strings?*
 242
 243 **Test Driven Development**
 244
 245 Some people develop code by writing the tests first.
 246
 247 If you write your tests comprehensively enough, the expected behaviors that you define in your tests will be the necessary and sufficient set of behaviors your code must perform. Thus, if you write the tests first and program until the tests pass, you will have written exactly enough code to perform the behavior your want and no more. Furthermore, you will have been forced to write your code in a modular enough way to make testing easy now. This will translate into easier testing well into the future.
 248
 249 --------------------------------------------------------------------
 250 An example
 251 --------------------------------------------------------------------
 252 The overlap method takes two rectangles (red and blue) and computes the degree of overlap between them. Save it in overlap.py. A rectangle is defined as a tuple of tuples: ((x_lo,y_lo),(x_hi),(y_hi))
 253
 254 ::
 255
 256  def overlap(red, blue):
 257     '''Return overlap between two rectangles, or None.'''
 258
 259     ((red_lo_x, red_lo_y), (red_hi_x, red_hi_y)) = red
 260     ((blue_lo_x, blue_lo_y), (blue_hi_x, blue_hi_y)) = blue
 261
 262     if (red_lo_x >= blue_hi_x) or \
 263        (red_hi_x <= blue_lo_x) or \
 264        (red_lo_y >= blue_hi_x) or \
 265        (red_hi_y <= blue_lo_y):
 266         return None
 267
 268     lo_x = max(red_lo_x, blue_lo_x)
 269     lo_y = max(red_lo_y, blue_lo_y)
 270     hi_x = min(red_hi_x, blue_hi_x)
 271     hi_y = min(red_hi_y, blue_hi_y)
 272     return ((lo_x, lo_y), (hi_x, hi_y))
 273
 274
 275 Now let's create a set of tests for this class. Before we do this, let's think about *how* we might test this method. How should it work?
 276
 277
 278 ::
 279
 280  from overlap import overlap
 281
 282  def test_empty_with_empty():
 283     rect = ((0, 0), (0, 0))
 284     assert overlap(rect, rect) == None
 285
 286  def test_empty_with_unit():
 287     empty = ((0, 0), (0, 0))
 288     unit = ((0, 0), (1, 1))
 289     assert overlap(empty, unit) == None
 290
 291  def test_unit_with_unit():
 292     unit = ((0, 0), (1, 1))
 293     assert overlap(unit, unit) == unit
 294
 295  def test_partial_overlap():
 296     red = ((0, 3), (2, 5))
 297     blue = ((1, 0), (2, 4))
 298     assert overlap(red, blue) == ((1, 3), (2, 4))
 299
 300
 301 Run your tests.
 302
 303 ::
 304
 305  [rguy@infolab-33 ~/TestExample]$ nosetests
 306  ...F
 307  ======================================================================
 308  FAIL: test_overlap.test_partial_overlap
 309  ----------------------------------------------------------------------
 310  Traceback (most recent call last):
 311    File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, in runTest
 312      self.test(*self.arg)
 313    File "/afs/ictp.it/home/r/rguy/TestExample/test_overlap.py", line 19, in test_partial_overlap
 314      assert overlap(red, blue) == ((1, 3), (2, 4))
 315  AssertionError
 316
 317  ----------------------------------------------------------------------
 318  Ran 4 tests in 0.005s
 319
 320  FAILED (failures=1)
 321
 322
 323 Oh no! Something failed. The failure was on line in this test:
 324
 325 ::
 326
 327  def test_partial_overlap():
 328    red = ((0, 3), (2, 5))
 329    blue = ((1, 0), (2, 4))
 330    assert overlap(red, blue) == ((1, 3), (2, 4))
 331
 332
 333 Can you spot why it failed? Try to fix the method so all tests pass.