On Sunday 02 December 2007 18:48, Chris Dolan wrote: > ... > > In this fashion, we use TODO tests to track when bugs in our > dependent packages get fixed, and then when we can remove workarounds > therefore. > > Chris
This discussion is interresting and it's always educating to understand why other do thing in what might first appear to be a strange way. One of the things I wrote was that I wanted _my_ tests to fail on a passed TODO. This would let other use the process they see fit. I have no doubt that any of us can deal with the "passed TODO" but we may not be the most representative developers. I like the principle of least surprise and passing todo are very very surprising, so surprising that (most) people writing Todos don't expect them to pass at all (I like to believe) and most people using modules might be surprised by that too; How we deal with passed todos in _our_ modules is easy. The question is how do you deal with _other's modules_ passing todo? I mail the author, look in the code, mail here and discuss. Most I believe, and it's regreatable, don't even bother looking. they scan for 'OK' and are happy with that. (I used to; now I like to see xx/yyy tests, that gives me a , false, sense of security) There is a third kind of module users. Entreprise users, people who follow a process, people investing money in development and that don't like to take risks. For those people, "Unexpectedly passed" screams "BROKEN". There is not simple solution to this problem. but I would like to be able to check my modules more thorowly and I would like to be able to setup cpan so I can say "unexpectedly succeeded" == failed so I can avoid some less competent manager come and put a list of 'weird modules used in my project' under my nose. Cheers, Nadim. PS: some of you always send two mails, one to the original mail author and one to the list. it's OK but getting the information just once is, IMO, better.
