Re: junit 5 suggestions

Hi Again,

   Kevin sorry I keep sending mail I just didn't think that an api
discussion was a 'issue' but more a discussion.

I will create a issue.
Also I wasn't suggesting having junit depend on EclEmma, as I think EclEmma
depends on junit.
But rather, taking some code from EclEmma and putting it in the JUnit
project.

Cheers,
Scott


On Mon, Mar 10, 2014 at 5:37 PM, Kevin Cooney <[email protected]> wrote:

>
>
> Scott, as I've said before, I think it's easier to track feature requests
> on github. It's hard for me to track the six threads on the mailing list
> that are related to this.
>
> We've had problems in the past having JUnit depend on other third-party
> libraries, so I doubt that we would have a future version of JUnit depend
> on EclEmma. Instead, I would personally prefer that we ensure that you have
> the necessary extension points to solve your problems.
>
> Let's discuss further on github.
>
> Thanks,
>
> -- Kevin
>
>
> On Mon, Mar 10, 2014 at 1:41 PM, Scott Morgan <[email protected]> wrote:
>
>>
>>
>> Hi Again,
>>
>>    Ok this is much easier to read;
>>
>> https://github.com/adligo/junit/blob/master/diagrams/JUnit5RunApiSuggestion.jpg
>>
>> The basic idea is;
>> Lets compare Apples to Apples (or in other words line up JUnit Test
>> Classes, Code Coverage and AssertionCounts)
>>
>> It would involve adding parts of something like EclEmma to junit so that
>> the coverage and assertions would all be tracked in the same models.
>> Then the other statistics could be calculated and included with the JUnit
>> test results like;
>> percentage of instructions covered
>> percentage of lines covered
>> percentage of assertions to instructions
>> average instructions per line (this should be smallish (ie 1.1) for well
>> refactored code)
>>
>> It would probably take us several years to implement, and break backward
>> compatibility.
>> So it makes sense for others to review it for some time and agree about
>> the api, before any real coding starts.
>>
>> I think full blown statistics of junit tests would provide teams with
>> better insight to their junit testing effort.   I also do NOT think new
>> project prototypes should be 100% tested until some end to end api level
>> functional testing has occurred.
>>    After all junit 4.11 has about 700 junit tests of itself and I
>> couldn't reports of new junit tests to work with out altering the junit 4
>> api slightly (and junit did use ant at one point to build itself).
>>
>> If enough folks agree this is a good idea I would recommend the following
>> migration path;
>> 1) Implement all the models, and tests of them
>> 2) alter the JUnitCore class
>>
>> Cheers,
>> Scott
>>
>>
>  
>