Vincent Massol

Originally posted by Jeanne Boyarsky:
Once Vincent's article is published, we can link to it from here.

As promised, here it is: http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html

Enjoy!

-Vincent

Originally posted by Vincent Massol:

We preferred to focus on giving keys so that Maven users will then know how to use Maven on anything including J2EE.

That said I should say that we did cover parts of J2EE (and IMO the most important parts!). Thus webapps are well covered for example.

Originally posted by Jeanne Boyarsky:

I agree with that. The problem wasn't the conciseness. It was the feeling that I couldn't sit down with the book and do a build of a J2EE application that uses the standard EAR/WAR structure. Certainly for less common things, I would use a web resource or wait for a more detailed book. That isn't the domain of the series. Vincent did say they are thinking about adding a web only chapter on EARs, which would make the book greatly more useful.

It was a difficult decision but we did not include a full chapter on J2EE simply for lack of space. We had to juggle with including some important and vital how-to on Maven vs focusing one full chapter on J2EE. We preferred to focus on giving keys so that Maven users will then know how to use Maven on anything including J2EE.

However, I did understand Jeanne's point and I told her that I would write an article on Maven and J2EE that I would post publicly and link it from the book's website. I have finished writing the article a few weeks ago and it's now in the hands of O'Reilly. It should be published very soon on http://oreillynet.com/.

Thanks

Originally posted by Jean Miles:
It really takes alot of work to create tests, I see all the benefits but it is hard to explain to project leads that if this is the first time we are create tests for code and takes a learning curve to understand what we are doing, but in time it will cut the time in testing changes introduce throughout the project.

