Absolutely. This is what I'm planning to do first of all. Module-specific
Cobertura reports will help in the future.
—
Yegor Bugayenko
On Mon, Feb 21, 2011 at 9:08 AM, Martin Matula <martin.matula_at_oracle.com>wrote:
> Hi Yegor,
> Agreed there are multiple perspectives one can look at this. I'd say the
> aggregated report gives us the best idea which things are missing coverage -
> i.e. which tests need to be added with the highest priority. If something is
> covered by samples (which we are also running on a regular basis), it is
> less likely to be broken than some other code that is not tested by any
> tests. So, probably makes sense to add coverage for such areas first. Would
> you agree?
> Martin
>
>
> On 20.2.2011 7:31, Yegor Bugayenko wrote:
>
> Cobertura report looks great, but I have one concern about it. You're
> joining together all cobertura reports from all sub-modules, and it makes an
> impression, for example, that tests in samples.* packages add coverage to
> jersey.core.*. I don't think that this approach is valid/correct. Of course,
> it's kind of a philosophical question, but I would prefer to have isolated
> coverage reports, one per each sub-module.
>
> But don't worry, I can build such an isolated report myself in
> jersey-server, and continue with unit tests (as soon as you
> approve JERSEY-652).
>
> Thanks!
>
> —
> Yegor Bugayenko
>
>
> On Sun, Feb 20, 2011 at 12:52 AM, Pavel Bucek <pavel.bucek_at_oracle.com>wrote:
>
>> On 2/17/11 4:27 PM, Yegor Bugayenko wrote:
>>
>> Looks like I can't reopen the issue... I created a new one: JERSEY-652.
>>
>> Maybe I just didn't find how to reopen. Sorry for this.
>>
>> no problem
>>
>>
>> Btw, we don't use <dependencyManagement> now, but we should, I think.
>> Since it's a multi-module project. I added a simple section to parent
>> pom.xml, just to show how it should work. If you're comfortable with this
>> approach, I can update other sub-modules.
>>
>> With <dependencyManagement> we won't need to specify versions of
>> components in every sub-module. Instead, we will just tell that this
>> dependency is required. All other details will be grabbed from
>> jersey-project/pom.xml.
>>
>> yeah, you are right. I'll look into it next week, I should be able to
>> have everything by the end of Tue or Wed. Thanks for suggestion!
>>
>> btw, current test+samples code coverage can be found at
>> http://anise.cz/~paja/jersey/report/ so you can take it as an inspiration
>> to new tests.
>>
>> Pavel
>>
>>
>> —
>> Yegor Bugayenko
>>
>>
>> On Thu, Feb 17, 2011 at 3:54 PM, Pavel Bucek <pavel.bucek_at_oracle.com>wrote:
>>
>>> Looks fine, I already committed it into the trunk.
>>>
>>> I took this opportunity to update junit for whole project (to 4.8.2) but
>>> now I'm facing some issues with that.. anyway, not your problem. I should
>>> have this solved by end of today.
>>>
>>> So, I'll close that issue and mark it as fixed. You don't need to create
>>> new one for new tests, just add another attachment to this one and
>>> reopen/comment.
>>>
>>> Thanks,
>>> Pavel
>>>
>>>
>>> On 02/17/2011 02:20 PM, Yegor Bugayenko wrote:
>>>
>>> I created a simple ticket JERSEY-651, where some initial changes are
>>> introduced. Would be nice to get some comments/corrections before I
>>> continue. I decided to start with jersey-server module, since it's one of
>>> the most important ones and the situation there is rather sad: 307 source
>>> files and 3 unit tests. I'd be glad to improve it.
>>>
>>> —
>>> Yegor Bugayenko
>>>
>>>
>>>
>>> On Thu, Feb 17, 2011 at 1:24 PM, Pavel Bucek <pavel.bucek_at_oracle.com>wrote:
>>>
>>>> Hello,
>>>>
>>>> please see inline.
>>>>
>>>>
>>>> On 02/17/2011 12:29 PM, Yegor Bugayenko wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>> Maybe you can use maven-cobertura-plugin (
>>>> http://mojo.codehaus.org/cobertura-maven-plugin/)? Using this plugin
>>>> you won't need any script. You just add a few lines to the parent pom.xml,
>>>> and that's it. Or you're already proceeding this way?
>>>>
>>>> yep, it is done that way, you may check poms if you want. It wasn't
>>>> that simple with jersey, but I managed to get usable results from what we
>>>> have now; the script I posted previously is used mainly for coverage info
>>>> collection and report generation. If you have some experience and/or want to
>>>> suggest some improvement, feel free to do so.
>>>>
>>>>
>>>>
>>>> I'd be glad to contribute with unit tests. Shall I submit them as
>>>> patches in JIRA or I can get a write-access to SVN? Any approach is fine for
>>>> me.
>>>>
>>>>
>>>> JIRA issues with patches is good way how to start, you might get write
>>>> access to svn after few added tests (we just need to have chance to review
>>>> your work, check whether tests don't break anything.. simply - gain mutual
>>>> trust).
>>>>
>>>> Regards,
>>>> Pavel
>>>>
>>>>
>>>>
>>>>
>>>> —
>>>> Yegor Bugayenko, PMP®
>>>> www.tpc2.com <http://www.TechnoParkCorp.com> (Team as a Service™)
>>>> tel. 650.681.4161, skype: egor256
>>>>
>>>>
>>>>
>>>> On Thu, Feb 17, 2011 at 12:22 PM, Pavel Bucek <pavel.bucek_at_oracle.com>wrote:
>>>>
>>>>> Hi Egor,
>>>>>
>>>>> well, there is definitely room for improvement, I recently modified
>>>>> jersey poms to include cobertura do to code coverage and we can see that not
>>>>> everything is covered as we would like.
>>>>>
>>>>> But! For example, jersey-core does not have much unit tests in itself
>>>>> included, but you can find jersey-core related tests in jersey-tests module.
>>>>>
>>>>> If you want to see test coverage for jersey, you can test it by
>>>>> yourself or wait for a week or so, I plan to publish them on project page or
>>>>> somewhere visible.
>>>>>
>>>>> "script" you can use to generate test coverage report with cobertura
>>>>> (don't execute it unless you know what you are doing):
>>>>>
>>>>>
>>>>>
>>>>> svn co svn cp https://svn.java.net/svn/jersey~svn/trunk/jersey
>>>>> cd jersey
>>>>>
>>>>> rm -rf ./osgi # we don't care about this, its just duplicate of
>>>>> jersey-tests
>>>>>
>>>>> mvn clean install -Dmaven.test.skip=true -Dcobertura
>>>>> find . -d -name src | sed 's/src/pom.xml/' | while read X ; do mvn
>>>>> clean cobertura:cobertura -Dcobertura -DforkMode=never
>>>>> -Dnet.sourceforge.cobertura.datafile=./cobertura.ser -f "$X" ; done
>>>>>
>>>>> rm ../cobertura*
>>>>> rm ./cobertura_final.ser
>>>>>
>>>>> mkdir ../sources
>>>>> find . | grep src/main/java$ | while read X ; do cp -r "$X"/*
>>>>> ../sources/ ; done
>>>>>
>>>>> I=1; find . | grep cobertura.ser$ | while read X ; do cp "$X"
>>>>> ../cobertura$I.ser ; I=$(($I+1)) ; done;
>>>>> cobertura-merge.sh --datafile ./cobertura_final.ser ../cobertura*
>>>>>
>>>>> rm -rf ../report
>>>>>
>>>>> cobertura-report.sh --datafile ./cobertura_final.ser --destination
>>>>> ../report --format html ../sources/
>>>>>
>>>>>
>>>>> Best think you should do now is:
>>>>> - create new tests which will improve test coverage
>>>>> - create new issue on issue tracker, add your diff as a patch to it
>>>>>
>>>>> Others might add something; nevertheless, we are looking forward to
>>>>> hearing for you again and it would be really goof if you'll be able to
>>>>> contribute!
>>>>>
>>>>> Thanks in advance,
>>>>> Pavel
>>>>>
>>>>>
>>>>> On 02/17/2011 11:52 AM, egor_at_technoparkcorp.com wrote:
>>>>>
>>>>>> I'm a using Jersey for the last year in a few projects of my company.
>>>>>> The framework is great, but according to what we see in its source
>>>>>> code
>>>>>> repository there is a lack of unit tests for key modules, like
>>>>>> jersey-api, jersey-core, etc.
>>>>>>
>>>>>> I'm willing to contribute to the project and create missing unit
>>>>>> tests,
>>>>>> which will increase entire project coverage. I already filled my SCA.
>>>>>> Please help me to do this. Thanks!
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>