aspose file tools*
The moose likes Agile and Other Processes and the fly likes About Test Driven Development? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "About Test Driven Development?" Watch "About Test Driven Development?" New topic
Author

About Test Driven Development?

Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Hi, comrades!

I have been reading the other thread on this forum about improving coding speed.

For the first time in my life i ran into the concept of test driven development. I had heard about it before, but I never got interested on it.

This time I decided to see what it was all about, and I have been reading the book Test Driven Development by Example (by Kent Beck).

I am fairly new to Unit Testing too and I have some questions I would like read your opinions about.

1. Do you how any idea about how TDD deals with the development of Graphical User Interfaces (like Swing, SWT)?
2. Any thoughts on how to use TDD on the development of multithreading applications?
3. I have the impression that TDD do not imply that I have to test every single method or class I develop, but only those aspects that imply business logic. Is that correct?

Thanks in advance for your participation!
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Edwin Dalorzo:
1. Do you how any idea about how TDD deals with the development of Graphical User Interfaces (like Swing, SWT)?

There are frameworks like jfcUnit and Jemmy, which let you write unit tests for your Swing components. There's some code in the Abbot project's version control system for doing the same with SWT code (no documentation, though). If you're doing Swing development, I'd really recommend picking up a copy of Dave Astel's book, Test-Driven Development: A Practical Guide. It uses Jemmy for developing a small GUI application throughout the chapters.

Originally posted by Edwin Dalorzo:
2. Any thoughts on how to use TDD on the development of multithreading applications?

One word: isolation. You'll want to isolate the multithreading logic as much as you can from the application logic that should be executed within those threads.

Originally posted by Edwin Dalorzo:
3. I have the impression that TDD do not imply that I have to test every single method or class I develop, but only those aspects that imply business logic. Is that correct?

The idea is that you write tests that verify expected behavior or functionality. In practice, that often means your tests invoke one or two methods on the class under test and potentially invokes another method or two to assert against the object's state. Your tests might also lead you to creating new classes as part of the implementation of a test. In other words, no, it's not that you should test every single method or class directly but if you follow TDD you should be doing that indirectly (otherwise, why would a class exist if there was no test that directly or indirectly required creating it?).


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Edwin Dalorzo:
1. Do you how any idea about how TDD deals with the development of Graphical User Interfaces (like Swing, SWT)?


I've written a whole chapter about it in the book from my signature. (Unfortunately it's only available in German.)

The most important trick is to make your GUI code as dumb as possible, so that as many tests as possible can ignore it. Google for "humble dialog" for a good technique on how to do that.


2. Any thoughts on how to use TDD on the development of multithreading applications?


There is a chapter on testing multi-threaded code in the book "Unit Testing in Java: How Tests Drive the Code" - it even comes with a set of utilities classes.

Basically it comes down to the fact that unit tests can only handle a small subset of threading problems, and even that is hard work and requires that you know very well what you are doing.

So the best strategy to deal with multithreading is to not allow it to become complicated and to rely on well-known patterns wherever possible.



3. I have the impression that TDD do not imply that I have to test every single method or class I develop, but only those aspects that imply business logic. Is that correct?


Not exactly. The XP mantra to TDD is "Test everything that could possibly break". There *are* some things, such as multithreading, which are hard enough to test that it might be more efficient to rely on other techniques to assure correctness. That's more of an exception, though.

What other things than business logic do you have in mind?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Thanks very much for your replies Lasse and Ilja. They have been most certainly helpful.

I will do some research this weekend on jfcUnit and I will load the book Test Driven Development to my bookshelf in Safari, as soon as I finish to read the one I am reading now.

I am particularly interested in knowing how TDD positivly affects the development process, and of course understanding the drawbacks of its implementation.

It is pity that your book has not been yet translated Ilja. I will look about humble dialog as you suggest and I see about reading Unit Testing in Java.

I believe I may be getting the wrong idea about TDD. The book I am currently reading, by Kent Beck, seem to suggest that the development process is something spontaneous, somehow, without planning, that you start to write tests and, by art of magic, this process will lead us to the correct implementation of the system.

I consider myself open-minded and prone to evaluate new ideas on how to do things. But I am having difficulty to understand how to develop a real system with this philosophy.

I have taught to have a design previous to the development, and I guess TDD is not changing that. Hence I know mostly, beforehand, which classes I have to implement. However I feel TDD suggest that the final outcome is somehow uncertain. How come?

Another difficulty I have is on how to use Unit Testing with GUI, and that's why I have to work a bit hard on it. In fact, I think I need study more about unit testing itselt in order to understand what is intelligent to test and what it is not.

Yesterday, precisely, I develop a Login Screen. I have a method named setUpFrame which sets the frame's layout and call another methods to add the panels to the content pane, sets the screen size, among another things.

I simply do not see a point in testing this.

On the other side a I have couple of threads that read and write messages into a message queue. The thread will die until it is requested by an user event. I created tests to make sure that the class that reads and writes messages to the underlaying queue works properly, but I have to idea about how to test the thread's execution logic.

