Right, the original question was about acceptance testing, but TDD still offers a number of benefits, some of which help in solving the acceptance testing problem. Later in these postings, a number of the benefits of TDD are enumerated by William Tanksley. He briefly discusses the fact that simply being forced to write unit-testable code has a profound effect on modularity, coupling and cohesion. He's right about that I think, but there's more...
Done correctly, TDD covers a lot of testing scenarios. Granted, it is black box level testing, but it is nevertheless testing ground that gets covered. Frequently (daily? weekly?)integrating the application and running a large suite of tests against the code successfully builds a lot of confidence that at least the guts of the app behind the UI is stable. Just having this confidence (and a thin UI layer, as William Tanksley mentions) can cut a lot of work out of acceptance testing. It really can focus on the 'skin' of the application, especially if, when bugs are found in the guts, a test is first written to expose the bug, and *then* the code is fixed to make the new test work.
Additionally, having dedicated QA folks working closely with the software engineers throughout a project's life means that the QA folks are up to speed on all of the new functionality coming through, and can be aware ahead of time about what unit tests will cover, and what business logic still needs to be tested through the UI. This can be a very efficient, painless process. I've seen it work.
As a developer, I love TDD. I do not fear maintenance tasks at all anymore. With a suite of tests that is regularly run, all the uncertainty of possibly not knowing everything that a maintenance change will affect is almost completely gone. I'll find out when tests break, and when I've made my changes written tests for them and fixed all the tests I broke, I'm done. This also shortens the acceptance testing cycle, because it shortens the development turn around time when problems are found in acceptance.
Technology, no matter what it is applied to, is just a bigger hammer that makes bigger things happen faster. So our technology makes more, bigger explosions more accurately in a shorter period of time. Is that an asset? I'm not sure.
A war isn't over until one side or another either doesn't exist anymore or is convinced that they have lost. That is the only way a war ends. This is especially true with terrorists. If there is one terrorist left out there who is still fighting to win, we haven't won!
Also, the technology is great for the US to not lose people - but we are aiming high tech weapons at low tech targets staffed by Afghanis. The US doesn't necessary have high casualties, but we are causing plenty in the targets that we hit. We can argue about whether they were civilian or not, whether some "collateral" damage is expected or not - if it's war, people die. I don't think anyone (as someone did earlier in this thread) should be arguing about whether deaths are either "deplorable" or "collateral". That's a non-argument. War sucks. Death sucks. Everyone is someone else's son or daughter, and no one wants to find out their relative is dead.
That said, this war is probably necessary. It is interesting that the key element of the decline of previous world dominating powers (Britain, Spain) can be traced at least in part to protracted, expensive wars.
We'll see if technology is stronger than human determination. Which is cheaper? Which is more flexible? Hmmmm...
The other thing I personally think has an effect with tires on pavement is that you are talking about an elastic material on a very rough surface - when the elastic rubber conforms to the road surface, you wind up with almost a gear like meshing of the two surfaces, which is capable of resisting shear force with more than just surface friction. I think this is borne out by the fact that, while a wider tire patch serves you well on pavement, it provides a much smaller benefit on ice. I think if you had two *perfectly* smooth and *perfectly* inelastic solids in contact, surface area wouldn't matter.
BTW, in light of this discussion, I find it amusing that so many early college physics problems include the following phrase somewhere in the setup: "assuming no friction,..."
It doesn't seem mysterious to me that it's related only to the force. The same force distributed over a wider area actually applies less force per square [your measure here]. So it's a wider area - big deal. It's compensated for by a proportionally smaller force per square area. Whatever atomic force is working at keeping the surfaces distinctly separated has to do less work at any single point when the force is acting in more places. The net effect? Surface area is irrelevant. Am I missing something? Is this explanation just way too simple? What's the catch?
Slashdot Mirror
Right, the original question was about acceptance testing, but TDD still offers a number of benefits, some of which help in solving the acceptance testing problem. Later in these postings, a number of the benefits of TDD are enumerated by William Tanksley. He briefly discusses the fact that simply being forced to write unit-testable code has a profound effect on modularity, coupling and cohesion. He's right about that I think, but there's more ...
Done correctly, TDD covers a lot of testing scenarios. Granted, it is black box level testing, but it is nevertheless testing ground that gets covered. Frequently (daily? weekly?)integrating the application and running a large suite of tests against the code successfully builds a lot of confidence that at least the guts of the app behind the UI is stable. Just having this confidence (and a thin UI layer, as William Tanksley mentions) can cut a lot of work out of acceptance testing. It really can focus on the 'skin' of the application, especially if, when bugs are found in the guts, a test is first written to expose the bug, and *then* the code is fixed to make the new test work.
Additionally, having dedicated QA folks working closely with the software engineers throughout a project's life means that the QA folks are up to speed on all of the new functionality coming through, and can be aware ahead of time about what unit tests will cover, and what business logic still needs to be tested through the UI. This can be a very efficient, painless process. I've seen it work.
As a developer, I love TDD. I do not fear maintenance tasks at all anymore. With a suite of tests that is regularly run, all the uncertainty of possibly not knowing everything that a maintenance change will affect is almost completely gone. I'll find out when tests break, and when I've made my changes written tests for them and fixed all the tests I broke, I'm done. This also shortens the acceptance testing cycle, because it shortens the development turn around time when problems are found in acceptance.
Technology, no matter what it is applied to, is just a bigger hammer that makes bigger things happen faster. So our technology makes more, bigger explosions more accurately in a shorter period of time. Is that an asset? I'm not sure.
...
A war isn't over until one side or another either doesn't exist anymore or is convinced that they have lost. That is the only way a war ends. This is especially true with terrorists. If there is one terrorist left out there who is still fighting to win, we haven't won!
Also, the technology is great for the US to not lose people - but we are aiming high tech weapons at low tech targets staffed by Afghanis. The US doesn't necessary have high casualties, but we are causing plenty in the targets that we hit. We can argue about whether they were civilian or not, whether some "collateral" damage is expected or not - if it's war, people die. I don't think anyone (as someone did earlier in this thread) should be arguing about whether deaths are either "deplorable" or "collateral". That's a non-argument. War sucks. Death sucks. Everyone is someone else's son or daughter, and no one wants to find out their relative is dead.
That said, this war is probably necessary. It is interesting that the key element of the decline of previous world dominating powers (Britain, Spain) can be traced at least in part to protracted, expensive wars.
We'll see if technology is stronger than human determination. Which is cheaper? Which is more flexible? Hmmmm
The other thing I personally think has an effect with tires on pavement is that you are talking about an elastic material on a very rough surface - when the elastic rubber conforms to the road surface, you wind up with almost a gear like meshing of the two surfaces, which is capable of resisting shear force with more than just surface friction. I think this is borne out by the fact that, while a wider tire patch serves you well on pavement, it provides a much smaller benefit on ice. I think if you had two *perfectly* smooth and *perfectly* inelastic solids in contact, surface area wouldn't matter.
..."
BTW, in light of this discussion, I find it amusing that so many early college physics problems include the following phrase somewhere in the setup: "assuming no friction,
It doesn't seem mysterious to me that it's related only to the force. The same force distributed over a wider area actually applies less force per square [your measure here]. So it's a wider area - big deal. It's compensated for by a proportionally smaller force per square area. Whatever atomic force is working at keeping the surfaces distinctly separated has to do less work at any single point when the force is acting in more places. The net effect? Surface area is irrelevant. Am I missing something? Is this explanation just way too simple? What's the catch?