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