wood burning stoves*
The moose likes Beginning Java and the fly likes Agile Java: to the author Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Agile Java: to the author" Watch "Agile Java: to the author" New topic
Author

Agile Java: to the author

miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
i'm an inexperienced java amateur but i like to read about and i've this Q: does your book deals with the paradox of writting a test, see it fail, write some code, see it green, refactor and so on and on and then, where does patterns and good OO design come in? How does one know in which direction is going? does one has to be a big boss in programming to do it tdd?
thank you


java amateur
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Greetings Miguel,

Thanks for the posting. I think you win the honor of being the first.

The book teaches you the whole testing cycle, also known as TDD (test-driven development), from day one. Write test code, demonstrate failure, write production code to meet test specification, demonstrate success, refactor, demonstrate success (i.e. that you haven't broken anything). In fact, this cycle is the core of how I present the book.

What I've found is that coding in this fashion makes it far easier to learn a new language. I monitor this forum from time to time. What I've noted is that beginning Java developers often have the same kinds of problems. They tend to write large chunks of code, and then spend lots of time trying to figure out why it doesn't quite work the way it should. They insert lots of System.out.printlns.

In contrast, learning using TDD means you get far more rapid feedback. You write a small bit of code that says what you expect to happen. You don't proceed until you've written that small bit of code to actually make it happen. This helps you avoid quickly going down a debugging rathole. It's also very satisfying and rewarding--you get a constant feedback that you're headed in the right direction at all times.

One other thing: many shops are finding that TDD is very valuable, and are adopting it as a standard way of coding. It seems a shame to learn how to have to relearn how to code. Agile Java tries to teach you the "better" way the first time around.

You definitely don't need to be a big boss in order to code this way. It's simple, and any new Java developer can learn it with ease. You can also do it on your own, even if you're the only one in your shop that knows about it. Chances are other people will see the improvements you're getting out of coding with TDD, and will want to try it for themselves.

Agile Java does talk about different aspects of design. You mentioned refactoring; it's important that you understand what to do in this refactoring step. Otherwise you run the risk of making the design worse. Throughout the book I provide little bridge icons that point to tips for success: what are the kinds of things you should be doing in order to keep your code and design clean? I demonstrate the use of patterns in several places, and there's some UML to help you get a pictorial view of what's going on.

One thing I can't state enough: I've met dozens of developers who have given TDD an honest try for a month. Some of these people are Java wizards, people who've done Java since day one and are the experts. They are all amazed at the benefits they've gotten out of TDD, and none of them want to go back to the "old way" of doing things. None of them!

Regards,
Jeff


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

Joined: Feb 08, 2004
Posts: 1281
thanks a lot for your answer
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Let's continue down this path.

So, when writing tests first, the test code itself, does it have to compile? Meaning if I write a test to test my classA.methodA(int a), but ClassA has not been written yet, so therefore the test fails to compile. Or do you write your Class stubs so that the test will compile but just fail?

Is there a rule of thumb, on the number of lines to code before repeating the cycle?

You had mentioned about debug, and the amount of code that needs to be debugged, if you don't test first. Along those lines, I tend to design top-down, then code and test bottom up, so that when I am doing the big test of everything, All the levels below have been tested and that any errors are at the top level, and can concentrate finding bugs there.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Greetings Mark,

Thanks for the questions!

Initially the test will not compile, at least not in most cases. That's level one of feedback.

The way you deal with this depends on your preference of technique and experience; there's no one right way. When starting out, the best approach is to observe the compilation failure, then write just enough code to make things compile. This allows you to become familiar with some of the compilation error messages and how to resolve them--something that's always valuable. Once you've gotten things to compile (progess!), then write the code to make the test pass.

As far as the number of lines to code in a given cycle, the rule of thumb is "as few as possible." Let's say your test invokes a method named buildPart. There may be a few side effects of buildPart. You may ultimately need two or three assertions to completely demonstrate that buildPart worked.



(Not a great example, eh?) As I build the testBuildPart() method, I'll provide just enough code in the Engine class to get this single assertion (assertEquals) to work. Then I code any additional, relevant assertions, one by one, and supply the correct code in Engine with each added assertion:



There are many subtle benefits to constructing the code this way (and if someone asks, I can talk about those).

Ultimately the number of lines is a comfort and confidence level. As you become more experienced, you might write more lines of code before getting feedback. But I've done TDD for about five years, and I still find that the smallest steps are the best.

Your approach sounds solid, and sounds like it works well for you. It's similar to how I approach things. One thing I have noted is that building from the inside out (I use this term instead of bottom up) often alters the original design intention. I now find myself building from the middle out, in both directions.

Regards,
Jeff
[ March 08, 2005: Message edited by: Jeff Langr ]
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
i found this sample chapter
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
There are many subtle benefits to constructing the code this way (and if someone asks, I can talk about those).

one i've read about is that you get clean interfaces from the classes one's building (this is just to get a change to keep listening to this subject )
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

I now find myself building from the middle out, in both directions.


That's interesting. Usually in Detail Design, I have gotten to the point detail level in my sequence diagrams that writing the code is merely typing. And yes there will be a few design issues that I find out won't exactly work when coding, but they are usually really small. So that coding from the inside out, the inside is usually a really small chunk of code, which I can test by itself and test quickly because it is so small.

Thanks

Mark
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Depends upon what you refer to as the "inside." ;-) I find that if you do your design well, most of the "sides" are small and easy to test.

