57834Re: [SCRUMDEVELOPMENT] TDD effectiveness
- Jun 5 2:56 PM+1 or more!AlanOn Thu, Jun 5, 2014 at 2:09 PM, Adam Sroka adam.sroka@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
I have coached a lot of teams and have seen a few patterns in the way people code without TDD:1) They write some code they think is right and manually poke at it through the user interface.2) They write some code they think is right and sprinkle it with system out code so that they can read the intermediate results and check them.3) They write some code they think is right and run it through the debugger to check intermediate results.4) They write code against an interactive interpreter or shell and capture (or reproduce) the session checking results along the way.All of these have a few things in common:* You don't write a whole system at once. You write just enough to be able to see and verify some result.* You don't always get it right the first time. You expect some intermediate results to be incorrect. You use this as an indication that the program is either not yet doing something you need it to or doing something you don't expect. You then attempt to correct this and check again.* You are constantly moving and shuffling things around to make it easier to understand and to isolate bits you want to work on. Periodically you need to check that you haven't introduced regressions. The longer you wait to do that the more likely it will be a long day when you do...My conclusion is that the only significant feature of TDD that is missing from these other methods is automation. Each of these methods requires you to remember what to verify and do it over and over again. The Pragmatic Programmers told us a long time ago that anything you are going to have to do over and over you need to automate (Ubiquitous Automation.)So, the next time you think TDD is too hard or not worth doing ask yourself this: I am a programmer, why am I afraid to write a program to do something that I am perfectly willing to do manually over and over?Hi all,Given this discussion, I thought it sensible to point out that TDD isn't exactly a new idea...Tim--On 3 June 2014 13:41, Adam Sroka adam.sroka@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:Code coverage is a double-edged sword. You can show it to middle managers to prove that all that time you spent on testing you were actually doing something useful. However, once you test all the easy stuff the number is going to move slower and they're gonna want to know why.At that point a lot of folks might start doing silly things to improve the number. That's a bad idea. The trick is to realize that this is all a game and it only buys you a small amount of time to improve things. After that you're going to have to try something else.I use coverage to motivate teams to start automating tests and managers to leave them alone and let them do it. The truth is, however, that once you have at least one test running the number itself is kinda pointless. At the first sign of danger I will take it down and tell them that, on further analysis, we were finding the number didn't accurately reflect our testing effort...On Wed, May 28, 2014 at 1:16 AM, 'Hiep Le' tronghieple258@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
In my view, the code coverage is a trap; developers will write some meaningless tests in order to reach to a certain ratio, which is stupid and a waste of time.
What we should do is to write good tests (cover positive and negative cases) for appropriate context and TDD is a good way to go.
In short, my empirical evidence shows that TDD does not necessarily keep you from doing a poor job.
MarkusTim021 251 5593
- << Previous post in topic Next post in topic >>