Why think unit tests should be in their own source code hierarchy instead of side-by-side

Steven Schveighoffer schveiguy at yahoo.com
Sat Mar 24 11:19:55 UTC 2018


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


More information about the Digitalmars-d-announce mailing list