Hacker News Reader

Comment by morganherlocker | Hacker News Reader

Just about everyone writes tests first. You have some sort of script that you are running against the real code you are working on to see if it is doing what it should be doing. The only real difference between true "TDD" and everyone else, is that the TDD folks save this script to be run later.

I might be so far down the TDD trail that I have lost perspective, but do people really write huge swaths of code without writing scripts to run the code and see what it is doing? Those little scripts are tests, and with a tiny bit of formatting, they can be made to output something consistently useful like TAP[1], instead of inconsistent console logs. This whole debate seems like strawmen fighting strawmen.

[1] http://testanything.org/

View on HN

I haven't heard about people writing some sort of scripts to run "against" the real code. Most people do manual integration testing by running the application, and doing some light debugging, and then when it starts to work, write a few tests (if any).

I do it, except they're not scripts, but really high level functions and objects/processes that create and delete themselves. And although I'm not explicitly TDD at all, those functions often end up becoming tests (or informing test writing) by production time.

Applications I write are ultimately experiments in the interop of N different libraries that I haven't used in quite this combination before, so the first code I write is usually checking to see if things will work in combination in the way that I think they will. That involves writing code that has the stripped down functionality of the parts of the design that I thought could benefit by using those libraries.

The last thing I finalize is the highest level logic, and by the time I write it, I know it's going to work.

Imagine if they could codify their manual integration tests in such a way that they could be automated? Not necessarily a unit test, but still a test. Likely a valuable one.

Yes, obviously we do that, but after the feature is working. It's not practical to write it before implementing it at least with the stack I'm working on currently. We use Selenium+Protractor for integration tests, and these tests are implementation specific.

TDD has two general meanings. The original, and strictest, says that each test is written and part of the test suite before writing any feature code.

It's also more loosely taken to mean anything which isn't test-last. The underlying idea of many, though wrong, is that in the old days, people wrote all their code before testing it, and in this modern era we know developers should write automated tests during the development phase.

However, I think it's unwise to mix those two terms. What you describe - running some code in order to verify new features during development - has a long history independent of TDD, as your own TAP example, dating from 1987, points out.

Reply on news.ycombinator.com