From: Yusuke ENDOH Date: 2008-10-08T20:57:38+09:00 Subject: [ruby-core:19201] Re: output format of miniunit Hi, thank you ryan for your reply. 2008/10/8 Ryan Davis : >> In addition, the output is helpful in terms of machine readablity. > > Except that it is not because the default inspect is # so wrapping > that up in an additional <> just makes it even harder to read. Well, I have to admit that's true. <#> is indeed hard to read a little. > Esp if that instance has fields that also use the default inspect. In this case the message is originally hard to read unless pp is not used. It is not a fault of additional <>. Though I still believe is helpful, I have no objective basis for persuading you. So I give up ... > EVERY assertion message is in the form of "Expected x, not y", it is > completely unambiguous (I was forced to write a lot of rspec style specs at > the time and was really tired of the ambiguous error messages), readable, > and uniform. Sorry, I can't get your point. For example, "Expected X to be empty" is not in that form literally, is it? Is the matter the order that expected value and actual one show? I don't know about rspec, but I wonder which message of test/unit is inconsistent and ambiguous. >>> and multiple lines harder to write processors >> >> Indeed, the current output of test/unit is harder to write processors. >> But I don't think the cause is multiple lines. Appropriate line feeds >> will be rather helpful to parse if you parse as line-at-a-time. > > which means you have to write a bunch of extra stuff to track the state of > your processor... OR, you can match a single regex and happily move on. Why doesn't miniunit support xml or yaml output option for machine processing if machine readability is taken into consideration so seriously? I think that Regexp is a bad idea for such a parser unless the parser is disposable. It's too ad-hoc. In addition, the result even in current format cannot be parsed uniquely (e.g., "Expected 1, not 1, not 1."). I think human readability is more important in default output than machine one. >>> PP is _really_really_ slow. too slow. By default miniunit should be as >>> fast >>> as freakin' possible. That means inspect. >> >> But the current implementation will build message string only when its >> test is failed. So it is not a problem, isn't it? > > It is when you change one thing that breaks a thousand tests at a time... > like I do. Speed is important when it is holding you back. Is it really common use case? In such a case, casual users would stop the test execution by pressing Ctrl+C before all errors are output, check the first several errors only, fix a bug and re-run the test. >> # In addition, speed is very very week reason for ruby... > > it is? how so? should all our code be as slow as possible? should I go back > to MS-BASIC on an 8Mhz processor? No. No to all these questions. In general, the faster the better. But when I talk about ruby's interface design, I think there is consensus that speed is much weaker than convenience. >>> If and where it doesn't look good, the user has every option to override: >>> >>> class TestMyVeryComplexObject < Test::Unit::TestCase >>> def mu_pp(obj) >>> pretty_inspect(obj).gsub(/[\w\/\.]+:\d+/, 'FILE:LINE') >>> end >>> end >>> >>> or... whatever the user wants. >> >> I want you to think that the users of miniunit is not only those who >> write tests but also those who only run tests. >> So it is important to switch mu_pp *without modifying test code*. >> The command-line option is needed at least, I think. > > SOMEONE wrote those tests. That someone can decide how best to represent an > error. in my case, where I have lots and lots of recursive datastructures, I > want to take the extra hit of something like pp in order to make things like > unit_diff more useful to me. In most of my tests tho (outside of my language > processing family of products), there is absolutely no reason so I decide to > go with the regular inspect. I think it's really nice to allow test developper to decide representation. I'm never denying the mechanism. I'm just suggesting that mu_pp uses pp as default or only when the command-line option is supplied. This is because all test developpers are not so earnest to consider good representation each time. In addition, there are already many test assets whose developpers expected pp to be used for error formatting. -- Yusuke ENDOH