[Pulp-dev] Pulp 3 Unit Test Plan Proposal

Jeremy Audet jaudet at redhat.com
Mon Mar 26 20:01:41 UTC 2018

> I'm also generally -1 against trying to pick a number (100%, 80%, 60%) up-front.  We should unit test what makes sense to unit test, push that number as high as reasonable, and otherwise focus on pulp-smash, which I think has historically been more useful.

QE is flattered by the focus on Pulp Smash. We're happy that the smoke
tests are being executed as a pull request check.

However, it's important to remember that unit tests are far faster
than integration tests, typically by several orders of magnitude. In
addition, Pulp Smash's smoke tests are intentionally limited. They're
designed to execute quickly and to detect catastrophic regressions.
They're not intended to be comprehensive. In fact, some of the
already-written test cases may be stripped of their "smoke test"
status for the sake of speed. Psychology is important here: it's bad
if a developer locally fires off smoke tests, gets bored, and opens up
a new web browser tab.

Please keep this limitation in mind when deciding on policies
regarding smoke tests.

More information about the Pulp-dev mailing list