I've never seen a project fail because of too much testing. Maybe because of an over-emphasis on process, but not because of writing too many useful tests. On the contrary, projects I've worked on fail or approach failure because of lack of clear requirements, whether in unit test form, BDD, or well-written user stories. If it's not clear what a product owner wants then it's impossible to test and impossible to implement to match the owner's expectations. TDD is useless if you don't know what you're trying to build.
Too much testing, no. Too much time spent building test frameworks, simulators and 101 other things before a line of code is written? Well I just witnessed it last year.
Not that it was the only factor. Heavy 'agile' process was certainly part of it. They also threw everything away and restarted again at some point, likely due to changing requirements. But it was part of the picture that added up to nothing getting done.
Jesus, what a nightmare! You look back on your work and you've only produced tooling instead of solving the problem you set out to solve. An easy trap to fall into, but doing it for a year is something else.
It wasn't quite as bleak a picture as maybe I've painted.... but not far off either. Must have been pretty depressing for the team as well as for the folks running the show.
On the positive, I think they all got good roles with our competitors!
The problem is that it's entirely reasonable and common for a product owner to not know what they want. It's not some inconvenience that can just be ignored.
It's a fairly uninteresting problem if you can fully specify it before development starts.
Specification should be more like a conversation. That's the whole point of a lot of incremental and customer-focused development.
The problem is when you're under time constraints or technological constraints that don't allow for rapid iteration.
The discipline of writing tests tends to tease out design requirements fairly quickly. Because as soon as someone takes the time to think carefully about the implications of what the product owner wants, it usually results in a feedback loop eliciting further details. Like a conversation, yes, but one which results in documented, tested implementations.
Because as soon as someone takes the time to think carefully about the implications of what the product owner wants, it usually results in a feedback loop eliciting further details.
I am not a TDD person, and that sounds pretty much what I do. Why do I need a load of tests to find out more details of what I am trying to implement?
The benefits of testability as a focus of requirements gathering and automated tests in the source tree as a concrete artifact of that requirements gathering is:
(1) If something is specified well enough to be automatically tested, there is clear agreement (and not superficial agreement hiding different interpretations).
(2) If automated tests are created and in the source tree, the unambiguous knowledge in #1 is preserved which makes resolving future questions of expectations and intent of the existing code base easily resolvable.
For most people the easiest way to see what using an API looks like is to use it. And the emergent design that results can often be better than what you would have designed if you tried to design by thinking about it without writing code. http://c2.com/cgi/wiki?WhatIsAnAdvancer
And writing an API takes up a small proportion of my time. Usually its generating database queries, and spitting them out as web pages, and presenting the data in a way that non technical users can understand.
If you're spending a substantial proportion of your time generating database queries or rendering results to web pages you should look at using better libraries for doing so, and/or improving your own library-type code.
If you're talking about figuring out how best to present the data, that's not really "development" per se. But it is another kind of API, and again something that you can design more effectively using a test-oriented approach (e.g. start by figuring out the use cases for what a user wants to find out from the information).
How do you know I am not using good libraries libraries for writing my code? (I usually use Django which seems to be well respected). Again, that has nothing to do with test driven development.
I already start by figuring out what the user wants. Again, nothing to do with writing a load of tests first.
All your suggestions for how TDD will improve my development seem to point to exactly what I do already without writing tests first.
How do you know I am not using good libraries libraries for writing my code?
You said "writing an API takes up a small proportion of my time. Usually its generating database queries, and spitting them out as web pages...". Which suggests to me that you're not using libraries effectively, because those things are a tiny proportion of my time. The business logic - i.e. the part that's actually specific to your problem - should be where you spend most of your time, and that's the part where TDD is effective.
I already start by figuring out what the user wants. Again, nothing to do with writing a load of tests first.
Writing a test for a use case ensures you actually understand it. It helps you find more possible problems or misunderstandings in the same way that a blueprint is an advantage over a sketch. And it's probably the most effective way to communicate these use cases to developers you're collaborating with.
Wow, so without knowing very much about my work, you are able to tell me where I should be spending the majority of my time.
And how does writing a test ensure that I understand a problem any more than not understanding it? If I don't understand it properly I will likely write the wrong test.
Comments
I've never seen a project fail because of too much testing. Maybe because of an over-emphasis on process, but not because of writing too many useful tests. On the contrary, projects I've worked on fail or approach failure because of lack of clear requirements, whether in unit test form, BDD, or well-written user stories. If it's not clear what a product owner wants then it's impossible to test and impossible to implement to match the owner's expectations. TDD is useless if you don't know what you're trying to build.
Too much testing, no. Too much time spent building test frameworks, simulators and 101 other things before a line of code is written? Well I just witnessed it last year.
Not that it was the only factor. Heavy 'agile' process was certainly part of it. They also threw everything away and restarted again at some point, likely due to changing requirements. But it was part of the picture that added up to nothing getting done.
Jesus, what a nightmare! You look back on your work and you've only produced tooling instead of solving the problem you set out to solve. An easy trap to fall into, but doing it for a year is something else.
It wasn't quite as bleak a picture as maybe I've painted.... but not far off either. Must have been pretty depressing for the team as well as for the folks running the show.
On the positive, I think they all got good roles with our competitors!
The problem is that it's entirely reasonable and common for a product owner to not know what they want. It's not some inconvenience that can just be ignored.
It's a fairly uninteresting problem if you can fully specify it before development starts.
Specification should be more like a conversation. That's the whole point of a lot of incremental and customer-focused development.
The problem is when you're under time constraints or technological constraints that don't allow for rapid iteration.
The discipline of writing tests tends to tease out design requirements fairly quickly. Because as soon as someone takes the time to think carefully about the implications of what the product owner wants, it usually results in a feedback loop eliciting further details. Like a conversation, yes, but one which results in documented, tested implementations.
I am not a TDD person, and that sounds pretty much what I do. Why do I need a load of tests to find out more details of what I am trying to implement?
The benefits of testability as a focus of requirements gathering and automated tests in the source tree as a concrete artifact of that requirements gathering is:
(1) If something is specified well enough to be automatically tested, there is clear agreement (and not superficial agreement hiding different interpretations).
(2) If automated tests are created and in the source tree, the unambiguous knowledge in #1 is preserved which makes resolving future questions of expectations and intent of the existing code base easily resolvable.
For most people the easiest way to see what using an API looks like is to use it. And the emergent design that results can often be better than what you would have designed if you tried to design by thinking about it without writing code. http://c2.com/cgi/wiki?WhatIsAnAdvancer
That's not really answering the question I asked.
And writing an API takes up a small proportion of my time. Usually its generating database queries, and spitting them out as web pages, and presenting the data in a way that non technical users can understand.
If you're spending a substantial proportion of your time generating database queries or rendering results to web pages you should look at using better libraries for doing so, and/or improving your own library-type code.
If you're talking about figuring out how best to present the data, that's not really "development" per se. But it is another kind of API, and again something that you can design more effectively using a test-oriented approach (e.g. start by figuring out the use cases for what a user wants to find out from the information).
How do you know I am not using good libraries libraries for writing my code? (I usually use Django which seems to be well respected). Again, that has nothing to do with test driven development.
I already start by figuring out what the user wants. Again, nothing to do with writing a load of tests first.
All your suggestions for how TDD will improve my development seem to point to exactly what I do already without writing tests first.
You said "writing an API takes up a small proportion of my time. Usually its generating database queries, and spitting them out as web pages...". Which suggests to me that you're not using libraries effectively, because those things are a tiny proportion of my time. The business logic - i.e. the part that's actually specific to your problem - should be where you spend most of your time, and that's the part where TDD is effective.
Writing a test for a use case ensures you actually understand it. It helps you find more possible problems or misunderstandings in the same way that a blueprint is an advantage over a sketch. And it's probably the most effective way to communicate these use cases to developers you're collaborating with.
Wow, so without knowing very much about my work, you are able to tell me where I should be spending the majority of my time.
And how does writing a test ensure that I understand a problem any more than not understanding it? If I don't understand it properly I will likely write the wrong test.