> > That depends on what you consider "valid". Just duplicating the function > code in the test is absurd and pointless.
Yes, the code is duplicated, and now I see your point. Thanks! However, that code would always generate the same string (despite the timestamp). But that was a violation of the DRY principle. And the specs don't really care if it is a md5, only that the string is unique. New mantra: Test to the interfaces (as in program to the interfaces) :) 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) I'd say they are still unit tests Yes. Now that I think of, they all really only change in **scope**. It's hard to re-wire your brain and break old habits, so, thanks for helping! Marcelo. On Thu, May 15, 2008 at 11:19 PM, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Thu, 15 May 2008 22:44:17 -0300, Marcelo de Moraes Serpa < > [EMAIL PROTECTED]> escribió: > > @Gabriel: I understand what you are saying. It all depends on what you >> want >> to test. In this case, I wanted to test the algorithm of the method. The >> test_generate_chat_dir_string is meant to do just that: Check if the >> generate_chat_dir_string generated a "valid" (according to the specs) >> string >> for a "chat dir name". >> > > That depends on what you consider "valid". Just duplicating the function > code in the test is absurd and pointless. Of course it will pass now - > you're executing the same code! On the other hand, what if you later want to > replace the algorithm and use SHA1 instead of md5? The test will fail then - > but do you *actually* care whether it actually returns the md5 digest or > something else? > If you *do* care, then you should compute the output by hand (or assume it > is correct *now*) and hard code THAT string in the test, not recompute it > again. > If you *don't* care, then follow the steps I outlined in the previous > message: just ensure that different inputs give different outputs. > > It is not a integration nor a functional "unit" test, but it is a "real" >> unit test in the sense that I created a test for each method and I >> exercised >> the methods the following way: >> >> 1) Got some data to test and... >> 2) ... Generated an output "manually" in the test method that I knew were >> the expected return of the tested method; >> 3) Fed this data to the tested method and compared the manually generated >> result with the return value of the method. >> >> It is like testing a method that does a simple division: >> >> def test_divide >> divdend = 10 >> divisor = 2 >> expected_result = 5 >> self.assertEquals(mathprogram.divide(dividend,divisor),5) >> > > Mmm, no, your posted example was more like this: > > def test_divide > divdend = 10 > divisor = 2 > expected_result = dividend/divisor > self.assertEquals(mathprogram.divide(dividend,divisor), 5) > > You *computed* the expected result using (presumably) the same code as the > tested function. > > The techniques you explained in your message sound more like functional >> testing or integration + functional testing where multiple aspects of a >> single functional unit are being exercised. Or am I wrong? >> > > I'd say they are still unit tests. I'm testing a single function, comparing > the expected output with the actual output. But I only check the *public* > interfase of the function, what their users expect from it (its contract, if > you want); I don't check the internal implementation. > The real value of unit tests comes when you want to modify something, or > reimplement it. You must ensure that you don't break other things. With a > too strict test very tied to the current implementation, you can't change > anything. > > > -- > Gabriel Genellina > > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list
