Greetings:

This is a fairly long-winded question.  I beg your indulgence.  

I am writing unit tests for our bar code scanner test software, and I have 
encountered some results that I cannot explain nor get around.  Here is the 
scenario.

Our program implements a generator class for creating 'label' objects.  Leaving 
out a lot of detail, the generator converts a text string into a list of floats 
(txtlst), along with other attributes.  My unit tests verify that the 'label' 
has been constructed correctly.  

One of the generator class's attributes is the character separator (cs), a 
float which is inserted between the individual character representations in the 
label's txtlst.  This value is set when the generator object is created 
(default is 1.0), and can be changed by a simple assignment at any time before 
the label object is generated.  One of my tests verifies that, when cs is 
changed, the new value appears in the txtlst attribute for labels created after 
the change.  

To test this, I do the following:

     1. create a generator object
     2. check the cs value
     3. create a label
     4. check the cs values in txtlst
     5. change the generator's cs value
     6. check the new cs value
     7. create a new label
     8. check the cs values in the new txtlst


The first code excerpt implements these steps outside the unittest framework.   
 
###########################################
#!/usr/bin/python2.3
from lblgen import *

lg = lblgen(t = 'Any string here')
print '\n\nlg.cs: %.1f' % lg.cs
assert(1.0 == lg.cs)
lbl = lg.generate()
for x in lbl.txtlst[lbl.chlen::lbl.chlen]:
    assert(1.0 == x)
lg.cs = 2.5
print '\n\nlg.cs: %.1f' % lg.cs
assert(2.5 == lg.cs)
lbl = lg.generate()
for x in lbl.txtlst[lbl.chlen::lbl.chlen]:
    assert(2.5 == x)
###########################################

As the output shows, the assignment to lg.cs succeeded and the proper value was 
found in txtlst (no exceptions thrown by the assert statements).  
>>>>>>>>>>>>>>>>>>>>>>


lg.cs: 1.0


lg.cs: 2.5
>>>>>>>>>>>>>>>>>>>>>>

The next excerpt does the same steps inside the unittest framework.    
###########################################
#!/usr/bin/python2.3
from lblgen import *
import unittest

class cs_tryout(unittest.TestCase):
    
    def test_cs(self):
        lg = lblgen(t = 'Any string here')
        msg = ('Generator cs is incorrect.\nExpected %3.1f; got %3.1f' % 
               (1.0, lg.cs))
        self.assertEqual(1.0, lg.cs, msg)
        lbl = lg.generate()
        msg = 'txtlst entry %d is incorrect.\nExpected %3.1f; got %3.1f'
        for ndx, got in enumerate(lbl.txtlst[lbl.chlen::lbl.chlen]):
            self.assertEqual(1.0, got, msg % (ndx, 1.0, got))
        
        lg.cs = 2.5
        msg = ('Generator cs is incorrect.\nExpected %3.1f; got %3.1f' % 
               (2.5, lg.cs))
        self.assertEqual(2.5, lg.cs, msg)
        lbl = lg.generate()
        msg = 'txtlst entry %d is incorrect.\nExpected %3.1f; got %3.1f'
        for ndx, got in enumerate(lbl.txtlst[lbl.chlen::lbl.chlen]):
            self.assertEqual(2.5, got, msg % (ndx, 2.5, got))


if __name__=='__main__':
    unittest.main( )
 ###########################################

In this case, the assignment to lg.cs failed.  
>>>>>>>>>>>>>>>>>>>>>>
F
======================================================================
FAIL: test_cs (__main__.cs_tryout)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "J:\My Documents\Projects\Mongoose\symgen\test3.py", line 25, in test_cs
    self.assertEqual(expect, lg.cs, msg)
  File "C:\PROGRA~1\Python23\lib\unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: Generator cs is incorrect.
Expected 2.5; got 1.0

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (failures=1)
>>>>>>>>>>>>>>>>>>>>>>

Can anyone tell me why it should fail here and succeed when unittest is not 
involved?  I need to be able to verify that this and other attributes can be 
changed, and I don't want to abandon the unittest framework if I can avoid it.  

Thanks in advance for your help.  
 
Barry
[EMAIL PROTECTED]
541-302-1107
________________________
We who cut mere stones must always be envisioning cathedrals.
-Quarry worker's creed


_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to