I have done some research and I found an interestig framework for Mutithreaded testing. Hence more to read. This TDD is a technique difficult to master as far as I can seen.

Finally, another great problem I have found is how to control the testing environment. Yesterday, likewise, I created a couple of classes that works like Transaction Scripts (as suggested by one of Mr. Fowller´┐Żs patterns) to execute simple SQL commands into a database. This is reusable code, not specific to any particular application.

Testing a class like this implies that I will have a properly configured access to a database, and testing the transaction script implies that I have a properly configured set of tables with records and everything to make sure that tests succed or fail when expected. The same thing happens when it comes to testing my clases the interact with the message queue.

How should I control all this enviromental issues when working with TDD in order that if somebody else run the tests six months later, all the test behave as expected?

Thanks guys for you execellent replies and thanks in advance for any further suggestion regarding this comments.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Edwin Dalorzo:
I will do some research this weekend on jfcUnit


I'd advise strongly to drop jfcUnit and use Jemmy instead. The latter has a much nicer API.


I will load the book Test Driven Development to my bookshelf in Safari, as soon as I finish to read the one I am reading now.


Personally, I didn't like that book very much. Unfortunately there aren't many alternatives for testing Swing GUIs...

I am particularly interested in knowing how TDD positivly affects the development process, and of course understanding the drawbacks of its implementation.


What drawbacks???

It is pity that your book has not been yet translated Ilja.


I doubt that it ever will be. There just already are too many TDD-books out there that it would make much economical sense, I fear.

I have taught to have a design previous to the development, and I guess TDD is not changing that.


Well, you guessed wrong. TDD actually is a technique to come up with the design while concurrently coding it.

Hence I know mostly, beforehand, which classes I have to implement. However I feel TDD suggest that the final outcome is somehow uncertain. How come?


The goal of a good design is to structure the code so that it is easy to understand, flexible, simple and still extensible.

To create such a design, you basically have to "see the code in your head". To the extent that you can do that, you might be able to come up with a good design upfront. But finally whether your design really is good can only be validated by coding it.

Before I start a new TDD cycle, I typically have a good idea of what the final design will look like. I might even have spent some minutes with a coworker on the white board to sketch some ideas.

TDD than allows me to implement and validate the design step by step. The nice thing about the tests is that they don't only allow you to refactor the design without breaking existing functionality, they are also a client of the production code that needs to use a small part of the code in isolation, and thereby forces me to decouple it from the rest of the system.

Often enough I find that during TDD I find a better, often simpler design than the one I envisioned. And the better I get at it - especially the refactoring step - the less I feel the need to think about the design up front.

Another difficulty I have is on how to use Unit Testing with GUI, and that's why I have to work a bit hard on it. In fact, I think I need study more about unit testing itselt in order to understand what is intelligent to test and what it is not.


I'd advise to start testing the non-GUI part of your code first. When you get good at that, you can start worrying about the GUI part - that's really already an advanced topic, in my opinion.

Yesterday, precisely, I develop a Login Screen. I have a method named setUpFrame which sets the frame's layout and call another methods to add the panels to the content pane, sets the screen size, among another things.

I simply do not see a point in testing this.


It might well be that I wouldn't test that, either. Much of GUI code has to do with layout, which is better visually validated than with some automatic test tool. (A coworker of mine even developed a JUnit-like framework to help with that, named JDemo. But you probably shouldn't worry about that before you get good at JUnit testing your business logic.)

What you could still test, the humble dialog style, is whether pressing a button calls the right business logic, for example.


On the other side a I have couple of threads that read and write messages into a message queue. The thread will die until it is requested by an user event. I created tests to make sure that the class that reads and writes messages to the underlaying queue works properly, but I have to idea about how to test the thread's execution logic.


Can you tell us more about the part of the logic you have trouble with?

I have done some research and I found an interestig framework for Mutithreaded testing. Hence more to read. This TDD is a technique difficult to master as far as I can seen.


You are already dealing with a lot of advanced techniques here that even experienced testers have trouble with. Perhaps you shouldn't yet worry to much about those...

How should I control all this enviromental issues when working with TDD in order that if somebody else run the tests six months later, all the test behave as expected?


Testing database code - another quite advanced topic.

There are a number of strategies available here. One possible solution would be using an in memory database (for example HSQLDB) that can be started, populated and destroyed for every test in isolation.

I think both "Unit Testing in Java", "JUnit Recipes" and "JUnit in Action" contain good advice on this huge topic.
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Hi, Ilja

Thanks for adivise. As you suggest I will concentrate on mastering Unit Testing with business logic at the moment. There will be time, after that, to see about GUI and mutithreading testing.

Another couple of assertions I would like to validate with you:

1.) As far as I can see TDD seems to be a techinique for more experienced developers. It does not seem to be a tecnique good for the junior ones, since it not only implies mastering the concepts of unit testing, but also all these refactoring issues, which in good theory, should come out with a good design. This imply that the programmer has to be experienced enough as to take good design decision on the way that will result in good application design.

