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
