File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Testing and the fly likes Effective Unit Testing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Effective Unit Testing" Watch "Effective Unit Testing" New topic
Author

Effective Unit Testing

gb Bhatnagar
Greenhorn

Joined: Nov 16, 2012
Posts: 1
Hi Lasse,

We often try to figure out what is the best testing framework to test our code, we may end with selecting Mockito or Easymock , or powermock or jmock or any other framework in general, depending upon which framework offers best approach may be which can mock Interfaces or static or private methods etc. But it may happen that the way code is written that itself is bad and we are simply trying to test badly written code and hence looking for all high feature frameworks. What is your view on such scenario. Should developer first get his/her code reviewed and then start writing Test cases or should first developer do coding and unit testing and then hand over code for review.

Many Thanks,
Gaurav Bhatnagar
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
The best way out of a hairy situation is to avoid getting into the situation in the first place. You're quite probably right on the money about the real issue not being about selecting the right tools but the badly written code that makes you look for such tools.

Regarding review-design-first-then-write-tests vs. write-test-first-then-review-design, my preference is the combination where you review the design every step of the way as you write tests, one at a time. Doing test-driven development, I validate (review) the design I'm about to implement by first drafting test code that uses that design. Once I see that the design makes sense from the user's point of view, I proceed with making the test compile and pass the test. Another alternative might be to pair developers with each other and encouraging them to review each other's code as they're writing it rather than after the fact.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Effective Unit Testing