[phobos] Split std.datetime in two?

[Steve Schveighoffer]

It looks as though Jonathan is willing to roll up the code into loops, so having this debate is academic at this point, but I wanted to respond to some points.


----- Original Message -----
> From:Andrei Alexandrescu <andrei at erdani.com>
> 
> On Feb 11, 2011, at 2:39 PM, Steve Schveighoffer <schveiguy at yahoo.com> 
> wrote:

> > Please please, let's *NOT* make this a standard practice.  If a test 
> fails, I don't want to get a debugger out or start printf debugging *to find 
> the unit test*.  I want it to tell me where it failed, and focus on fixing the 
> problem.
> 
> You find the unittest alright. With coming improvements to assert you will often 
> see the arguments that caused the trouble.

This will help immensely.  Right now, you get a line number.  The rule should be, if a unit test fails, it should give you enough information to 1) find the failing assert and 2) give you all the information to understand why the assert failed.

> I don't understand how we both derive vastly different conclusions from the 
> same extensive eperience with unittests. To me a difficult unittest to find is a 
> crashing one; never ever once in my life I had problems figuring out why an 
> assert fails in a uniitrst, and worse, I am incapable to imagine such.

foreach(x; someLongArray)
  assert(foo(x) > 5);

which x caused the problem?  all I get is the line number for the assert.

BTW, I had this happen in Tango unit tests that used loops (ironically, when I was rewriting Tango's date/time code), I had to instrument the code with printfs which sucked IMO.

> > 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.

> >  If you want to find a function to read, use your editor's find 
> feature.  Some even can just allow you to click on the function and find the 
> definition.  This argument is a complete red herring
> 
> I find it a valid argument. I and I suspect many just browse code to get a feel 
> of it.

Which you can.  I think you can also get a feel for how well tested the library is also ("wow, look at all the unit tests...").

> > Good unit tests are independent and do not affect one another.  Jonathan is 
> right, it's simply a different goal for unit tests, you want easily isolated 
> blocks of code that are simple to understand so when something goes wrong you 
> can work through it in your head instead of figuring out how the unit test 
> works.
> 
> For me repeated code is worse by all metrics. There is zero advantages that it 
> has, and only troubles.

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.

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.

Having extra unit tests that do the same exact thing is not productive, I agree there.

Let's look at a different type of repetition -- version statements.  The nature of version statements sometimes forces one to sometimes repeat whole sections of code.  However, understanding the code is much easier than some of the horrific abuses of C preprocessor stuff that I've seen.  At some point, factoring out repetitive code becomes more harmful than the alternative.  I feel like unit tests are one of those cases.

> > *That* being said, I have not read through all the datetime unit tests, and 
> I don't know the nature of how many could be omitted.
> 
> Please do. I had a completely different opinion (virtually same as yours) before 
> making a thorough pass thru it. Again, like in the sorcerer's apprentice, 
> it's not about the deed, but instead the frightening scale at which the deed 
> is realized.

When I have time, I'll peruse it.

-Steve