[Starlingx-discuss] Unit Test Coverage

[Bailey, Henry Albert (Al)]

Those are run by zuul as part of the py27 and py35 jobs for sysinv.
https://opendev.org/starlingx/config/src/branch/master/.zuul.yaml#L11-L12

They are invoked when any code change is submitted againt the sysinv code tree.
Also at merge time (the gate) as well.
Al

From: Jones, Bruce E [mailto:bruce.e.jones at intel.com]
Sent: Wednesday, October 30, 2019 4:39 PM
To: Zvonar, Bill
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Unit Test Coverage

This is very cool.

Are these tests running within Zuul jobs at code check-in time?

     brucej

From: Zvonar, Bill [mailto:Bill.Zvonar at windriver.com]
Sent: Wednesday, October 30, 2019 7:00 AM
To: starlingx-discuss at lists.starlingx.io
Subject: [Starlingx-discuss] Unit Test Coverage

Hi all,

As discussed in recent community calls and release team meetings, we agree that maintaining & increasing unit test coverage is an important step in maintaining & increasing the quality of our code base.

I'd like to highlight some recent work by the config sub-project to help 'lower the bar' for contributors to be able to add new unit tests to this sub-project.  Going forward, they will require new commits to include appropriate unit tests.

This is an excellent model for other sub-projects to follow on their path to having a reasonably low bar of entry for their contributors to add unit tests.  I'll be reaching out to those sub-project teams on this - if anyone is interested in helping, please let me know.

As well, as discussed in the community call recently, Ada is working on building a heat map [5] of where bugs are coming from - this will help us focus our unit test attention in the areas that have the biggest impact to our project.

Thoughts/comments welcome!

Bill...

>From the config sub-project...

We've enhanced and aligned the base unit tests to provide consistency across the different components - specifically for sysinv-api, sysinv-puppet and sysinv-helm.  The base unit tests leverage a common system description and configuration, thus adding an expanded coverage of target system deployment configurations to reduce the likelihood of breaking changes that are specific to deployment scenarios (e.g. ipv4 vs ipv6, aio-sx/dx vs standard configurations, etc).  Existing and new unit tests will benefit from any additional deployment scenarios that are contributed to the base classes.

There are example unit tests available to use as a guide [1-3], and a general guide for how to write unit tests in this area is available at [4].

Going forward, the starlingx/config sub-project will require that new commits to this area be accompanied by appropriate unit tests.

[1] https://opendev.org/starlingx/config/src/branch/master/sysinv/sysinv/sysinv/sysinv/tests/puppet/test_puppet.py
[2] https://opendev.org/starlingx/config/src/branch/master/sysinv/sysinv/sysinv/sysinv/tests/helm/test_helm.py
[3] https://opendev.org/starlingx/config/src/branch/master/sysinv/sysinv/sysinv/sysinv/tests/api/test_host.py
[4] https://opendev.org/starlingx/config/src/branch/master/sysinv/sysinv/sysinv/HACKING.rst
[5] https://docs.google.com/spreadsheets/d/1pZ3kTpkurKuOzTckbkxX9NHkjg2fMH71Ydl_KEVK4eY/edit?usp=sharing


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20191030/c52bcf64/attachment-0001.html>