wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Level of Java experience assumed, java version? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Level of Java experience assumed, java version?" Watch "Level of Java experience assumed, java version?" New topic
Author

Level of Java experience assumed, java version?

Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Greetings authors,
A few quick questions.
What level of Java experience is assumed by the book?
Does the book address any techniques specific to JDK 1.4 capabilities (NIO, asserts, etc.)? JDK 1.5?
thanks,
Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Jeff Langr:
Does the book address any techniques specific to JDK 1.4 capabilities (NIO, asserts, etc.)? JDK 1.5?

I doubt it. I am not one of the authors nor do I know the table of contents by heart, but I'd say none of the JDK 1.4 features (and definitely not 1.5) are significant from extreme programming point of view.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Lasse Koskela:

I doubt it. I am not one of the authors nor do I know the table of contents by heart, but I'd say none of the JDK 1.4 features (and definitely not 1.5) are significant from extreme programming point of view.

The "assert" capability is significant from an XP viewpoint--does one even use the native assert keyword when doing test-driven development? Why and when would you do so? (There are articles that discuss this topic)
Techniques for how to best test things such as logging are also significant.
-Jeff-
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Jeff Langr:
The "assert" capability is significant from an XP viewpoint--does one even use the native assert keyword when doing test-driven development? Why and when would you do so? (There are articles that discuss this topic)
Techniques for how to best test things such as logging are also significant.

I did think about the asserts, but ended with the initial opinion that they are insignificant. Perhaps "insignificant" is too strong a word, but still.
As you mentioned, with TDD you can't write the tests within the code that is to be tested--there is no code at that point. I agree that using asserts within the code is a good thing, if anything. However, I don't think this has anything to do with XP.
Regarding logging, I haven't had the need to test logging code (except for certain audit trail stuff, but I don't count that as logging). Could you shed some light to the value of testing logging code?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
agree that using asserts within the code is a good thing
Interesting. In my experience all that putting asserts in the production code has ever done for me is bloat the delivery to no benefit.
I believe in unit testing.
If I recognize that a failure condition can occur I'd much rather write a unit test for the situation, and thus design the system not to fail in that way in the first place. In this situation, in-code asserts gain me nothing.
If I don't know that a failure condition could arise, then I won't think to put an assert in the code. In this situation, in-code asserts gain me nothing.
Can someone explain what the benefit of in-code asserts might actually be, and what situations they would consider a good use for in-code asserts?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Frank, your opinion about the actual benefit of deploying assert statements within code is not uncommon. Actually, I kind of agree.
But. When you leave code-bloat out of the picture, asserts are just a way of doing whitebox testing within the box. Is it that bad? No. Is it of any good? Not if you do good unit tests. It's really up to the developer. Again...
PS. You left out the latter part of the sentence, "if anything". It was supposed to imply that asserts can be good or neutral but not bad (assuming the developer doesn't have an obsession towards excessive use of redundant or otherwise unnecessary asserts...).
[ May 14, 2003: Message edited by: Lasse Koskela ]
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
I test virtually everything: all functionality in code should exist only because there is a spec for it, and the tests are your specs. Logging is a functionality. How do you know the logging works properly?
I'm not sure there is a high value of testing logging, but in some environments logging is a critical aspect of the system. Depends on whether you view logging as a system trace facility or as an audit trail. Also, testing logging should start to minimize the tendency to log too much information.
-j-
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Lasse Koskela:

As you mentioned, with TDD you can't write the tests within the code that is to be tested--there is no code at that point. I agree that using asserts within the code is a good thing, if anything. However, I don't think this has anything to do with XP.

It may not have anything to do with XP. But it does have something to do with my original question: Does the Java cookbook discuss the applicability of the "assert" keyword in light of XP?
The original point of the question was, is the XP Cookbook going to answer all my questions about the latest version of Java that I happen to be using? Or is it limited to Java generalisms? It's not meant to be a critical question, just a curious one.
-j-
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Jeff Langr:
I test virtually everything: all functionality in code should exist only because there is a spec for it, and the tests are your specs. Logging is a functionality.

I agree that every requirement should be verified by tests (or testing). I usually think of logging as a kind of "extra feature," added to support development/maintenance. Of course if you have a requirement for persisting all business transactions and you implement it by logging (as in Logging API, Log4j, etc.), then that part of logging should be tested somehow. Should it be automated or not, can't really say.


testing logging should start to minimize the tendency to log too much information.

Yep. In fact this holds for nearly everything done with TDD.
Brian Coyner
Greenhorn

Joined: Mar 22, 2003
Posts: 7
Originally posted by Jeff Langr:
What level of Java experience is assumed by the book?

Our book has many specialized chapters. For example, if you want to use XDoclet to generate EJB code, then you'll have to be familiar with EJBs. If you want to use Cactus to test web applications, then you'll have to be familiar with Servlets and JSPs. Ant is covered on almost every page of the book, so if you know the elements of an Ant buildfile you are okay.


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596003870/ref=jranch-20" target="_blank" rel="nofollow">Java Extreme Programming Cookbook</a>
Eric Burke
Greenhorn

Joined: May 12, 2003
Posts: 7
I just went to a lunchtime meeting with a bunch of people who specialize in real-time CORBA and embedded C++ systems-level programming. We were talking about assertions and how they relate to unit testing. The general concensus among these experts was that assertions are particularly useful in cases where you may have very complex threading logic that is difficult if not imposible to test.
I don't find myself using assertions often. I generally think that a good unit test is the first line of defense. But in cases where tests don't cut it, assertions are a useful tool.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Level of Java experience assumed, java version?
 
Similar Threads
anyone know a good java book?
Java EE 5 Development with NetBeans 6
Prior knowledge of Groovy required ?
Tomcat
About the Book