> 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. _______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
