Agile Java: to the author

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

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

thanks a lot for your answer

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

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.

public void testBuildPart() { final String partName = "blend door"; Engine engine = new Engine(); factory.buildPart(partName); assertEquals(1, engine.getPartCount()); }

(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:

public void testBuildPart() { final String partName = "blend door"; Engine engine = new Engine(); factory.buildPart(partName); assertEquals(1, engine.getPartCount()); assertTrue(engine.contains(partName)); }

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 ]

i found this sample chapter

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 )

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

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-

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

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

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?

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?

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."

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

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

Thanks Joel!

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-

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

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.

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

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?

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

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-

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-

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...

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