Another "Does your book..." type question

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

[Vincent Massol]

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

[Java Joe]

I read a review of the book on Amazon, which was glowing on the value of this book, and would agree with the earlier post that this book would be a good one to have regardless of "winning" it.
The concept of testing everything, and doing regression testing is something that interests me, and the use of ANT to achieve this. The Amazon display of the "contents" did not reveal a table of contents that the prior post had aluded to (probably because they have actually seen the book).
Does the book touch on the use of ANT in automating testing?
My use of JUNIT has been light, but I can certainly see its value.
It does seem to be time consuming to think in both the development of something and addding code for the testability to put JUNIT to use causes "brain switches" - which is possibly a good thing to insure that the quality is there up front.
I look forward to seeing the actual book.

[Lasse Koskela]

"Java Joe",
May I ask you to change your display name -- it's obviously fake, which goes against our naming policy.
Thanks.
PS. You can find the table of contents for Vincent's book at http://www.manning.com/massol

[Bhushan Jawle]

Thanks Vincent.
"Java Joe",
You can see the TOC on Mannings web site