|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 15
Messages: 15
Messages: 15
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Scary thought: maybe those who say they can't do TDD are right
Tim Ottinger, from Object Mentor, says in "What can't who do?," that "When someone is supposed to change their workstyle to do TDD, and they say 'we can't do that,' how about we assume they're telling the truth?" He then deconstructs what the statement might mean... and ends up pointing out that there may be a misconception on someone's part about what test-driven development is.The first word is "we." It may well be that the speaker and the people he represents might not be able to do the work. They're not saying that it can't be done. They're only saying that they can't do it.
The next word is "can't" and that's an interesting word, too. It might mean that they lack the ability or knowledge. That's ideal, because such things can be taught and can be led. The other sense is that they are not allowed. If it's like that, then there is going to be some political work going on. But at least you know what you’re getting into.
The other tell is the word "that." Maybe they should describe what it is that they can’t do, and you can tell if the thing they can't do is the same thing that you are wanting them to do. Sometimes it is not. Tim has three good points - figuring out exactly what the statement means allows you to target what barriers there are to TDD in an organization.
Of course, all this assumes that you see TDD as a good thing...
[Editor's note: Tim Ottinger is no relation to Your Humble Editor - our last names are the same, but as far as we know there's no familial tie. We've talked about it briefly before. For myself, I'm glad there's at least one good writer with our last name - and I mean him!]
|
|
|
Message #231971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Irrelevant
So what is he saying. That someone might do something somewhere instead of someone else not doing something else? That's what I call a revolutionary insight!
Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant, because a lot of people who have embraced TDD have turned away from it again, because it did not work out for them. Now, it might well be that a certain development style might not be applicable in a certain *business* environment.
|
|
|
Message #231996
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Examples of TDD turnaway
a lot of people who have embraced TDD have turned away from it again, because it did not work out for them.
Can you elaborate on this comment? Can someone tell me the approximate percentage of those that embraced it, but have turned away from it? And why they turned away from it?
|
|
|
Message #231998
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Up with arrogance
Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant
If postulating about one possibility rather than declaring it to be unequivocally so is arrogant, then may we all be so arrogant. It sure beats making assumptions about the speaker.
|
|
|
Message #232034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Examples of TDD turnaway
Can you elaborate on this comment? Can someone tell me the approximate percentage of those that embraced it, but have turned away from it? And why they turned away from it?
I have seen a number of projects / project teams, where TDD was advocated yet after a certain time, it turned out to be infeasible. There were various reasons, but I will try and give a few.
- Meaningful tests required very extensive test harnesses.
- A tendency evolved to test the trivial, even with high code coverage.
- People simply refused/forgot to write tests (no you couldn't fire them :-().
- Especially with partly finished products, moving to TDD like development can be an overwhelming effort - this is dodged in particular, if people know that the testing will not come out favourably.
- Business was not able to provide decent specification and interaction.
|
|
|
Message #232035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Up with arrogance
Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant
If postulating about one possibility rather than declaring it to be unequivocally so is arrogant, then may we all be so arrogant. It sure beats making assumptions about the speaker.
Quite right. But can't usually does not refer to the ability or knowledge. There is plenty of literature available on the subject and "can't" usually refers not to "ability and knowledge" but to matters in project organization, delivery organization, business interaction etc. that can be very profound reasons not to use TDD.
|
|
|
Message #232050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I agree they are right
The next word is "can't" and that's an interesting word, too. It might mean that they lack the ability or knowledge. That's ideal, because such things can be taught and can be led. The other sense is that they are not allowed. If it's like that, then there is going to be some political work going on. But at least you know what you’re getting into.
After quite some time advocating TDD I've realized that although the vast majority of software developers understand technically how a test such as JUnit is written, they really don't get TDD.
It is very rare that I write something and am unable to test it. The code is structured from the ground up to be testable. I've found a tendency for folks to write the code the way they want to, then reflect that it cannot be easily tested.
It's really a painful process mentoring in this case, because you're really trying to fundamentally change how someone codes and that's a tough sell.
I'd say in my experience maybe 30% of the people will get it, recognize how much faster they are because their code passes QA more quickly, they can refactor more quickly, their code naturally becomes more reusable (since it's already reusable enough to support a test), etc.
The rest of the folks write tests but do so as an after thought and only write them to satisfy the goal of writing them.
|
|
|
Message #232069
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Up with arrogance
Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant
If postulating about one possibility rather than declaring it to be unequivocally so is arrogant, then may we all be so arrogant. It sure beats making assumptions about the speaker.
I'm detecting some arrogance in the original statement as well.
I can see a third reason why they say "can't": maybe they *really* can't. It's just not technically feasible. Or so hard that it's just not worth it and you're better off leaving a human in the QA department test it.
Examples? How about a Java ME application? (or more simply, a UI-driven one)
Most developers do *no* TDD at all. It's about time we started listening to these people instead of trying to lecture them.
--
Cedric
|
|
|
Message #232089
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Up with arrogance
Most developers do *no* TDD at all. It's about time we started listening to these people instead of trying to lecture them.
--
Cedric
Yes! Testing is for suckers.
|
|
|
Message #232098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Carts and horses
I don't want my team's D to be driven by T at all. I want my team's D to be driven by customer desires.
Creating tests before creating code, now that's a different thing. Which has to be a good idea, up to the point where it costs more to create tests than to test code. But we already knew that ...
|
|
|
Message #232104
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Carts and horses
There was an interesting interview (on Artima?) with two people behind a Ruby testing approach. They had avoided the term TDD in favour of "Responsibility-Driven Development", and not just out of a desire to be contrary. They argued (quite persuasively, IMHO) that the focus on *tests* was misleading, because it focused on the wrong thing.
Instead of thinking "how do I test this", you want developers to think "what should the responsibilities of this object/method be?" and then write tests that confirm that it carries out those responsibilities correctly.
I think this is the mindset shift that people who 'get' TDD are able to make subconsciously, but which eludes many others. Told to focus on tests, they resist the idea (for a number of reasons) and so never do TDD long enough to have the "aha" moment when the suddenly realise that "it itsn't about tests, per se, it is about identifying correct behaviour, and then thinking of a way to detect incorrect behaviour!"
Put it to them like that--as a two-step mental process--and we may see the lights go on for many more people. God knows it took me several days of struggle to 'grok' TDD, and it wasn't until I heard the Ruby guys talking about 'RDD' that I realised why it was so hard, and how I'd finally overcome it.
Cheers,
Christopher
|
|
|
Message #232117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Examples of TDD turnaway
Can you elaborate on this comment? Can someone tell me the approximate percentage of those that embraced it, but have turned away from it? And why they turned away from it?
I have seen a number of projects / project teams, where TDD was advocated yet after a certain time, it turned out to be infeasible. There were various reasons, but I will try and give a few.
- Meaningful tests required very extensive test harnesses.
- A tendency evolved to test the trivial, even with high code coverage.
- People simply refused/forgot to write tests (no you couldn't fire them :-().
- Especially with partly finished products, moving to TDD like development can be an overwhelming effort - this is dodged in particular, if people know that the testing will not come out favourably.
- Business was not able to provide decent specification and interaction.
1 - Meaningful tests required very extensive test harnesses.
Isn't this a problem of understanding what kinds of testing belong in a unit test and what kinds of testing belong in an integration test or UAT?
2 - A tendency evolved to test the trivial, even with high code coverage.
3 - People simply refused/forgot to write tests (no you couldn't fire them :-().
These are just matters of education and working practice surely. I'm sure similar problems were encountered when trying to get C programmers programming in C++ to use OO concepts. (you couldn't fire them either!)
4 - Especially with partly finished products, moving to TDD like development can be an overwhelming effort - this is dodged in particular, if people know that the testing will not come out favourably.
I agree, sometimes TDD is not applicable
5 - Business was not able to provide decent specification and interaction.
But surely at least some of the value of a test case suite is to give you some certainty as to how your application behaves regardless of whether a business person has told you how they want it to behave. If you don't think this has value without a business spec does that mean you think that a functional spec has no value either?
For me TDD simply formalises your expectation of how your app should work. On a project where those assumptions have not received an official sanction from the users at least the point of reference is still there.
It's better to not know what people want your code to do, but know what it does, rather than to not know either.
|
|
|
Message #232158
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Strict TDD may never work
There have been many suggestions in this thread as to why TDD may not be suitable. One of the best I read (and experienced) is the fact that often requirements are patchy and changing. I also think that concentrating too much on the test upfront (or Responsibility as someone else called it) may lead to the wrong test, the wrong design or both.
In my opinion, the problem lies in trying to be too strict about TDD.
I prefer a more relaxed mode where an initial design is layed out as a set of interfaces, followed by some tests to drive an initial implementation. Then I let the implementation shoot ahead for a while with unit tests following and occasionally taking over again (back to TDD).
The idea is not to lose sight of the bigger picture by focusing too much on a small piece of the whole system. It can be expensive to rewrite large parts of the API if that also means rewritting all those tests (could this be the reason some people abandoned TDD altogether?).
|
|
|
Message #232179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Here is what we could not do with TDD
>>> "Maybe they should describe what it is that they can’t do, and you can tell if the thing they can't do is the same thing that you are wanting them to do. "
We have delivered a J2EE web application just recently with lots of image processing involved. The testing of the application required visual inspection of the images that are being painted through the web browser. There is no possible way TDD can fit in here, when even the unit testing of the application requires tedious masking of images, positioning them in an applet and gamut of other visual features apart from the server-side logic.
IMHO,just bluntly summarizing that "TDD is the only approach" is not politically correct. Everyone should respect every school of thought out there and not try to force their ideology on the whole enterprise community.
I have worked on lots of financial applications where TDD makes sense as the use cases and unit tests could have been concretely summarized. We can definitely not make TDD the ideal approach to follow in case of every application out there. We should obey our common-sense when required.
|
|
|
Message #232323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No silver bullet?
Gosh ! Maybe there is no silver bullet ...
Having said that, things should be designed with testeability (sp?) ... UIs are not easily testable because they did not care to design UI Kits that way ... Moving requirements is a big marker for striving for TDD (as tests are "a bit" more evaluable than written specs). DbC(TM?) is also a good idea, but not everybody has the luxury of working with clear contracts ... Now, moving requirements, non testable building blocks, non clear contracts ... So, what field that builds things could have all those in a high grade and not suffer? Sometimes, I'm amazed why things do not fall apart more often :)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
