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