My latest work project has been implementing a solution for generating regression unit test programmatically for an android companion app for a sport / military medical appliance. Anybody who has written a unit test knows there are two camps of thought for writing tests; maximum coverage at any cost, and smaller quantity but better business logic tests that do more than just implement a method. These regression tests I am generating are of the former variety, contrary to my recommendation. Why? Because the client believes that to get their class B FDA software certification, that they must have that shiny > 85% code coverage number on their application. Little do they know these tests would never stand up to an audit by the FDA.
All that aside though, what tools can you use to proceduraly generate java package unit tests? Two tools specifically deserve a shout-out here. CodePro Analytix, and AgitarOne. CodePro, after being bought out by Google some years ago, was donated to the Eclipse foundation and has since, to my knowledge ceased any and all development. CodePro is a plugin for Eclipse that can be used to perform procedural code audits using custom code style rules, and to generate junit regression tests. That said, without some modification, the plugin will not utilize Android specific system classes, and instead result in a code stub when executed. On the other hand we have AgitarOne, a paid solution that utilizes a server / client solution. The server is a JAR that runs in the background and can be configured to to utilize a slave / master node configuration for large test automated build environments. The client is yet again another Eclipse plugin (why the fuck do people have a hard on for Eclipse? Android support has all but been deprecated at this point IMO!). I have yet to play around too much with the "Agitation" feature, but I assume it is just another procedural code audit utility, however, the junit test case generation feature of AgitarOne does allow for custom system class files to be added by the user before the generation request is submitted to the server for execution and result return.
So... Yeah, TL;DR: Unit testing = good. Unit testing for the sake of testing (aka intern work) = bad. If you have to do it though, AgitarOne might be for you.
Not much documentation on the subject matter exists. I have spent too many billable hours researching the subject matter, and finding these tools. I hope this information is useful to at least one of you here, or at minimum provides you with some level of entertainment value.
Cheers,
-CloudPlumber
Might update this as the project proceeds.
EDIT #1:
Since this post was originally authored, this project has since concluded. The client's app was setup from the beginning to use ANT as the builder, not something I myself would have done, but hey, you work with what you are handed. That said, in order to use these Eclipse based plugins for regression unit testing, the project had to be modified to build correctly inside of Eclipse using ANT. Doing so turned out to be more challenging than I would have expected due to the limitations imposed by the Win32 build of Java 8 for Windows. You see, ANT is distributed by the Apache foundation as JAR file, with a .BAT launcher, which is referenced by a Windows system PATH variable when the "ANT" command is issued by the user or an IDE, aka Eclipse. That said, you can see where some potential problems might arise. So, since this project is to eventually set to be built in conjunction with a continues integration utility such as TeamCity, in a Debian environment; we simply migrated this part of the project to an Ubuntu 16.04 LTS VM running a build of the Oracle JDK 8, and Eclipse with the appropriate plugins, and hey presto, problem solved!
At this point we generated all of the appropriate regression unit tests using AgitarOne, and Robotium. Doing all of this in a VM also made it so that our only deliverable became a simple VMware Workstation VM file containing a working dev environment capable of generating future tests, and executing existing tests. That and a bucket-load of documentation outlining our process and previous test results.