On Wed, Nov 21, 2012 at 5:47 PM, David Nalley <da...@gnsa.us> wrote: > Hi folks: > > Just a heads up on where I currently stand before the holidays in the US > begin. > I have master building and they run unit tests - and also cobertura is > reporting coverage reports in that job. > > https://builds.apache.org/job/cloudstack-master-maven/ > > I also have the RAT job running here: > https://builds.apache.org/job/cloudstack-rat-master/ > > Both of these poll git and run if there have been commits. > > --David
Super useful... thanks! I've been thinking about an appropriate strategy for how to start adding tests that have an impact, and I think the way to go is to look at analysis.apache.org's class complexity analysis [1]. If we were to start at the top of the class complexity chart, I think we would be adding significant value with each test that gets written. We could probably exclude the generated AWS code bits, as well as the code that isn't from our project (such as the Xen Java files). Depending on the individual class or method in question, we may find that refactoring is useful. (But of course, having a set of tests to confirm that the refactoring didn't break anything should be a prerequisite to making that sort of change! For example: com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer [2] is at the top of the chart for class-complexity, and a few minutes of looking at the source indicates that there is definitely a need to get some unit tests wrapped around this code! It's currently at 0% code coverage via unit tests [3], but we can say the same thing about lots of other files... Anyone have other ideas about how to prioritize unit test writing? -chip [1] https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity [2] https://analysis.apache.org/drilldown/measures/100206?metric=class_complexity&rids%5B%5D=100226&rids%5B%5D=102648# [3] https://builds.apache.org/job/cloudstack-master-maven/13/cobertura/com_cloud_hypervisor_xen_discoverer/
