Test Case Generation Tool with Mockito

69 views
Skip to first unread message

Suhaasv

unread,
May 28, 2015, 5:40:42 PM5/28/15
to growing-object-o...@googlegroups.com
My team is trying to use code coverage (in some cases from 15% to 50%) . We do want to have sensible test cases and not just the coverage :-)

We use Junit and Mockito. I am wondering if there is a tool that would generate test cases that would include Mockito.Though I use Eclipse as my main IDE, I am open to changing it to to anything else including the good old command line option.

I am open to exploring options where it is not one step process as well.

I apologize if this topic was discussed on an old thread earlier.

Regards,

Suhaas

Suhas Walanjoo

unread,
May 28, 2015, 5:40:42 PM5/28/15
to growing-object-o...@googlegroups.com
Hi,

At our company we are trying to use code coverage (in some cases from 15% to 50%) . We do want to have sensible test cases and not just the coverage :-)

Regards,

Suhaas

Daniel Wellman

unread,
May 29, 2015, 8:04:10 AM5/29/15
to growing-object-o...@googlegroups.com
Hi Suhaas, welcome!  By choosing to try to write sensible test cases and not focusing just on test coverage, I think you will be on the right path to building a test suite that helps you and your team improve your software.  

What do you mean when you say you want to generate test cases, what do you mean?  Do you mean that you want to pass some production source code files to a tool and have it emit files that contain JUnit test case classes?  Or are you looking for some code libraries that will help programmers write their test cases by generating example inputs and outputs?  Or something else?

If it's the format (generate test code from scratch given production source code files), I've never found a tool that could both a) create sensible cases that made sense for my problem domain, and b) generate tests that were clear in their intent and would be easy to understand and maintain.  I haven't tried to use that many, so perhaps this has changed.  When I write tests I want to make them as clear as possible so I understand what they mean later, focused on specific cases so they don't break when unrelated logic changes, and when they fail I want them to point clearly to one problem.  I'll admit that I'm skeptical that a tool can do this well, but if one can, I'd love to hear about it! :)

There's another type of testing library where the programmer writes specifications for a program / object / unit of production code and the testing library attempts to generate inputs that either prove or disprove those specifications.  The most popular one I know of is QuickCheck for the Haskell programming language (https://wiki.haskell.org/Introduction_to_QuickCheck1) which has been ported to many languages.  In the JVM world, there's the Scala port called ScalaCheck (https://www.scalacheck.org/) which may work for your team if you can use Scala for your testing code.  I'm not sure if there's an equivalent Java version.


You had mentioned you wanted to improve test code coverage from cases such as 15 to 50%.  One way I've found to start gaining confidence that my production code is covered by tests (and make dramatic gains in code coverage) is to start by writing a few end-to-end tests that exercise the happy-paths of my system.  These would interact via a web browser in the case of a web application, or through an HTTP endpoint in the case of a web service.  These tests tend to cover large paths of the code and start to give me confidence that I have a safety net to catch errors.  

The danger I've seen with this approach is that these end-to-end tests are often very hard to write in a way that makes them consistent -- they tend to be flaky, and when a test fails it's not always obvious what code was wrong.  That's why I'd try to write just a few and then try to focus on writing more tests that work with lower-level objects in the system - and when something is hard to test, I see if there are ways to change the test that makes the code easier to take and also improves the design of the system by reducing coupling, introducing domain concepts, etc.

Cheers,
Dan




--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Suhas Walanjoo

unread,
May 29, 2015, 11:56:15 AM5/29/15
to growing-object-o...@googlegroups.com

Dan,

Thanks for your reply. Let me tell you what I have done so far. I have tried two Eclipse plugins, 1) Moreunit 2) CodeAnalyticsPro (was maintained by Google, abandoned now). I see that apart from generating empty shells of test methods, Moreunit also identifies mockable classes. OTOH, CodeAnalyticsPro  creates a lot of test cases with code inside them. It also identifies cases in which exceptions will be thrown. For starters, I am going to use both as general guidelines to create my test cases.

My scenario is export of selective data to MS Excel file from a web application. I am thinking something like Cucumber would be more useful than the standard JUnit + Mockito combination.

I would be interested in knowing more about tools that generate test input data. I had come across one such project on Github https://github.com/SecretDeveloper/TestDataGenerator.Core. Let me look at my notes and post it here later.

Did anyone ever use Google's tools to increase testability? https://code.google.com/p/testability-explorer/  It was based on Misko Hevery' presentations.

I would love to hear more from group members about their experiences on this front.

Regards,

Suhaas

Nat Pryce

unread,
May 29, 2015, 8:13:07 PM5/29/15
to growing-object-o...@googlegroups.com
If you've got existing (gnarly) code that you want to lock down with good coverage to catch regressions while you refactor, then have a look at approval testing: http://approvaltests.sourceforge.net/.  Combined with a (repeatable) way of generating test input data. it gives you a low-overhead way of gaining test coverage.

Suhas Walanjoo

unread,
May 29, 2015, 11:17:46 PM5/29/15
to growing-object-o...@googlegroups.com

Thank you, Nat!

Reply all
Reply to author
Forward
0 new messages