Handling test data that depends on temporal data (that might change while the test runs)

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Fri May 16 01:16:53 EDT 2008


En Thu, 15 May 2008 23:32:38 -0300, Marcelo de Moraes Serpa  
<celoserpa at gmail.com> escribió:

> New mantra: Test to the interfaces (as in program to the interfaces) :)

Seems reasonable...

> However, I'm curious on how you would test the mathprogram.divide(x,y)
> function. But in this case I'm not testing the implementation. I don't  
> care
> how the divide process is done, only that it is done correctly (10/2 =  
> 5).
> Actually my posted example was meant to be like this:
>
> def test_divide
>   divdend = 10
>   divisor = 2
>   expected_result = 5
>   #10/2 should be 5, so let's test if the method gets it right:
>   self.assertEquals(mathprogram.divide(dividend,divisor),  
> expected_result)

Mmm, it's hard to tell in this example what's the purpose of  
mathprogram.divide, because Python already knows how to divide numbers.  
The code above is certainly a way to test the function; but aren't we  
testing the *Python* operator / instead of our own code?
(I'm thinking of mock objects here [1] - this example is too simple,  
perhaps it's hard to get the idea, see the wikipedia article for a few  
other examples)

[1] http://en.wikipedia.org/wiki/Mock_object

-- 
Gabriel Genellina




More information about the Python-list mailing list