I'm still waiting upon an introduction in this forum, I'm not sure whether or not I should be posting yet!

-Jeff-
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Originally posted by Jeff Langr:
Depends upon what you refer to as the "inside." ;-) I find that if you do your design well, most of the "sides" are small and easy to test.

I'm still waiting upon an introduction in this forum, I'm not sure whether or not I should be posting yet!

-Jeff-


Heck, if Dirk doesn't introduce you, then I guess the entire conversations will be just you and me. But on the bright side, I'd get 4 copies of the book.

Mark
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
I'm still waiting upon an introduction in this forum, I'm not sure whether or not I should be posting yet!

I guess its all my fault!
yesterday i was browsing this forum and then i saw this link where your book was anounced with yesterdays date. So i took the initiative of posting here. In the meanwhile i received a forum's newsletter only annoucing the other book promo...

On the other hand:
Heck, if Dirk doesn't introduce you, then I guess the entire conversations will be just you and me. But on the bright side, I'd get 4 copies of the book.

Mark
i hope Mark wouldnt bother sharing one with me
Sorry if i caused any trouble
Ben Wood
Ranch Hand

Joined: Aug 14, 2001
Posts: 342
Hi Jeff,

Your book sounds very interesting to me, and could be extremely useful. The organisation I work for is currently on the Java learning curve; a few of us are using it already because we came in with Java skills some years ago, largely developing internal web-based applications, but most developers are using frameworks such as ColdFusion, which makes it easy to write messy, unmaintainable code. There has now been a commitment to increased usage of Java and so far we have trained around 50 staff in Java, and 20 of these in J2EE, using a combination of in-house and external courses.

We are not a software house but there are many developers working here on our various applications, often dealing with complex requirements and data. many developers are not CS graduates and, like me, have moved across from a scientific background. The main problem we face is ensuring that each developer (whether using Java or not) has some guidelines for producing quality code.

We are at a stage now where we need to think in terms of a "corporate" development approach that everyone will adhere to...one idea we had was to use XP. I was wondering if you have any experience of entire organisations or software houses who have adopted the TDD methodology and used agile techniques and how this affected the quality of the resulting systems, how was productivity affected and, perhaps most importantly, how the developers and designers responded to the culture change?


SCJP 1.4, www.gsi3d.org.uk
Nigel Browne
Ranch Hand

Joined: May 15, 2001
Posts: 673
Hi Jeff,
I really enjoyed the sample chapter so I've ordered a copy of your book. While I am waiting for it to come through the post can you tell me how in depth in your coverage on multi threaded testing and testing swing.
Apart from JUnit are there other open source project I'll need to run the examples in your book?
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

Originally posted by Jeff Langr:

I'm still waiting upon an introduction in this forum, I'm not sure whether or not I should be posting yet!
-Jeff


Sorry about that, Jeff. You've now been introduced here, so you can mosey over there and enjoy the "welcomes."


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Ben Wood:
I was wondering if you have any experience of entire organisations or software houses who have adopted the TDD methodology and used agile techniques and how this affected the quality of the resulting systems, how was productivity affected and, perhaps most importantly, how the developers and designers responded to the culture change?


Greetings Ben,

