----- Original Message -----
> From:Andrei Alexandrescu <andrei at erdani.com>
> std.datetime has 34219 lines, which accounts for over 26% of the entire Phobos
> size. If Jonathan will (as he promised, I didn't forget :o)) fix line sizes
> to conform to 80 columns, then std.datetime will become 40961 lines, or straight
> 30% of Phobos.
> 
> (This might have to do with the increase of "hello, world" that was noted by some people on the compiler list.)

I don't think so, but I cannot be sure. I'd say a full 75-90% of std.datetime is unit tests or documentation.  That shouldn't increase the size of the lib, and certainly not by as much as it does.

If it is to blame, maybe there is something wrong with the compiler still including unittest code for -lib or something...

> I understand there are factors that contribute to that: date and time manipulation is a bulky endeavor, there's a ton of unittests, and there's a lot of documentation. But at a level I find it difficult to digest the fact that in sheer numbers date and time manipulation accounts for 30% of Phobos. As a comparison point, std.algorithm does arguably a lot of work, has adequate documentation, and has unittest coverage at 95%, yet does all that in a "measly" 8027 lines.

Lines of file does not mean % of a library, especially when a large portion of it is not compiled.  I think we need to stop this prejudice against uncompiled LOC.  I fully support having unit tests next to the code being tested, it's the whole point of the builtin unit test system in D.

Bottom line, the doc generator should do a better job of generating documentation, so we don't *have* to open the file, and if std.datetime is adding too much binary to the exe, we should fix whatever problems dmd is likely having there.

-Steve

On 02/10/2011 04:50 PM, Steve Schveighoffer wrote:
> Bottom line, the doc generator should do a better job of generating documentation, so we don't*have*  to open the file, and if std.datetime is adding too much binary to the exe, we should fix whatever problems dmd is likely having there.

I recently fell by chance on a doc generator for D (yes!) that includes the source of each func, *folded*, in the generated html. Greatissime.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 10 feb 2011, at 18:55, spir wrote:

> On 02/10/2011 04:50 PM, Steve Schveighoffer wrote:
>> Bottom line, the doc generator should do a better job of generating documentation, so we don't*have*  to open the file, and if std.datetime is adding too much binary to the exe, we should fix whatever problems dmd is likely having there.
> 
> I recently fell by chance on a doc generator for D (yes!) that includes the source of each func, *folded*, in the generated html. Greatissime.

I think Dil can to that, or it's a python script included with Dil. Anyway Tango has that and it uses Dil to generate its documentation.

> Denis
> -- 
> _________________
> vita es estrany
> spir.wikidot.com
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

On 10 February 2011 16:50, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> ----- Original Message -----
>> From:Andrei Alexandrescu <andrei at erdani.com>
>> std.datetime has 34219 lines, which accounts for over 26% of the entire Phobos
>> size. If Jonathan will (as he promised, I didn't forget :o)) fix line sizes
>> to conform to 80 columns, then std.datetime will become 40961 lines, or straight
>> 30% of Phobos.
>>
>> (This might have to do with the increase of "hello, world" that was noted by some people on the compiler list.)
>
> I don't think so, but I cannot be sure. I'd say a full 75-90% of std.datetime is unit tests or documentation. ?That shouldn't increase the size of the lib, and certainly not by as much as it does.

I'm almost certain that it is the cause, though this is not
std.datetime's fault.
Evidence from the map file shows that the executable size is roughly
proportional to the number of lines of code in Phobos...
The deeper cause is that the linker is failing miserably, it hardly
discards anything.

> If it is to blame, maybe there is something wrong with the compiler still including unittest code for -lib or something...
>
>> I understand there are factors that contribute to that: date and time
>> manipulation is a bulky endeavor, there's a ton of unittests, and
>> there's a lot of documentation. But at a level I find it difficult to digest
>> the fact that in sheer numbers date and time manipulation accounts for 30% of
>> Phobos. As a comparison point, std.algorithm does arguably a lot of work, has
>> adequate documentation, and has unittest coverage at 95%, yet does all that in a
>> "measly" 8027 lines.
>
> Lines of file does not mean % of a library, especially when a large portion of it is not compiled. ?I think we need to stop this prejudice against uncompiled LOC. ?I fully support having unit tests next to the code being tested, it's the whole point of the builtin unit test system in D.
>
> Bottom line, the doc generator should do a better job of generating documentation, so we don't *have* to open the file, and if std.datetime is adding too much binary to the exe, we should fix whatever problems dmd is likely having there.

Yes, but on the other hand..
(1) There has to be a maximum acceptable source file size.
Personally I start to feel uncomfortable above 2000 lines, and get an
uncontrollable urge to split at 5000 lines.  That's just me, but I
suggest all modules should be short. And at 35000 lines,
std.datetime.length > short.max.

(2) Actually, it seems that most of size actually comes because every
test is written 'by hand'. If they were done as arrays [parameter1,
parameter2, result]...
with a loop, they'd be a lot shorter. (I crunched down the
std.math.exp tests enormously by doing this). Looking at that module,
I get the feeling that there's been a lot of cut-and-paste.
It is a little disconcerting if D really cannot write unittesting code
concisely. If it really needs to be that big, that part of the
language needs more work; or we need more helper functions. Or both.

On 2/10/11 3:44 PM, Don Clugston wrote:
> (1) There has to be a maximum acceptable source file size. Personally I start to feel uncomfortable above 2000 lines, and get an uncontrollable urge to split at 5000 lines.  That's just me, but I suggest all modules should be short. And at 35000 lines, std.datetime.length>  short.max.

Agreed.

> (2) Actually, it seems that most of size actually comes because every
> test is written 'by hand'. If they were done as arrays [parameter1,
> parameter2, result]...
> with a loop, they'd be a lot shorter. (I crunched down the
> std.math.exp tests enormously by doing this). Looking at that module,
> I get the feeling that there's been a lot of cut-and-paste.
> It is a little disconcerting if D really cannot write unittesting code
> concisely. If it really needs to be that big, that part of the
> language needs more work; or we need more helper functions. Or both.

