Pure TDD is, as the others have said, to write the tests first. If you aren't writing code to fix a broken test you are doing it wrong.
TDD, though, is really a learning system. The main point is writing the code with testability in mind. You can write them together and get the same results as long as you do that. It keeps the code loosely coupled and the APIs clean.
So, IMO, you can still call it TDD as long as you are writing the code and tests together and are writing the code with the tests in mind. You can do that with the pure TDD or with some variant as long as the result is the same. I guess it depends whether you are referring to the general style or the specific learning methodology.
Unless you're writing super functional stuff, I don't understand how you could reasonably apply TDD when developing user interfaces: I target web, but the same could hold for mobile and other devices.
Because, what exactly is the contract? Do I essentially write integration tests to the effect of "If I click input element with css class .username, type 'x', and then click input element with class .password, then type 'y', then click the button with class .login, the page URL has changed from <mysite.com>/login to <mysite.com>/profile?"
There are no clear API interfaces for UIs. A user wouldn't really care that the button had class .username on it, for example -- that just gives us some way to identify the correct DOM element to perform the e2e test against. And some day, a developer could rename that class name, and it'd break the e2e test.
In other words, I can't assumption what TDD looks like for user interfaces, without the whole testing process seeming extremely brittle. Contrast this with, if I call some REST API, I expect this response body. It's quite concrete.
I don't think it is that much different, just maybe in proportions. In pretty much every application I write there 2 types of code. There is the guts or business logic that is written in the style of a library making it very testable. The other is the top level code, the 'main loop'. This is just there to hook together the library code in as short a way as possible. I think UI code differs in that it tends to have quite a bit more of this top level code that is basically un-testable except for very high level integration/scripted tests and QA testing. But UI code still has some amount of the library/logic code that can be written with testing in mine. I think this speaks to the myth that 100% test coverage is desirable and good. It is not.
> It keeps the code loosely coupled and the APIs clean.
Having seen some of the interesting designs of less-experienced devs, I disagree that this is a benefit of TDD. TDD may help straighten out some of your thoughts if you already have loose coupling in mind, but it won't work if the dev doesn't already have some experience there.
As a veteran (20+ years) programmer I've yet to witness a project where tests are written before the code for the entire duration of the implementation. I personally feel TDD is the snake oil you need to sell to get your team to do write unit tests for max coverage.
> As a veteran (20+ years) programmer I've yet to witness a project where tests are written before the code for the entire duration of the implementation.
Did you made any effort to adopt and enforce TDD? Because, like any good practice, unless someone drives adoption then things tend to stay the way they are.
Of course I did but like any other process if there has to be complete adoption the benefits need to be clearly visible and significant. The problem with pure TDD (and remember that's what I am talking about - writing / updating tests before writing any code), is that there are diminishing returns as soon as the code base becomes a certain size. In fact, at some point the costs flip around to be higher than the benefits (ie: updating code before tests becomes significantly more efficient than the other way around).
In my experience, it has always been easier for multiple developers working on a code base to write the tests once the implementation has been fleshed out and a significant portion of it is 'ready'.
Doing TDD one should have a strong preference to write the test first. But really, in this discussion, which frequently happens on this forum the most important thing is often left out. What people are not talking about is that there also is a refactoring step in the cycle. To qualify something as TDD or not TDD the presence of the refactoring step is actually the most critical.
Some people take liberty with the term, but in general it's failing test first, write code to make it pass, as in the development is driven by the test like the term sounds: 'test driven development'.
Hopefully, when people say "TDD", they refer to the very specific methodology by that name which goes something like this: before making each change, writing a test which fails, and then making it pass with the minimal amount of code, followed by refactoring which keeps all tests passing. No, not exactly unit tests.
Others are right that strictly, it's tests before code, but I think the win from it is that in designing your system, you design it to be testable, spending more time thinking about APIs, and then do go and try to break it.
Or do they just mean doing unit tests as you code?
I'm never sure when I hear this term because the benefits described (thing's just working first try) seem to apply no matter what order do it in.