On 3/23/18 9:54 PM, Tony wrote:

> I said my "original reply", meaning the one where I first mentioned Test-Driven Development. That was to something that Steven Schveighoffer said (although I did not reply directly to his message, but replied to his comment that was still in H.S. Teoh's message):
> 
> "I've worked on a project where the testing was separated from the code, and it was a liability IMO. Things would get missed and not tested properly."
> 
> He doesn't explicitly specify development or maintenance, but I assume it was development.

It was somewhat development and somewhat maintenance, but I was not using TDD. The code was already written, I was adding to it. I was also adding tests afterwards to make sure what I did worked properly.

In my case, I had no choice but to use separate files, as I was writing firmware for an embedded device, and the tests were running on the host PC (i.e. testing that when I communicated with the device, it was doing what I expected).

But even in my normal work where tests and the code run on the same system, my style of development just doesn't fit TDD, I often times don't know what the code or functionality is going to look like at the end when I'm done (I rewrote what eventually became iopipe 5 times because I wasn't sure of the best way to do it). I can see where if you use TDD, it would be OK to separate the tests from the program, but I still feel that the cost of having them separated from the code it's testing outweighs the benefits of less recompilations. I'm just not as picky as Atila when it comes to build time :)

-Steve

On 2018-03-23 21:43, H. S. Teoh wrote:

> Yep.  As I mentioned elsewhere, recently I've had to resort to external
> testing for one of my projects, and I'm still working on that right now.
> And already, I'm seeing a liability: rather than quickly locating a
> unittest immediately following a particular function, now I have to
> remember "oh which subdirectory was it that the tests were put in? and
> which file was it that a particular test of this function was done?".

Put the tests in a directory called "tests" and follow the same file and directory structure as the regular code.

It's just a matter of configuring a command in an editor that will find the corresponding test file and navigate to it. Or dump your editor if it doesn't support custom commands 'cos it sux and you deserve better. :-D  I mean, this is 2018, not 1995, we shouldn't have to be stuck with the handicap of clicking through files and directories to find the right test file anymore.

:D

-- 
/Jacob Carlborg

I really like `unittest`. It's my personal conviction that a developer should not be able to view the documentation, tests, or implementation for some part of a code base in isolation. `unittest` makes it easier for me to work this way.

Automated tests are vital for stability and documentation is vital for maintainability and making it possible for others to understand your code. But when they aren't right there in the same place as the implementation, I've noticed that it is the inevitable habit of developers to think of tests and documentation as second-class, if they are thought of at all. The developer updates the implementation and doesn't think to update the tests or the docs. This happens a few times. Then instead of updating the tests to work with the updated implementation, the tests are discarded as an inconvenience. And then end users become confused by docs that have since become inapplicable.

On Sun, Mar 25, 2018 at 04:22:32PM +0000, pineapple via Digitalmars-d-announce wrote:
> I really like `unittest`. It's my personal conviction that a developer should not be able to view the documentation, tests, or implementation for some part of a code base in isolation. `unittest` makes it easier for me to work this way.
> 
> Automated tests are vital for stability and documentation is vital for maintainability and making it possible for others to understand your code.  But when they aren't right there in the same place as the implementation, I've noticed that it is the inevitable habit of developers to think of tests and documentation as second-class, if they are thought of at all. The developer updates the implementation and doesn't think to update the tests or the docs. This happens a few times. Then instead of updating the tests to work with the updated implementation, the tests are discarded as an inconvenience. And then end users become confused by docs that have since become inapplicable.

Exactly. This is why inline unittests are one of the best design decisions ever made in D.  Along with built-in documentation (in spite of all ddoc's warts).

Before D, almost none of my code was ever thoroughly tested -- I just couldn't be bothered to install, setup, write, and then keep in-sync a separate unittesting system. Ditto for a documentation system.  I tried DOxygen for one project, but it did not even get past writing a Doxyfile. :-(  Fortunately, now I'm in the process of migrating that project from C++ to D, and now I have 90%+ test coverage, integrated into the build system so that it will fail loudly should any test fail. A large part of the tests are inline unittests -- otherwise they would just be too cumbersome to maintain and I would've given up long ago. (The external testsuite is there only out of necessity, due to the original C++ design; if I had the started from a blank slate, I would've hands-down preferred inline unittests.)

D's unittests and inline docs (in spite of said warts) have significantly (and measurably) improved the quality of my code. And the fundamental reason is exactly as you said: proximity to the actual code make a huge difference.  External docs does have the tendency of quickly falling out-of-date, and external tests tend to get ignored and eventually thrown out -- I've seen this with my own eyes in large projects with large numbers of developers, where the code simply changes way too fast for any external docs/tests to be kept up-to-date without lots of external motivation (like an angry manager holding threats over your head, :-P or an irate QA department complaining about regressions).


T

-- 
Philosophy: how to make a career out of daydreaming.

On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote:
> On 3/22/18 6:59 AM, Atila Neves wrote:
>> Blog post:
>> 
>> https://atilanevesoncode.wordpress.com/
>> 
>> Atila
>
> It's simple. Unittests in imported modules should not be visible. They should be compiled as if -unittest was not passed.
>
> Even Walter and Andrei are supportive: https://github.com/dlang/dmd/pull/6375#issuecomment-373487247
>
> -Steve

That would completely break __traits(getUnitTests).

Atila

On 3/26/18 9:26 AM, Atila Neves wrote:
> On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote:
>> On 3/22/18 6:59 AM, Atila Neves wrote:
>>> Blog post:
>>>
>>> https://atilanevesoncode.wordpress.com/
>>>
>>> Atila
>>
>> It's simple. Unittests in imported modules should not be visible. They should be compiled as if -unittest was not passed.
>>
>> Even Walter and Andrei are supportive: https://github.com/dlang/dmd/pull/6375#issuecomment-373487247
>>
> 
> That would completely break __traits(getUnitTests).

I'm sure we could find a way to keep the features here, 99.99% of the time, you don't care about, nor want to parse or semantic, an imported module's unit tests. Only specialized unit test frameworks care about this feature.

It could be as simple as, if you use __traits(getUnitTests, modulename) anywhere in a module, then that module is imported the traditional way. Or we could create a specialized "import unittest" syntax for this purpose.

I think we can have the best of both worlds, with the common case being preferred.

-Steve

On Tue, Mar 27, 2018 at 09:27:16AM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote:
> On 3/26/18 9:26 AM, Atila Neves wrote:
> > On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote:
[...]
> > > It's simple. Unittests in imported modules should not be visible. They should be compiled as if -unittest was not passed.
> > > 
> > > Even Walter and Andrei are supportive: https://github.com/dlang/dmd/pull/6375#issuecomment-373487247
> > > 
> > 
> > That would completely break __traits(getUnitTests).
> 
> I'm sure we could find a way to keep the features here, 99.99% of the time, you don't care about, nor want to parse or semantic, an imported module's unit tests. Only specialized unit test frameworks care about this feature.
> 
> It could be as simple as, if you use __traits(getUnitTests, modulename) anywhere in a module, then that module is imported the traditional way. Or we could create a specialized "import unittest" syntax for this purpose.
[...]

Yeah, since __traits(getUnitTests) is inside the compiler, it could in
theory be as simple as:

	- `import abc;` - compiler lexes and parses abc, but leaves
	  unittests alone (but still present as AST nodes with no
	  semantic run). Basically, module abc is parsed as if
	  `-unittest` is not present.

	- `__traits(getUnitTests)` triggers semantic on unittest AST
	  nodes of the target module.

Does __traits(getUnitTests) work if you don't specify `-unittest`? If so, then the solution is probably already there.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.