Glorious merge of code coverage and testem configuration

Justin Obara obara.justin at
Wed Jan 17 19:13:24 UTC 2018

Hi Tony,

I was thinking about this a bit more and maybe it doesn’t make sense. The
test would only be for cases where the fluid object is missing, which
really shouldn’t happen for these files. If we did want to test it, I
suppose we’d have to have a separate test file where the fluid object isn’t
included. I’m leaning towards just ignoring those branches, but am open to
some other thoughts and suggestions.

Also, we do have a manual test for running multiple versions of Infusion.


On January 17, 2018 at 1:03:02 PM, Tony Atkins (tony at

Hi, Justin.

Could you elaborate on "add a test util for this that we plug into every



On 17 January 2018 at 17:31, Justin Obara <obara.justin at> wrote:

> Thanks so much Tony et al for adding this. It’s really helpful to be able
> to view the reports and see what are tests are actually covering.
> I’ve started using this for my most recent work and noticed that I was
> getting a lower branch coverage than expected. I spoke with Tony about this
> in the channel
> <> today.
> It seems this is because the
> var fluid_3_0_0 = fluid_3_0_0 || {};
> at the top of most of our files is treated as a branch because of the
> conditional for the default value.
> I think we should either add a test util for this that we plug into every
> test, or just instruct the code coverage to ignore it. If we go the ignore
> route, we could follow this method
> var fluid_3_0_0 = fluid_3_0_0 || /* istanbul ignore next: the presence of
> the fluid object can be inferred by the test running */ {};
> Thanks
> Justin
> On January 16, 2018 at 11:19:48 AM, Antranig Basman (
> antranig.basman at wrote:
> I'm happy to report the merge of a major and significantly useful pull
> request
> from Tony Atkins which
> adds long-awaited and much needed
> code coverage and testem drivers to Infusion. As well as providing
> amalgamated coverage reports derived from
> both our browser and node-based tests, it provides an all-in-one testem
> driver that will execute all such
> tests in all available browsers and node.js.
> This will be invaluable to us in CI, and will shortly be a part of the
> automated builds run on each pull
> request. It will be important in future reviews to ensure that new work
> has good coverage, coverage of
> existing work does not degrade, and that we should work steadily to bring
> areas of old implementation up to
> reasonable standards of coverage (e.g. branch coverage of about 90%
> represents a reasonable baseline. For
> example we have interestingly poor coverage of jquery.keyboard-a11y.js via
> automated tests.
> The coverage reports are generated automatically by running "npm test" and
> can be accessed in the newly
> generated "reports" directory. Machine-readable summaries of the coverage
> are produced in "coverage".
> Let us all join in congratulating ADTKINS on almost a year of steering
> this pull request to a successful
> conclusion. Similar work is in progress for GPII projects but looks like
> it will be blocked by moving those
> projects over to a "monorepo" structure.
> Cheers,
> Antranig
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list