Agreed. People will look at Phobos for inspiration in terms of style and idioms. If they see they're looking at more than 2x the size of the code for adding tests, probably they'd feel intimidated.

Peeking at std.datetime's unittests, I confirm they are very repetitive - essentially unrolled loops. I just set the bar somewhat halfway and saw the following. I mean come on!


Andrei

             assertThrown!DateTimeException(Date.fromISOString(""));
             assertThrown!DateTimeException(Date.fromISOString("990704"));
             assertThrown!DateTimeException(Date.fromISOString("0100704"));
             assertThrown!DateTimeException(Date.fromISOString("2010070"));
             assertThrown!DateTimeException(Date.fromISOString("2010070 "));

assertThrown!DateTimeException(Date.fromISOString("120100704"));
             assertThrown!DateTimeException(Date.fromISOString("-0100704"));
             assertThrown!DateTimeException(Date.fromISOString("+0100704"));
             assertThrown!DateTimeException(Date.fromISOString("2010070a"));
             assertThrown!DateTimeException(Date.fromISOString("20100a04"));
             assertThrown!DateTimeException(Date.fromISOString("2010a704"));

             assertThrown!DateTimeException(Date.fromISOString("99-07-04"));

assertThrown!DateTimeException(Date.fromISOString("010-07-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-07-0"));

assertThrown!DateTimeException(Date.fromISOString("2010-07-0 "));

assertThrown!DateTimeException(Date.fromISOString("12010-07-04"));

assertThrown!DateTimeException(Date.fromISOString("-010-07-04"));

assertThrown!DateTimeException(Date.fromISOString("+010-07-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-07-0a"));

assertThrown!DateTimeException(Date.fromISOString("2010-0a-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-a7-04"));

assertThrown!DateTimeException(Date.fromISOString("2010/07/04"));

assertThrown!DateTimeException(Date.fromISOString("2010/7/04"));
             assertThrown!DateTimeException(Date.fromISOString("2010/7/4"));

assertThrown!DateTimeException(Date.fromISOString("2010/07/4"));

assertThrown!DateTimeException(Date.fromISOString("2010-7-04"));
             assertThrown!DateTimeException(Date.fromISOString("2010-7-4"));