2) Now, as the develpment process appears to be, to some degree, uncertain, I would like to listen what is your experience with this tecnique when it comes to project estimation, does TDD not make estimation more inaccurate?

As for the threading issues you asked me, the application I am working initiates a set of threads. The number of threads is fixed, but customizable. Some of these threads are reading from one or more message queues. When the queue is empty then the thread that realizes that the queue is empty asks the other threads to stop. When there are messages back in the queue, this only running thread wakes up the other threads one by one.

I would like to test that the threads really stop when the queue is empty and that the threads really wake up when there are messages in the queue, and what happens to the message when it cannot be delivered, or what happens to the message when I ask the thread to interrupt. Things like those.

Once again, thanks for your insightfull sugestions.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Edwin Dalorzo:
1.) As far as I can see TDD seems to be a techinique for more experienced developers. It does not seem to be a tecnique good for the junior ones, since it not only implies mastering the concepts of unit testing, but also all these refactoring issues, which in good theory, should come out with a good design. This imply that the programmer has to be experienced enough as to take good design decision on the way that will result in good application design.

It's true that it's mostly experienced developers who use TDD. Then again, I've seen junior developers leap-frog their senior colleagues in productivity after adopting TDD. This is because the senior colleagues are constantly debugging their code while the junior developer knows exactly where he's at and why that something broke.

Obviously the developer's understanding of what constitutes good design has an effect on how good the design ends up being. Yet, I claim that the same developer will end up with a better design using TDD than he would have by simply drawing class diagrams beforehand and then trying to implement the design. That is, unless you're talking about a really trivial problem.

Originally posted by Edwin Dalorzo:
2) Now, as the develpment process appears to be, to some degree, uncertain, I would like to listen what is your experience with this tecnique when it comes to project estimation, does TDD not make estimation more inaccurate?

That's not my experience at all. The technique you use to implement functionality has relatively little to do with how long you estimated it will take. Obviously at first it's more difficult, but it shouldn't take more than a couple of rounds until you're back to your normal accuracy with your estimates.
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Thanks very much, to both of you, for your insight.

Now I will do part.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Edwin Dalorzo:
1.) As far as I can see TDD seems to be a techinique for more experienced developers. It does not seem to be a tecnique good for the junior ones, since it not only implies mastering the concepts of unit testing, but also all these refactoring issues, which in good theory, should come out with a good design. This imply that the programmer has to be experienced enough as to take good design decision on the way that will result in good application design.


My experience is exactly the opposite. I've learned good design mainly by applying refactoring techniques. I think there are at least three reasons for this working:

- most refactorings (and the associated "code smells" concentrate on rather local design decisions. Those are easier to handle than the big design picture - the beginner won't feel as easily overwhelmed by the decisions to make. With the time, he will get a better and better understanding of the more global effects of his decisions.

- a beginner will make lots of "wrong" decisions, naturally, and needs lot of early feedback. TDD is much better at giving early and frequent feedback on the effect of design decisions than separating designing from coding.

- while a beginner learns, he will start to understand where his existing designs lack in elegance. Refactoring is exactly the technique he needs to put the newly learned into action immediately.

2) Now, as the develpment process appears to be, to some degree, uncertain, I would like to listen what is your experience with this tecnique when it comes to project estimation, does TDD not make estimation more inaccurate?


My experience matches that of Lasse. What is uncertain is what exactly the final design will look like. How much *time* it will take to come up with that design is by far not as unpredictable as it might sound to you now.


As for the threading issues you asked me, the application I am working initiates a set of threads. The number of threads is fixed, but customizable. Some of these threads are reading from one or more message queues. When the queue is empty then the thread that realizes that the queue is empty asks the other threads to stop. When there are messages back in the queue, this only running thread wakes up the other threads one by one.


Mhh, sounds to me as if the simplest thing that could possibly work would be if every worker thread that didn't find something to work on in the queue would do a wait(), and the queue would do a notifyAll every time something is put into the queue. What do you think?

I would like to test that the threads really stop when the queue is empty and that the threads really wake up when there are messages in the queue


I'm sure this can be tested for, although I'm not sure that, if the above strategy sounds right, I would really do it.

what happens to the message when it cannot be delivered


This doesn't sound to me as if that has something to do with threading at all?

what happens to the message when I ask the thread to interrupt.


Why would you ask a thread to interrupt?
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Edwin Dalorzo:

2) Now, as the develpment process appears to be, to some degree, uncertain, I would like to listen what is your experience with this tecnique when it comes to project estimation, does TDD not make estimation more inaccurate?


I've found the opposite. Doing TDD gets me into a fairly natural rhythm due to its tiny cycles. Having done it for a while, I've gotten a much better feel for how long it will actually take me to develop new software.

-Jeff-


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might find A Roadmap for Regression Testing of RDBs to be of interest.

It's not enough to test your app, you also need to test your DB.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: About Test Driven Development?