That's awesome, thanks Tony and Antranig.

So, if I want to add test coverage to my XYZed GPII module I would just include 
gpii-test and nyc in my dev dependences, add that .nycrc file,  and then mimic 
these lines in my package.json, then my project will get full test coverage? 

Cheers to the Max,

> On Mar 12, 2018, at 12:16 PM, Antranig Basman <> 
> wrote:
> Dear All -
>  This is to report another important milestone in improving our quality 
> infrastructure. This evening another significant branch has been merged, 
> itself representing more than 6 months work by Tony Atkins but building on 
> yet more work implementing similar capabilities for Infusion and captured in 
> other projects in our ecosystem, including gpii-testem. As a result of this, 
> we will now have complete code coverage information pooled between our 
> web-based and node-based unit tests and integration tests, which will greatly 
> improve the efficiency of future code review.
> The code coverage reports can be browsed within the "reports" directory 
> created after a standard (successful) run of the "npm test" task. We should 
> be aiming to reach a baseline quality target of around 90% branch coverage, 
> which across most of our implementation we do already. Once we reach this 
> uniformly, we should consider how further engineering cycles should best be 
> spent.
> Similar capabilities will now be rolled out across our other GPII projects, 
> and also we will probably try to enroll in some form of coverage dashboard so 
> that this can be checked in an automated way as part of our CI.
> Could everyone who has outstanding pull requests against universal please 
> merge them up against current master, and if your work has contributed any 
> further implementation files you will need to explicitly list them against 
> the peculiar patterns found in the .nycrc file listed here (bug has been 
> filed in the upstream "istanbul" project which will hopefully make this 
> unnecessary one day):
> This has been a long road with many awkward turnings due to mismatched 
> assumptions and inflexible implementations in the tower of projects that we 
> depend on, and let us all join in congratulating Tony on the endurance and 
> carefulness needed to land this highly valuable work improving our project 
> infrastructure.
> Cheers,
> Antranig.
> _______________________________________________
> Architecture mailing list

Architecture mailing list

Reply via email to