As one example, I did a small bit of consulting at Sabre, where the VP there mandated use of XP and thus TDD throughout the entire development shop. This covered 300+ people and perhaps 15 to 20 teams. While successes varied from team to team, there were at least a few teams with very low defect rates. Here's a quote from an older article, located at http://www.sabreairlinesolutions.com/news/030223_Hand-to-Hand_Teamwork.htm:

"In addition, quality has vastly improved. In two cases, software products were rewritten entirely with XP, and the defect rate was less than 10 percent of that in prior versions."

Kent Beck's 2nd edition of Extreme Programming Explained has a more recent interview with the VP, Brad Jensen, where he reaffirms the success of XP within Sabre.

That's not an anomaly; there are many other citings of shops whose defect rate has decreased dramatically. TDD alone accounts for a good chunk of this; bolstering TDD with other disciplined practices such as those in XP (e.g. pair programming or code inspections) can add to the improvement.

The culture change is different if you're talking XP/agile vs. TDD. You can do TDD exclusively of anything else and obtain significant benefits. It doesn't appear to create a significant cultural impact, other than the fact that by example you may set the bar higher for your peers.

XP, on the other hand, has dramatic impacts to the culture. A consistent percentage abhors XP and won't do it. The bulk of the masses, however, are more accepting but skeptical. After a few weeks on an XP project, most of these people either embrace XP, or accept it due to recognition of some of its benefits. When all is said and done, the diehards--those who still refuse to do XP honestly--account for perhaps one or two in 20.

Agile Java, by the way, doesn't really talk much about XP. It's more about improving your development skills, again something that you can always do.

Regards,
Jeff
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Joel McNary:
You've now been introduced here, so you can mosey over there and enjoy the "welcomes."


Thanks Joel!
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by miguel lisboa:
i hope Mark wouldnt bother sharing one with me
Sorry if i caused any trouble


No worries, I think I was excited to be here, so I jumped the gun. ;-)

-Jeff-
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Nigel Browne:
Hi Jeff,
I really enjoyed the sample chapter so I've ordered a copy of your book. While I am waiting for it to come through the post can you tell me how in depth in your coverage on multi threaded testing and testing swing.
Apart from JUnit are there other open source project I'll need to run the examples in your book?


Greetings Nigel,

You won't need anything other than JUnit, the Java development kit, and an editor or IDE. I always recommend that people learn how to program using a simple editor (vi, emacs, TextPad, UltraEdit) and the command line--that way, you're always able to compile and run Java programs on virtually any machine.

But once you get going, you'll probably want a full-fledged IDE such as IDEA or Eclipse. There's an appendix in Agile Java that steps you through getting started with IDEA.

My coverage on multithreaded programming is reasonably in depth. It's one chapter, 40 pages worth. It goes through all the basics, and touches on the new concurrency utilities (which greatly simplify things) introduced in J2SE 5.0. I try to demonstrate how you can test multithreaded code, although (a) there are tools out there that will help, and (b) some people are resigned to believe that there's no effective way to do so.

I cover Swing in two chapters. These chapters provide enough information to get you going, and teach you where to look for more. The main thrust is not so much to cover everything significant about Swing. Instead, the goal is to show you that you can test Swing code, and how to best approach it. You'll learn enough Swing to produce a reasonably sophisticated application: basic widgets, tables, layout, field editing, listeners, and more.

Regards,
Jeff
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Spritzler:
Usually in Detail Design, I have gotten to the point detail level in my sequence diagrams that writing the code is merely typing. And yes there will be a few design issues that I find out won't exactly work when coding, but they are usually really small. So that coding from the inside out, the inside is usually a really small chunk of code, which I can test by itself and test quickly because it is so small.


One approach you could try at the higher level is to use mock objects for the parts you haven't yet coded.

When you take a look a look at your sequence diagram, and start to code your high level objects, you know what methods you expect them to call on the more low level objects, and how you expect the low level objects to react. So you don't really to fully code your low level objects to test the high level ones - you can replace them by mock objects that just return hard coded values or the like.

I see several potential advantages to this way of working:

- it forces you to strongly decouple your high level objects from the low level objects, because the high level ones have to work with at least two versions of low level objects: mocks and production objects. That makes your design much more flexible.

- tests for high level objects are often easier to write, because you don't need to setup up all the objects way down to the lowest level. Also special conditions in the collaborators of the object under test might be much easier to provoke in mocks than in production objects (say, raising an IOException).

- you might need to write a lower number of tests, because you don't need to think about the ways all the lower level objects interact for your high level tests.

