Peter Maas <[EMAIL PROTECTED]> writes:
> I think this is too difficult, because there are many ways to write
> code (even skeletons) for a use case. An easier approach would
> be to write the skeleton manually, embed the test cases in the doc
> strings and generate the test code from the doc strings. If I
> remember correctly IBM has published something to generate unit
> tests from code. Python has a doctest module to support testing
> derived from doc strings. This can be combined with unit tests.
Yes - actually I channged my mind in somewhere in the article - I actually
don't want to create typical use-cases in the test bed, rather create a
skeleton which covers each method at least somehow (no code inside skeleton
would be needed).
> > The problem can be solved more easily if you design the module
>> skeleton first, then the tests and then the logic for the skeleton
>> - you would be creating tests before the code, but many people
> > wouldn't regard it as TDD then.
> You shouldn't care if your approach works for you.
Yes, you are right. I didn't select my words very well - I just meant that it
wouldn't be TDD then. Of course it might work, but I'd like to to it the TDD
way for now.
But thanks for the tip, I could see what IBM has done and then forget about
doing it automatically :)
--
# Edvard Majakari Software Engineer
# PGP PUBLIC KEY available Soli Deo Gloria!
$_ = '456476617264204d616a616b6172692c20612043687269737469616e20'; print
join('',map{chr hex}(split/(\w{2})/)),uc substr(crypt(60281449,'es'),2,4),"\n";
--
http://mail.python.org/mailman/listinfo/python-list
