----- Original Message ----- > From:Andrei Alexandrescu <[email protected]> > > > ----- Original Message ----- > >> From:Andrei Alexandrescu<[email protected]> > >> > >> On Feb 11, 2011, at 2:39 PM, Steve > Schveighoffer<[email protected]> > >> wrote: > > > > assert(foo(x)> 5); > > > > which x caused the problem? all I get is the line number for the assert. > > When the unittest fails I go and edit the code as such: > > assert(foo(x), text("foo(", x, ") failed"));
As long as the unit test looks like this to begin with, I have no problem. It should be the responsibility of the unit test writer to make sure the error messages clearly indicate what inputs cause the error. I also want to stress that this is a simple loop example, and not too difficult to understand. I don't think complex factored code is a good idea to have. BTW, where is text defined? It should be available everywhere. > >>> I don't sympathize with you, we have tools to easily do this > without > >> much burden. > >> > >> A little while ago you didn't care to start a debugger or use > writeln - two > >> simple tools. I cry double standard. > > > > Um.. how are you reading the code if not using an editor? Using ctrl-F and > typing in the function name is several orders of magnitude simpler than > adding > writelns, recompiling, or recompiling in debug mode (I'm counting the part > where you have to dissect the makefile to figure out how to put the thing in > debug mode in the first place) and debugging. It's like saying the burden > of using the claw of a hammer that's already in your hand is the same as > going to get a reciprocating saw to remove a nail. It's not even close to a > double standard. > > How are you debugging code if not using stdio or a debugger? It's an extra cycle to find the error conditions. Essentially, I have to first instrument the unit test to find out what is failing, then go instrument the function that is failing. Sometimes, I don't even need to do that, I can see the problem and just fix it, requiring no debugging. > > Then I guess we differ. I prefer to have unit tests be simple statements > that are easily proven mentally without much context. Complex code is more > difficult to reason about, and as spir said, we don't want to have to unit > test our unit tests. > > A simple loop is simpler than 100 unrolled instances of it. Only if you are reading all 100 instances. When a unit test fails, I only care about 1. When reading code, I skip all unit tests, be they a loop of 100 or 100 individual ones. > > > I attach to this statement that the unit tests should test *different* > things even if they look repetitive. For example, testing two corner cases > might look very repetitive, but they both are looking for weaknesses in > different places. > > I am certain that the unittests in std.datetime are well beyond 100% code > coverage. IMHO they should stop at 100% coverage (which is probably at 20% of > their size). I cannot give an opinion on the coverage, but I agree that they should stop at 100%. > > Again, I feel like you do, save the numbers. Let me give you an example. Many > would agree that sex is good. Yet few would agree that being required to > perform > it for 12 hours can be terrible. Eating is good too. Eating seven pounds of > even > the best food is a horrific experience. I'm sure you meant something different about the sex analogy :) I think these analogies are not relevant. One does not read scores of unit test, and writing a loop does not prevent you from having to come up with all the unit tests. > There is a limit to everything. That limit has been passed many times over by > the unittests in std.datetime. The limit should be 100% coverage. If std.datetime passes that, it should be trimmed. -Steve ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
