Get a better web browser:<br /><a href="http://www.mozilla.org/products/firefox/switch.html" target="_blank" rel="nofollow">http://www.mozilla.org/products/firefox/switch.html</a>
Kishore
SCJP, blog
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Ali Pope:
Is Mr.Rainsberger explaining why the testing should be done only through public API? (this will give us a hint on the long thread of testing private methods ;-) )
Originally posted by Rickard Johansson:
I have heard people say that the argument for only testing the public interface of a unit is that you will be able to refactor the internal structure of the unit without having to change the tests. I guess that this comes from bad experience in projects where test discouraged people from doing codechanges since they would also have to rewrite the test (i.e. more work).
I myself find this a bit strange since a solid testbed should give developers the courage to refactor code and be confident they did not break anything.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Ali Pope:
So I would conclude from the aboves that this reason is in a way deprecated :-).
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
I'm also putting my tests in a separate source folder but in the same Java package as the production code, i.e.
Get a better web browser:<br /><a href="http://www.mozilla.org/products/firefox/switch.html" target="_blank" rel="nofollow">http://www.mozilla.org/products/firefox/switch.html</a>
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
How so?
I guess that this comes from bad experience in projects where test discouraged people from doing codechanges since they would also have to rewrite the test (i.e. more work).
Originally posted by Lasse Koskela:
I'd recommend JUnit Recipes for a more thorough discussion of various JUnit "best practices".
Originally posted by Ali Pope:
Wow... many horseshoes.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
I guess that this comes from bad experience in projects where test discouraged people from doing codechanges since they would also have to rewrite the test (i.e. more work).
Originally posted by Ali Pope:
Moreover, the discussion on the testing private methods thread seems to prove that the unit testing is not meant only for public API.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
You won't regret it, I guarantee.Originally posted by Ali Pope:
I think I will trust your reviews and go for the book.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
Well, regardless of how good a state your project is in with regard to unit testing, it's always a good idea to make sure that your tests don't become more brittle than they need to be. With that in mind, I'd say testing only through the public interface is a good rule. When a test knows too much about the code under test, it becomes brittle by definition ("too much"). And then we're back to the point about wanting to test a private method being a code smell saying there's functionality that would benefit from being extracted into its own class.
Originally posted by Lasse Koskela:
You won't regret it, I guarantee.
Originally posted by Rickard Johansson:
I have heard people say that the argument for only testing the public interface of a unit is that you will be able to refactor the internal structure of the unit without having to change the tests. I guess that this comes from bad experience in projects where test discouraged people from doing codechanges since they would also have to rewrite the test (i.e. more work).
I myself find this a bit strange since a solid testbed should give developers the courage to refactor code and be confident they did not break anything.
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/1932394230/ref=jranch-20" target="_blank" rel="nofollow">JUnit Recipes: Practical Methods for Programmer Testing</a>
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/1932394230/ref=jranch-20" target="_blank" rel="nofollow">JUnit Recipes: Practical Methods for Programmer Testing</a>
Originally posted by J. B. Rainsberger:
I'm merely pointing out that when I think of refactoring, I don't think of writing new tests; instead, I think about changing code so that it still passes the existing tests. When I'm writing new tests, I assume it's to add new features. The generally accepted view of things is that one either refactors, or adds new features, but never both simultaneously.
Originally posted by Ali Pope:
Lasse good news: right now it is on my download manager! After finishing the current one I will go for it!
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Ali Pope:
I am not I am getting this . Manning is also offering the book in pdf format which is the only possiblity (for my country) to have the book asap.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007434/ref=jranch-20" target="_blank" rel="nofollow">JUnit Pocket Guide</a>
There aren't too many ways to separate test classes from production classes. You can separate them by naming convention or by their physical location.Originally posted by Ali Pope:
Kent are there any particular reasons behind these types of organization or it is just the natural ways?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Yeah, but how did the squirrel get in there? Was it because of the tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|