Re: junit 5 suggestions

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
>
>  
>