On Thu, Jul 20, 2006 at 01:38:46AM +0200, demerphq wrote: > Now i consider "wrong" to be different from "broken" or "buggy". To me > broken and buggy mean that the reporting doesnt do what its supposed > to do. But since I know that what its supposed to do is report where a > given Test::Builder based test routine was called I dont consider it > broken when it does exactly that.
That's not what it's supposed to do. It's supposed to tell you which line in the test file is the one that ultimately called a Test::Builder method with a failing test. > > But there is one! Give it the explicit knowledge that you, the writer of > > the test suite, has. > Right. Give it a damn name so i can find it in an editor with its > built in search function. As if making test names mandatory made them both unique within test files and meaningful. The problem with $Level is that people don't use it correctly. You want to solve this by providing another element of code that more people will have to use more frequently and hoping that they use it correctly. I'm not sure that's a good assumption to make. > > No, using buggy, incomplete subroutines is. At least complaining that an > > incomplete, buggy subroutine does the wrong thing is silly. Of course it > > does the wrong thing. You wrote it to do the wrong thing. > Show me where this is documented in Test::More and we can discuss why > I didnt follw that documentation. Until its there you have right > calling my usage buggy. Sure I do: it's buggy. You're not going to get the results you want. Should it be in Test::More? Perhaps it should be in Test::Tutorial. I don't know. I welcome suggestions. Strangely, it's not come up in the five years since I wrote Test::Builder. Does that mean that people don't care? Does that mean that it's not important? I don't know. > > Yes, it's common. That doesn't mean it's not broken. I'm not in the habit > > of voting whether to redefine wrong behavior as right because it's common. > If its so easy to use wrong then its probably deficient. I agree. > > I didn't say it was useful. I said it was correct. > Correct in some restricted definition. It correctly tells you where > the test procedure was called. It often tells you the wrong thing > about what failed in the test file. Then set $Level. It's a *hint*. I'm not arguing against good test descriptions. I'm arguing that if the reported test point is useless to you, someone didn't set $Level. > > For a value of "easily" defined as "by looking up the definition of the data > > structure in @tests and then reading further in the code until I find the > > point of the call", yes. > > What? If that test fails i will see the value of $test->[2] which will > be somewhere in the test file. How hard is that? I don't know, it depends on how difficult is to find and understand the code that set $test->[2]. It could be easy. It could be really difficult. > > I prefer to have two points of information for debugging this sort of test: > > the diagnostic and the line number and source file of the call point. > If i have the description i need neither. I can find everything else > quickly from that. IF you are lucky. > > > And Test::Builder isn't mentioned in Test::Simple at all (presumably > > > because it doesnt use it, in which case $Test::Builder::Level isnt going > > > to help.) > > That's quite an assumption. Write a test case. > Why, what does it matter? Its not mentioned in the docs of the module > so its not even relevent if it is or isnt in the context of this > discussion. You cant say "RTFM" when its not even in the FM. > > D:\dev\perl>perldoc Test::Simple | grep "Test::Builder" How does that prove that Test::Simple doesn't use Test::Builder? How does that prove that Test::Simple won't work if you set $Level? -- c
