On Thu, Jan 13, 2011 at 9:01 AM, Schulze, Stefan (EXTERN: CKC) < [email protected]> wrote:
> Jeff Jensen wrote: > > Perhaps a different CI job structuring? This has worked well > > for me at many > > customers: Have a CI job for only compile and unit tests - > > this maintains the most important very fast turnaround. Have > > a second CI job for (longer > > running) IT tests that only runs with success of the first. > > Have a third job for coverage, standalone or as part of a > > full system site gen or using Sonar or other... > > Sounds nice, but this doesn't meet my requirement, that the tests with > coverage-checks (and only one time, not twice) should run, when the > developers do "mvn test". There is no acceptable solution to this "requirement". Many of us "would like" to not run them twice, and in actuality running them twice is not a problem for things like site gen. However, my thinking is to separate the two runs anyway, as coverage is not needed with each local build. Run "mvn test" until the tests all pass and the developer thinks there is reasonable coverage, then run "mvn cobertura:cobertura" and view the results. I think running coverage all the time is not necessary until ready to inspect it, particularly when I know I have a lots of work to do on the story/feature; coverage is irrelevant at the start with full TDD (tests exist, no code exists, compile errors exist) and until I am ready to see the needed additional cases. That's for me; YMMV! :-) > We have a quite small difference between > coverage-threshold and actual coverage, so I think it's important, that > the developers check their coverage during development, so they can > react early. > What IDE is in use? If Eclipse, consider using eCobertura, a Cobertura Eclipse plugin, to run the tests in Eclipse and visually see the coverage as needed. > Another problem to your solution is, that Actually, it is a problem with your environment/practices, not with the solution! ;-) > we unfortunately don't use a > regular CI-server but a bunch of shellscripts and cron-jobs. So it's not > as trivial as with Hudson (Jenkins?) to use this kind of build-pipeline. > Looks like it is time to invest a couple of days and set it up! Your work life will be easier and maintenance cheaper.