There are different ways of doing it. One of them is to explain that typing code is only 50% of the work when developing an application. The other 50% is testing the code you've typed. You'll have to test it anyway (nobody will contradict this). Then you have 2 solutions, either you write some informal tests (like a quick main method, or simply deploy and start up the application and enter data, navigate menus, etc) or you write formal tests. Informal tests are lost and when you need to run them again (for example to test against regression) they are lost and you need to write/run them again manually. Thus what you need to demonstrate is that a good framework like junit (and extensions) lowers the barrier to writing automated tests. In due time, the cost is about the same as the manual tests but the advantages are tremendous as you can run them as often as you want to verify nothing is broken.
Now WRT to the training period, your manager need to bite the bullet. You can tell them that a single bug that makes it way to production will cost as much as spending tens of men day learning/writing tests. And when writing these tests you are 100% *sure* to find several of these bugs.
Then I guess it's a matter of asking for a proof of concept of some portion of the code, writing tests and showing that it's not that hard and how well it works.
Anyway, I know it can be difficult. However, in my past project I've never found any difficulty in convincing the managers. The only problem I've had is convincing them to give us the budget for these tests... So I usually start with a minimal lightweight testing strategy (we don't test everything and not all types of tests) and improve it incrementally across iterations.
What you absolutely need to do is include the time for writing these tests in your task estimations. If you separate testing time from coding time, you're in for trouble as manager may think testing is optional. And some developers may also think this...
Good luck!

Originally posted by Allan Halme:

Ah yes, but the purpose of the directory structuring was to avoid having to give funky names to the test classes ...

There are other advantages:
- a test is not simply made of a single test class. It can be composed of static Mock object classes, resources (like xml files, etc - Although in most cases, these resource could be created from inside the test classes but that's another subject of discussions )
- when you run the test you need different runners for different types of tests (they also don't run with the same lifecycle). Thus you need to separate them. Using name is neither efficient nor foolproof. It also leads to more complex builds. More importantly, in all tools you use, you'll need to find out how to exclude some tests/classes which may either not always be trivial or not supported.
- it's simply cleaner and easier for anyone new to the project. They'll understand right away the directory structure of the project and be able to run the tests more easily. Imagine if everything is together and they're in an IDE, they'll try to run some tests thinking they are pure junit tests for example, but it won't work as they are cactus tests (say). etc.
- using Suites to group test is not so nice as you'll often forget to add test classes to the suite.

Originally posted by Lasse Koskela:
Congratulations to all winners and big thanks to Vincent for hanging around!

And a big thank to you Lasse. You have impressed me a lot both by your moderation dedication and by the depth of your knowledge. Keep it up!

Thank you all for your interesting questions. A big thank you to JavaRanch for their warm welcome. It's really a nice place here.
If you wish to continue discussions, you can find me lurking on the following mailing lists/forums:
- for comments/questions about JUnit in Action's source code, please use the forum at http://sourceforge.net/forum/?group_id=68011
- for MockObjects related stuff, please use the following mailing lists: http://sourceforge.net/mail/?group_id=18189
- for Cactus related stuff, please use http://jakarta.apache.org/cactus/mailinglist.html
- for Maven related stuff, please use http://maven.apache.org/mail-lists.html
Of course, this is only for specific questions related to these topics. During the few days I've noticed that there are very knowledgeable people on this testing forum who can answer all kinds of questions! Congrats guys! Thus, for all general questions related to testing I really encourage you to continue using this forum. It's great.
Happy testing!

Originally posted by Mario Levesque:
Thanks Vincent,
I still prefer the paper format though. This way I can read and carry with me everywhere.
Mario

The book is now available in paper format through Manning: http://www.manning.com/massol
Thanks

Originally posted by bengt hammarlund:
will this book targeted at the experience developer or at the novice/experienced programmer?

It's for both junior and experience java testers. However, if you have little or no experience of Java beforehand, it'll be quite a challenge... It all depends what you mean by "novice programmer". I'd say the prerequisite is good knowledge of Java.

Originally posted by bengt hammarlund:
hi there! I have a question to the author: does your book cover how to correctly test methods that throw exceptions?
I've testing methods that throw exceptions like this:
- at first, I simply write a testXXX() throws Exception{}
- then, I write code that should throw an exception, an I catch it. But the testXXX() still throws exceptions, so I can test that my method really is throwing the right exception.
Is this procedure ok, or is there any other ideias in the book? Thanks for any reply!
I think exceptions are a very important issue, and something not that easy to test sometimes.
[ November 06, 2003: Message edited by: bengt hammarlund ]

Yes the book does cover it. Actually in most places you'll find that it shows how to test for positive and error paths. What you're doing seems right. There are several other best practices as discussed in the book, like use "expected" as the name of the exception you're expecting, etc.

Allan,
Then simply use different names. For example FooTest and FooDatabaseTest.

I think your best bet is to post your question on the httpunit mailing list...

Originally posted by Faisal Khan:
Vincent,
Thanks for being here and answering our questions. Another thing - does the book encourage developing test cases during the design phase or during development?
- FK -

During development. The book is about unit tests. These must be done during development. If you're talking about functional tests, my recommendation is to try to get them as soon as possible in the project's lifecycle, i.e. ideally you would get uses cases (UML for ex) + functional test cases at the same time and the goal of development is to implement code that passes these functional tests.

Originally posted by Bhushan Jawle:
Seeing the table of contents, I should admit that I will buy the book even if I don't win. As I see from previous threads, it has been mentioned by the author that the book covers about best practices for directory structure(question which used to haut me a lot)
It seems to talk about JUnit automation. Does it provide general guidelines as
1> How to identify the candidates for automation and what not to automate

Not really. Actually it's only a question of ROI. I personally feel everything should be automated. However, if you find that it takes too long to write a test, or that the test keeps breaking, then you need to decide:
- whether it is because your implementation is too complex and could be simplified (which would also lead to a simple test). This is good because if it's hard for the test to verify some API, it means it's going to be hard for the portion of the code that will be using it too.
- whether it is because you're not using the correct testing strategy. Thus for me, it's more a matter of being experienced in knowing what testing strategy fits better a specific testing need. And this is discussed in all the book.

2> Does it talk about guidelines on when to stop writing test cases (I know this question might draw a lot of comments. I am not against thorough testing, but, I think, at least in my case, there is a tendency to overdo the test cases :-) )
Thanks

Again, it's not a black or white question. The book does explain what is test coverage and shows some examples using Clover. That will show you what portion of the code you have covered in your test. However getting 100% is not a panacea (although it's very useful as a guide). What's more important is to write good tests. Kent Beck (I think) says "test until fear turns to boredom". That sums it up I guess...

Originally posted by Simon Brown:
If you want to test the tags at the component (i.e. tag) level rather than unit testing the individual classes, take a look at TagUnit. Basically it allows you to test custom tags via a JSP page.
[ November 05, 2003: Message edited by: Simon Brown ]

or cactus ;-)
BTW, I'd be curious to compare 2 test implementations, one using Cactus and one using TagUnit. That would be nice to set them next to each other.
I also think a TagUnit JSP can be easily wrapped by a cactus test if you wish to benefit from all Cactus integration tools (Maven, Eclipse, all JUnit test runners, etc). If I understand corectly, TagUnit writes test as JSPs so that would be something like:
public class MyClassTest extends ServletTestCase (or JspTestCase) { public void testXXX() { RequestDispatcher rd = theConfig.getServletContext(). getRequestDispatcher("/path/to/tagunitjsptestcase.jsp"); rd.forward(theRequest, theResponse); } public void endXXX(WebResponse) { // Assert returned page content here [...] } }