Kassem
Hey guys,
I was wondering what's all the hype about TDD? I mean what's the benefit of TDD? It doesn't make much sense to me, but I could be wrong...
Any thoughts?
Joe
reserved for posting later :)
EDIT:
I finally wrote it. Sorry about the delay, I was extremely busy last week. Between the internship, the school and looking for work, I barely had the time to write it today.
So here goes my answer,
I published it on my blog.
rolf
It allows the developer to focus on developing, and offloads the testing off him.
It can be a good thing.
(Disclaimer: I dont have experience with TDD and am not even sure we are talking about the same thing)
Kassem
rolf wroteIt allows the developer to focus on developing, and offloads the testing off him.
Yes that's what the name implies but how?
I guess we'll have to wait for rahmu's post :)
xterm
That is not what TDD is about. I'll leave it to rahmu, I'm in no mood for long posts >.<
rolf
OK lol wikipedia did that for me.
TDD looks very interesting, it just seems to be like and work best in teams.
Joe
Oh and I don't mean to be rude or anything, but rolf you're wrong on both counts :P
First of all, TDD is all about testing.
Second of all, you don't have to be in a team to implement it. As a matter of facts, TDD might have many flaws, but one of its great strength is that it is very easy to implement. Single developers usually benefit greatly from implementing it. :)
rolf
Actually, I may work in TDD a lot, if not most of the time, without knowing it.
I mean that's how most people work, right?
1st you start off with a feature you must implement, but that is not there (test fails!), then you usually try several solutions until you find one that you find good, then from there on you keep testing and debugging and improving.
It's not exactly TDD, but on the other side, TDD isn't "iktishaf al baroud"
Ayman
Actually, I may work in TDD a lot, if not most of the time, without knowing it.
Same here :)
arithma
- TDD's true power lies in the seperation between the contract for a certain interface and its implementation.
That means that an architect can codify his vision for the usage of interfaces in tests.
- A developer will start out with failing naive interfaces and incrementally fulfill the unit tests.
- A maintainer will be able to see the usage of the entities in an API, framework, or project, and accordingly will know how a change on one piece of code could affect other places in a project. (Amplify instantaneous feedback of global effect from local changes).
- TDD is closely related to contract-by-usage (iirc the exact wording).
- The architect, developer, maintainer could all be the same person, but the mind-set should be separate in each of the stages.
@rolf and ayman: The thing about software engineering and the related methodologies and patterns is that it is all oriented towards teams. Communication is a huge guarantee for more organization as it would be impossible to have any meaningful progress without common ground.
An interesting question is how does TDD apply for GUI based functionality? How automatic can that be?
Kassem
@rahmu: very interesting article, I really enjoyed reading it. If I may add, TDD also encourages granularity in your code. You have to write a test for each and every task in your application. You cannot have "and" inside the name of your tests, that's a clear sign that your code is flawed and tells you to go back to your code, refactor and write a more precise test. This helps you figure out what is causing problems later on, especially when you alter your code.
@arithma: I would really want to know the answer to your question, but all I could think of is the following:
1. Write a test which expects some sort of user interaction (mouse event, filling a form... etc)
2. Implement the functionality
3. Design and code the GUI element
4. Interact with the GUI element and check for the result.
arithma
@Kassem: with number 4 goes your automated testing. There are some techniques around that, for example leaving your GUI as the very last layer, and keeping everything underneath tested. GUI hand testing is almost inevitable, and emulating user click and press sequences is almost always a one way ticket to hell.
The greatest value that I touched while using TDD in a very small code base was the confidence I had when debugging later issues that arose. I didn't have to check the lower layers since I knew they passed the tests. Once you start get puzzled around, you recheck your unit testing scheme for gaps. Usually that's where you strengthen even more your code base. It's even more beautiful when you optimize your implementation, in certain units, without breaking an entire program.
Unit testing fails when changes are to be done on the architectural level (but that's inherent in the definition of a unit test) where interfaces must change, classes merged or re-factored.
Joe
@arithma: No!
TDD is widely used in web development, and this is all about GUI. Ideally, TDD would abstract completely manual testing. But here's where it gets complicated:
Can you be 100% sure that the tests you wrote cover every aspect of your code? How can you be sure you haven't left out a buggy situation or a security vulnerability?
The biggest trap of TDD is assuming that everything is good because all your tests have passed
@everyone:
Once you have a solid test database, you can then set up a Continuous Integration process. It is advanced management of unit testing. We are looking into that at work. We are actually setting up an open source tool called 'Hudson' that does that. More once I'll know more. :)
cnicolaou
rahmu, i'll check the blog before commenting on TDD
Continuous Integration is not only about unit tests, it's a bit more to check that your build is not broken when devs commit changes or new features to the central repository. It runs specified tests and keeps a log of previous builds with diffs (unit/functional/integration).
Hudson is great, there's also CruiseControl from ThoughtWorks, easy to install and get it up and running quickly.
Now reading your blog entry...
cnicolaou
@rahmu excellent post, cheers
Joe
cnicolaou wrote@rahmu excellent post, cheers
:D