A result-set query has a condition that no committed test exercised on both sides, for example a date-range filter. The report names the exact untested condition so you can add data that trips it, or confirm the other side is unreachable.
plpgsql_check is not installed in that database. Tests are still generated and run. Install the extension to get branch and statement numbers.
No, the opposite. A pruned test is one the tool set aside rather than ship, because it would not have been reliable. The branch is then reported honestly instead. Pruned tests are listed in the JSON so you can see exactly what was set aside and why.
Usually a specific precondition is not being met, a required row, an upsert target, a date gate. The report's per-line explanations name the blocker. If it turns out to be a limit of the tool (an E tag), reporting the routine is the most useful thing you can do.
Yes. The test_<routine>.sql files are ordinary pgTAP. Commit them next to your code and run them in CI. When a routine's intended behaviour changes, re-generate (or accept the new recorded output) and commit the update.
unitautogen --schema public --html report.html --out unit_tests is the one to start with, since unit tests are the default. Reach for integration when routines call each other, and seccover or --pii for security review.
unitautogen commands against live databases.