- test failures are more focussed, because problems in low level objects don't cause tests for high level objects to fail.

- tests are likely to run faster, because mocks don't need to compute much.

Of course you might still want to write some integration tests to see that all your objects work well together, but in my experience the number of those tests can be quite small.


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
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Thanks Ilja, some great thoughts.

Agile Java does go into mocking, and shows a few different techniques for doing so. Once you've come up to speed in basic Java development, you'll want to explore other books on test-driven development. These books go into greater detail on mocking and other testing techniques. (However, they assume you already know how to program in Java.) Kent Beck has a book on TDD, as do Johannes Link and Dave Astels.

thanks,
Jeff
Sean Magee
Ranch Hand

Joined: Aug 23, 2004
Posts: 69
Hi Jeff,

I have been hearing a lot of interesting topics pertaining to your book.
I am a beginner in java, so of course there is much improvement to be attained for developing. Where the curiousity seeks in is, Will a beginner benefit from Agile Java as much as an intermediate or expert? What kind of improvements would I see in my own developing due to TDD and topics discussed in your book?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

you can replace them by mock objects that just return hard coded values or the like.


I think Mock Objects are a bad idea, it hides functionality that you need to see if it works with everything else. Integration.

Also it takes time to stub out classes and create Mock Objects, that I'd much rather spend in coding real code. In the case of Mock objects like acting as a Servlet, so that you can run the tests locally is fine, but we have a Command Object that we pass to one simple Session Bean, that will allow us to run our tests on the server, and not need the mock objects. With remote debugging, it is very quick and easy to fix bugs. Again I believe this tests things more to the real world, and makes your tests better.

By writing the small inner objects and testing those, you will find that it goes a lot faster than working on the outside, stubing/mocking the inside, then having to create the inside and test that again, then run the outside tests again to make sure you haven't broken anything.

Mark
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
I'd have to agree that mock objects present problems of their own. I had a very bad firsthand experience working on a system where the developers had overused (abused) mocks. I ended up writing a paper on this topic. It discusses the dependency issues that drive the use of mocks, and also talks about the design implications of using mocks.

I'd also be concerned if it was taking a long time to code up mocks and maintain them; that suggests they are getting out of the realm of simple testing technique. Like many things, the judicious use of mocks can be very beneficial, but when overused or misunderstood, they can be devastating to a system's flexibility, trustworthiness, and dependability.

-Jeff-
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Sean Magee:
Will a beginner benefit from Agile Java as much as an intermediate or expert? What kind of improvements would I see in my own developing due to TDD and topics discussed in your book?


Greetings Sean,

Thanks for the question. Agile Java is targeted at the beginning Java developer. It could also appropriate for an experienced Java developer who wants to relearn how to program in Java the TDD way.

I've observed a lot of questions in this forum about small homework exercises, simple starter applications, and so on. The thing I've observed most is that beginning Java developers seem to trip over a lot of simple things. They code too many lines at once before getting feedback. They then post 50+ lines of code and ask others to spot the error that they can't figure out. This doesn't happen nearly as much when you're doing TDD.

When doing things using TDD, the "Agile Java" way, you'll learn to take smaller steps. This reinforces basic language concepts and also teaches you how to avoid making lots of mistakes all at once. You should see dramatic improvement in your approach to coding after only a few weeks of practice. You'll spend a lot less time going into debugging mode.

Most developers have a light-bulb reaction after 3-6 weeks where they get it; the usual response is "wow!"

I won't kid you; it's radically different and at first will seem counter-intuitive. Patience during the first couple of weeks helps. But in all likelihood, you'll never want to go back to the old way of doing things.

-Jeff-
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mark, our experiences seem to differe enormously. I'm quite sure that the way I use mock objects it saves time for me and improves the feedback from my tests.

We could explore the reasons for our differences, but that'd probably better be done in a different forum...
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Originally posted by Ilja Preuss:
Mark, our experiences seem to differe enormously. I'm quite sure that the way I use mock objects it saves time for me and improves the feedback from my tests.

We could explore the reasons for our differences, but that'd probably better be done in a different forum...



To The Test Mobile, Batman.

Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Agile Java: to the author
 
Similar Threads
Java vs. Javascript
What is your opinion about Ruby?
What is Groovy and in which cases we need Groovy?
try catch performance overhead...
howto detect powerpoint