Even worse, that particular testAddAction test isn't even testing *any implementation defined by the tool*. It should be moved into the CMF tests, or maybe just deleted. God knows what its author was trying to cover. He *might* be trying to test listActions (which the tool does define), but if so he's doing a really shitty job because he doesn't actually test any of its conditionals.
So... are you going to delete it? No. Because you don't know why it's there, and neither do I, and it's easier to not think about it and just leave it there. Are you going to add tests that actually test the functionality *of the implementation*? No. Because "it's tested, it has tests!". But a lot of these tests are actually complete decoys. And on and on it goes, running useless tests that just spin the CPU for no apparent purpose, neglecting to revisit old tests and rewrite them in a way that *actually* tests the stuff that is written in the implementation... but, sure, features? Did you say features? We can add more features! So much technical debt...
doctests
Posted byphilikonat
2008-05-29 04:34 AM
Amen, brother. I used to write tests like that, too. But what's helped me *focus* on writing tests for the stuff I actually implement as well as documenting my intent are doctests. I know you hate 'em (and I partially agree with some of your criticism), but in the end they do help with those two issues.
doctests...
Posted bychrismat
2008-05-29 12:43 PM
You can write Perl in any language:
>>> # cut and paste shit I don't understand and use it anyway!
>>> from PloneDocTestNGCaseDS9 import MakeAPlone
>>> plone = MakeAPlone()
>>> 'mytool' in plone.objectIds()
True
... and so on. We both know that this is how it would have went if everything had been doctests instead of unit tests from the start. This is not a doctest vs unittest thing, it's a think instead of not-think thing.
So... are you going to delete it? No. Because you don't know why it's there, and neither do I, and it's easier to not think about it and just leave it there. Are you going to add tests that actually test the functionality *of the implementation*? No. Because "it's tested, it has tests!". But a lot of these tests are actually complete decoys. And on and on it goes, running useless tests that just spin the CPU for no apparent purpose, neglecting to revisit old tests and rewrite them in a way that *actually* tests the stuff that is written in the implementation... but, sure, features? Did you say features? We can add more features! So much technical debt...
>>> # cut and paste shit I don't understand and use it anyway!
>>> from PloneDocTestNGCaseDS9 import MakeAPlone
>>> plone = MakeAPlone()
>>> 'mytool' in plone.objectIds()
True
... and so on. We both know that this is how it would have went if everything had been doctests instead of unit tests from the start. This is not a doctest vs unittest thing, it's a think instead of not-think thing.