assertThrown!DateTimeException(Date.fromISOString("2010-07-4"));

             assertThrown!DateTimeException(Date.fromISOString("99Jul04"));
             assertThrown!DateTimeException(Date.fromISOString("010Jul04"));
             assertThrown!DateTimeException(Date.fromISOString("2010Jul0"));
             assertThrown!DateTimeException(Date.fromISOString("2010Jul0
"));

assertThrown!DateTimeException(Date.fromISOString("12010Jul04"));

assertThrown!DateTimeException(Date.fromISOString("-010Jul04"));

assertThrown!DateTimeException(Date.fromISOString("+010Jul04"));

assertThrown!DateTimeException(Date.fromISOString("2010Jul0a"));

assertThrown!DateTimeException(Date.fromISOString("2010Jua04"));

assertThrown!DateTimeException(Date.fromISOString("2010aul04"));


assertThrown!DateTimeException(Date.fromISOString("99-Jul-04"));

assertThrown!DateTimeException(Date.fromISOString("010-Jul-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-Jul-0"));

assertThrown!DateTimeException(Date.fromISOString("2010-Jul-0 "));

assertThrown!DateTimeException(Date.fromISOString("12010-Jul-04"));

assertThrown!DateTimeException(Date.fromISOString("-010-Jul-04"));

assertThrown!DateTimeException(Date.fromISOString("+010-Jul-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-Jul-0a"));

assertThrown!DateTimeException(Date.fromISOString("2010-Jua-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-Jal-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-aul-04"));


assertThrown!DateTimeException(Date.fromISOString("2010-07-04"));

assertThrown!DateTimeException(Date.fromISOString("2010-Jul-04"));

             assertPred!"=="(Date.fromISOString("19990706"), Date(1999,
7, 6));
             assertPred!"=="(Date.fromISOString("-19990706"),
Date(-1999, 7, 6));
             assertPred!"=="(Date.fromISOString("+019990706"),
Date(1999, 7, 6));
             assertPred!"=="(Date.fromISOString("19990706 "), Date(1999,
7, 6));
             assertPred!"=="(Date.fromISOString(" 19990706"), Date(1999,
7, 6));
             assertPred!"=="(Date.fromISOString(" 19990706 "),
Date(1999, 7, 6));

             //Verify Examples.
             assert(Date.fromISOString("20100704") == Date(2010, 7, 4));
             assert(Date.fromISOString("19981225") == Date(1998, 12, 25));
             assert(Date.fromISOString("00000105") == Date(0, 1, 5));
             assert(Date.fromISOString("-00040105") == Date(-4, 1, 5));
             assert(Date.fromISOString(" 20100704 ") == Date(2010, 7, 4));

On 2/10/11 9:50 AM, Steve Schveighoffer wrote:
> ----- Original Message -----
>> From:Andrei Alexandrescu<andrei at erdani.com>
>> std.datetime has 34219 lines, which accounts for over 26% of the entire Phobos
>> size. If Jonathan will (as he promised, I didn't forget :o)) fix line sizes
>> to conform to 80 columns, then std.datetime will become 40961 lines, or straight
>> 30% of Phobos.
>>
>> (This might have to do with the increase of "hello, world" that was noted by some people on the compiler list.)
>
> I don't think so, but I cannot be sure. I'd say a full 75-90% of std.datetime is unit tests or documentation.  That shouldn't increase the size of the lib, and certainly not by as much as it does.

It increases the size of the source that someone looking at the library must navigate and absorb.

In case I wasn't clear: my concern is source size. I am now sorry I mentioned library size, and twice so because I didn't verify the hypothesis.

It is difficult to believe that a library needs that much unittests in terms of sheer size. The more I browse through std.datetime, the more firmly my hair is standing up on my head. It's most all large hand-unrolled loops. I am now sorry I voted for the library without having raised a flag at this very serious problem. I didn't realize its size back then.

>> I understand there are factors that contribute to that: date and time
>> manipulation is a bulky endeavor, there's a ton of unittests, and
>> there's a lot of documentation. But at a level I find it difficult to digest
>> the fact that in sheer numbers date and time manipulation accounts for 30% of
>> Phobos. As a comparison point, std.algorithm does arguably a lot of work, has
>> adequate documentation, and has unittest coverage at 95%, yet does all that in a
>> "measly" 8027 lines.

> Lines of file does not mean % of a library, especially when a large portion of it is not compiled.  I think we need to stop this prejudice against uncompiled LOC.  I fully support having unit tests next to the code being tested, it's the whole point of the builtin unit test system in D.

I am sorry, I disagree with discounting LOC. LOC is LOC. Compiled or uncompiled it is intellectual overhead. We need to write good code, code that we provide as living examples on how to write quality programs. Good code is not unrolled loops. Well, except sometimes :o).

> Bottom line, the doc generator should do a better job of generating documentation, so we don't *have* to open the file, and if std.datetime is adding too much binary to the exe, we should fix whatever problems dmd is likely having there.

I agree.


Andrei

On 02/10/2011 11:02 PM, Andrei Alexandrescu wrote:
> On 2/10/11 3:44 PM, Don Clugston wrote:
>> (1) There has to be a maximum acceptable source file size. Personally I start to feel uncomfortable above 2000 lines, and get an uncontrollable urge to split at 5000 lines. That's just me, but I suggest all modules should be short. And at 35000 lines, std.datetime.length> short.max.
>
> Agreed.
>
>> (2) Actually, it seems that most of size actually comes because every
>> test is written 'by hand'. If they were done as arrays [parameter1,
>> parameter2, result]...
>> with a loop, they'd be a lot shorter. (I crunched down the
>> std.math.exp tests enormously by doing this). Looking at that module,
>> I get the feeling that there's been a lot of cut-and-paste.
>> It is a little disconcerting if D really cannot write unittesting code
>> concisely. If it really needs to be that big, that part of the
>> language needs more work; or we need more helper functions. Or both.
>
> Agreed. People will look at Phobos for inspiration in terms of style and idioms. If they see they're looking at more than 2x the size of the code for adding tests, probably they'd feel intimidated.
>
> Peeking at std.datetime's unittests, I confirm they are very repetitive - essentially unrolled loops. I just set the bar somewhat halfway and saw the following. I mean come on!
>
>
> Andrei
>
> assertThrown!DateTimeException(Date.fromISOString(""));
> assertThrown!DateTimeException(Date.fromISOString("990704"));
> assertThrown!DateTimeException(Date.fromISOString("0100704"));
> assertThrown!DateTimeException(Date.fromISOString("2010070"));
> assertThrown!DateTimeException(Date.fromISOString("2010070 "));
> [...]

I'm interested in this example. I mean how can this happen? What we would never
do in regular (if only because we're lazy, and even copy+paste sucks for more
than a few repetitions), we happily do as soon as the /context/ is somehow
different; eg unittests. Just like if unittest were not code.
I've read similar patterns in code by very high-level programmers. There are
even test-case generating tools that produce such code.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Thursday, February 10, 2011 15:00:50 spir wrote:
> On 02/10/2011 11:02 PM, Andrei Alexandrescu wrote:
> > On 2/10/11 3:44 PM, Don Clugston wrote:
> >> (1) There has to be a maximum acceptable source file size. Personally I start to feel uncomfortable above 2000 lines, and get an uncontrollable urge to split at 5000 lines. That's just me, but I suggest all modules should be short. And at 35000 lines, std.datetime.length> short.max.
> > 
> > Agreed.
> > 
> >> (2) Actually, it seems that most of size actually comes because every
> >> test is written 'by hand'. If they were done as arrays [parameter1,
> >> parameter2, result]...
> >> with a loop, they'd be a lot shorter. (I crunched down the
> >> std.math.exp tests enormously by doing this). Looking at that module,
> >> I get the feeling that there's been a lot of cut-and-paste.
> >> It is a little disconcerting if D really cannot write unittesting code
> >> concisely. If it really needs to be that big, that part of the
> >> language needs more work; or we need more helper functions. Or both.
> > 
> > Agreed. People will look at Phobos for inspiration in terms of style and idioms. If they see they're looking at more than 2x the size of the code for adding tests, probably they'd feel intimidated.
> > 
> > Peeking at std.datetime's unittests, I confirm they are very repetitive - essentially unrolled loops. I just set the bar somewhat halfway and saw the following. I mean come on!
> > 
> > 
> > Andrei
> > 
> > assertThrown!DateTimeException(Date.fromISOString(""));
> > assertThrown!DateTimeException(Date.fromISOString("990704"));
> > assertThrown!DateTimeException(Date.fromISOString("0100704"));
> > assertThrown!DateTimeException(Date.fromISOString("2010070"));
> > assertThrown!DateTimeException(Date.fromISOString("2010070 "));
> > [...]
> 
> I'm interested in this example. I mean how can this happen? What we would never do in regular (if only because we're lazy, and even copy+paste sucks for more than a few repetitions), we happily do as soon as the /context/ is somehow different; eg unittests. Just like if unittest were not code. I've read similar patterns in code by very high-level programmers. There are even test-case generating tools that produce such code.

