My manager's manager (... and his manager, and everyone else who wears a suit) at my firm is talking about how we really need to transition to TDD because it's better than what we're doing now. Unfortunately we're dealing with a very old system that has zero automated testing. A lot of this stems from the lack of time allocated to set up any kind of framework around it, and the fear that such a framework would take a lot of time to maintain and its only output would increase developer workload. (You and I both see that as a good thing. You may remember a couple of my other questions surrounding it.)
We recently hired a 'release manager' who basically just sets up a project management system and looks at all the projects coming in and makes sure they have all their documentation. Apparently it's required for SOX compliance to have one, even if it doesn't really seem that his title and his job description match up. One of the things he now looks for (and rejects the proposal if it is missing) is a testing document: a series of steps that the analyst has put forth about how to test the new feature or bug fix they're championing. I won't go into the quality of the document, but at least most of them are more than "deploy to test environment, analyst to test". Let's just assume that enough of them are good enough quality to give someone at least the happy path testing.
Is this considered TDD? I suppose I always thought TDD meant you had to have, say, a unit test written before your class, or an integration test written before you wrote your bridging code between two modules.
Now, I don't want to fall into the "we're Agile!" trap. I think it's silly to sit in a meeting and argue about whether we're actually doing TDD or not. But what I think is important is to be able to line up what we're doing with the lessons others have learned. If we are doing (what the general community calls) TDD then it stands to reason that we are likely to benefit from advice geared at teams that do TDD.
So my questions are:
- Are the tests mandated by TDD required to be automated?
- Are we doing what the general community calls TDD?
- If we aren't what would we need to change to do so?
- Regardless of if we "are" or not, is there some red flag indicated here that would let us be more in line with the TDD community?
So far, it would appear that yes, you do need automated tests in order to be "TDD". So perhaps a follow-up question would be how much of TDD would translate to an "only manual testing" environment?