-1

I am Currently working on a big java project, which needs to be managed in bigger & better ways. It is using SVN , Hudson , Sonar. After multiple checkins in a day , a nightly Hudson build is run , which also runs sonar , hence giving the new stats ( of code coverage , complexities etc ). But these numbers are not very useful as of now as they tell situation / figures after checkin.

The practical situation is that , with every checkin the code covergae is decreasing. Now we want to bench mark the figures at present level. Lets say Code Coverage presently is at 45% What we want is the next checkin should be allowed if and only if it increases code code coverage % else not.

My question is how this can be done ??

I did some research around , came to know of two possible ways

  1. Use SVN Hooks
  2. Use Continuous Build servers like Hudson

For 1st Option found link / tutorial : Can i run a script when i commit to subversion?

The following two links seems to suggest 2nd option is better ( as it has much less checkin time)

Questions

  1. As i haven't worked on configuring hudson ( just used it as a normal user to initiate build ) what i dont understand from above two links is that... Sonar will run AFTER checkin is done, so how will it stop user to checkin if some test case failed ? or is my understanding incorrect ?? or it will send an email to all developers indicating stats before and after checkin ? or it will send email only if test case fails ??
  2. My use case is little different... before deciding to commit or not i want to check the new coverage % (including the present checkin changes ) and old coverage % ( before checkin changes ) and allow only if the new > old ... how can i do this using hudson+sonar ?? any code/config examples ??
  3. Or my use case is not possible by using Hudson ... and SVN hook is the only option for me ?? if yes any code example on how to do this

Let me know if i need to clarify my question further

Community
  • 1
  • 1
Lav
  • 1,283
  • 5
  • 21
  • 48
  • 2
    Two observations: (1) coverage does not translate directly to code quality, and (2) technology solutions to people problems don't work. – parsifal May 24 '13 at 16:27
  • for (1) changed the question as of now my concern is code coverage % only not code quality as whole – Lav May 24 '13 at 16:32
  • Doing this in a pre-commit hook script is going to slow everyone down *and* cause some very undesirable conditions. While not an exact duplicate, your question is *similar* to [this one](http://stackoverflow.com/questions/16730585/build-on-pre-commit-in-svn). Short version: You really ought to be doing this through a CI system, not a pre-commit event. – alroc May 24 '13 at 17:34

1 Answers1

0

Did some research around , didnt find EXACT solution ( comparing new and old figures ) but found these this link that suggests three solutions Ensure minimal coverage on new Subversion commits

  1. Build Breaker Plugin : compares current test coverage numbers to hard coded values , the hard coded values can be increased every fort night by admin
  2. Paid tool http://www.semanticdesigns.com/Products/TestCoverage/ that tests if there are NEW TEST CASES added for NEW CODE
  3. Also found this http://mojo.codehaus.org/cobertura-maven-plugin/usage.html BUT uses Cobertura as a test coverage analysis tool.
Community
  • 1
  • 1
Lav
  • 1,283
  • 5
  • 21
  • 48