Unit tests need to be simple. If they're more complicated, the risk of getting them wrong goes up. Also, as Steve points out, determining _what_ failed can be a royal pain when you try and put something in a loop. Helper functions help with that, but it's still a pain.

Normal code can afford to be more complex - _especially_ if it's well unit tested. But if you make complicated unit tests, then pretty soon you have a major burden in making sure that your tests are correct rather than your code. In the case above, it's testing 5 things, so it's 5 lines. It's simple and therefore less error prone. Unit tests really should favor simplicity and correctness over reduced line count or increased cleverness. The goal of unit testing code is inherently different from normal code. _That_ is why unit testing code is written differently from normal code.

- Jonathan M Davis

On 02/11/2011 12:34 AM, Jonathan M Davis wrote:
> On Thursday, February 10, 2011 15:00:50 spir wrote:
>> On 02/10/2011 11:02 PM, Andrei Alexandrescu wrote:
>>> On 2/10/11 3:44 PM, Don Clugston wrote:
>>>> (1) There has to be a maximum acceptable source file size. Personally I start to feel uncomfortable above 2000 lines, and get an uncontrollable urge to split at 5000 lines. That's just me, but I suggest all modules should be short. And at 35000 lines, std.datetime.length>  short.max.
>>>
>>> Agreed.
>>>
>>>> (2) Actually, it seems that most of size actually comes because every
>>>> test is written 'by hand'. If they were done as arrays [parameter1,
>>>> parameter2, result]...
>>>> with a loop, they'd be a lot shorter. (I crunched down the
>>>> std.math.exp tests enormously by doing this). Looking at that module,
>>>> I get the feeling that there's been a lot of cut-and-paste.
>>>> It is a little disconcerting if D really cannot write unittesting code
>>>> concisely. If it really needs to be that big, that part of the
>>>> language needs more work; or we need more helper functions. Or both.
>>>
>>> Agreed. People will look at Phobos for inspiration in terms of style and idioms. If they see they're looking at more than 2x the size of the code for adding tests, probably they'd feel intimidated.
>>>
>>> Peeking at std.datetime's unittests, I confirm they are very repetitive - essentially unrolled loops. I just set the bar somewhat halfway and saw the following. I mean come on!
>>>
>>>
>>> Andrei
>>>
>>> assertThrown!DateTimeException(Date.fromISOString(""));
>>> assertThrown!DateTimeException(Date.fromISOString("990704"));
>>> assertThrown!DateTimeException(Date.fromISOString("0100704"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070 "));
>>> [...]
>>
>> I'm interested in this example. I mean how can this happen? What we would never do in regular (if only because we're lazy, and even copy+paste sucks for more than a few repetitions), we happily do as soon as the /context/ is somehow different; eg unittests. Just like if unittest were not code. I've read similar patterns in code by very high-level programmers. There are even test-case generating tools that produce such code.
>
> Unit tests need to be simple. If they're more complicated, the risk of getting them wrong goes up. Also, as Steve points out, determining _what_ failed can be a royal pain when you try and put something in a loop. Helper functions help with that, but it's still a pain.
>
> Normal code can afford to be more complex - _especially_ if it's well unit tested. But if you make complicated unit tests, then pretty soon you have a major burden in making sure that your tests are correct rather than your code. In the case above, it's testing 5 things, so it's 5 lines. It's simple and therefore less error prone. Unit tests really should favor simplicity and correctness over reduced line count or increased cleverness. The goal of unit testing code is inherently different from normal code. _That_ is why unit testing code is written differently from normal code.

Thank you for your answer, Jonathan, makes much sense. Looks like the famous "who controls the controller" ;-) Your answer beeing "let us make the controller do its task in shuch a way that it does not require (much) control".

denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Feb 11, 2011, at 12:34 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Thursday, February 10, 2011 15:00:50 spir wrote:
>> On 02/10/2011 11:02 PM, Andrei Alexandrescu wrote:
>>> On 2/10/11 3:44 PM, Don Clugston wrote:
>>>> (1) There has to be a maximum acceptable source file size.
>>>> Personally I start to feel uncomfortable above 2000 lines, and
>>>> get an
>>>> uncontrollable urge to split at 5000 lines. That's just me, but I
>>>> suggest all modules should be short. And at 35000 lines,
>>>> std.datetime.length> short.max.
>>>
>>> Agreed.
>>>
>>>> (2) Actually, it seems that most of size actually comes because
>>>> every
>>>> test is written 'by hand'. If they were done as arrays [parameter1,
>>>> parameter2, result]...
>>>> with a loop, they'd be a lot shorter. (I crunched down the
>>>> std.math.exp tests enormously by doing this). Looking at that
>>>> module,
>>>> I get the feeling that there's been a lot of cut-and-paste.
>>>> It is a little disconcerting if D really cannot write unittesting
>>>> code
>>>> concisely. If it really needs to be that big, that part of the
>>>> language needs more work; or we need more helper functions. Or
>>>> both.
>>>
>>> Agreed. People will look at Phobos for inspiration in terms of
>>> style and
>>> idioms. If they see they're looking at more than 2x the size of
>>> the code
>>> for adding tests, probably they'd feel intimidated.
>>>
>>> Peeking at std.datetime's unittests, I confirm they are very
>>> repetitive -
>>> essentially unrolled loops. I just set the bar somewhat halfway
>>> and saw
>>> the following. I mean come on!
>>>
>>>
>>> Andrei
>>>
>>> assertThrown!DateTimeException(Date.fromISOString(""));
>>> assertThrown!DateTimeException(Date.fromISOString("990704"));
>>> assertThrown!DateTimeException(Date.fromISOString("0100704"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070 "));
>>> [...]
>>
>> I'm interested in this example. I mean how can this happen? What we
>> would
>> never do in regular (if only because we're lazy, and even copy
>> +paste sucks
>> for more than a few repetitions), we happily do as soon as the /
>> context/
>> is somehow different; eg unittests. Just like if unittest were not
>> code.
>> I've read similar patterns in code by very high-level programmers.
>> There
>> are even test-case generating tools that produce such code.
>
> Unit tests need to be simple. If they're more complicated, the risk
> of getting
> them wrong goes up. Also, as Steve points out, determining _what_
> failed can be
> a royal pain when you try and put something in a loop. Helper
> functions help
> with that, but it's still a pain.

Not taking one femtosecond to believe that. The hard part is to get the unittest to fail. Once it fails, it is all trivial. Insert a writeln or use a debugger.

>
> Normal code can afford to be more complex - _especially_ if it's
> well unit
> tested. But if you make complicated unit tests, then pretty soon you
> have a
> major burden in making sure that your tests are correct rather than
> your code.

I am now having a major burden finding the code that does work in a sea of chaff.

>
> In the case above, it's testing 5 things, so it's 5 lines. It's
> simple and
> therefore less error prone. Unit tests really should favor
> simplicity and
> correctness over reduced line count or increased cleverness.

All code should do that. This is a false choice. Good code must go inside unittest and outside unittest.

> The goal of unit
> testing code is inherently different from normal code. _That_ is why
> unit testing
> code is written differently from normal code.

Not buying it. Unittest code is not exempt from simple good coding principles such as avoiding copy and paste.
>

Andrei