utPLSQL-SQLDeveloper
utPLSQL-SQLDeveloper copied to clipboard
utPLSQL
Enhancement: Keep Test Code Coverage module list settings between runs
It would be a useful enhancement if the settings for the Code Coverage pop-up (included modules, excluded modules, etc.) were stored and reused when all tests are rerun with code coverage analysis. Thanks.
Maybe also by default include the objects directly referenced by test package?
Maybe I'm using ut/plsql in an unusual way. In addition to any module testing, we're also using it to test the entire Flows for APEX workflow engine as a whole - so running many specially crafted test workflows through the system & checking workflow path, state, process variables, etc. So my module list is 20+ packages...
It would be helpful to understand in which situation the suggested includes are wrong/incomplete. For excludes the default is always null.
- When you run utPLSQL tests for the whole schema there will be no defaults
- When you run it for a test suite via context menu, the included objects are based on dba_dependencies of the selected test suite
- When you run it from the test runner you can select multiple suites and/or tests and the includes are also based on the dependencies of the select tests.
Which variants are you using? And why does the mechanism based on dba_dependencies produces an unsatisfying result?
I'm not convinced that providing a save-restore mechanism in the code coverage report popup window is the right thing to do.
I can imagine use-cases where using the utPLSQL-cli to produce the code coverage could be better. You can write a small script that calls utPLSQL with the right parameters and the include/exclude configuration.
Include/exclude in SQLDev is targeting the cases where you run a subset of your tests and you want to get the coverage only for this subset.
Maybe also by default include the objects directly referenced by test package?
Sorry @PhilippSalvisberg That is irrelevant. I forgot that this functionality is already implemented.
Maybe also by default include the objects directly referenced by test package?
Sorry @PhilippSalvisberg That is irrelevant. I forgot that this functionality is already implemented.
No problem, Jacek.
IMO the feature makes sense when running only a subset of tests in a schema. But I do not see a value when running all tests suites of a schema.
Hi @PhilippSalvisberg - sorry for delay in responding. From discussion above and from playing with settings while testing over last week, I now appreciate that there is much more logic in the included models for code cover than I had first thought. And my code under test is not actually my entire schema. as I have other testable objects there which are not under test.
I think the only time it might be useful to have the option to keep the previous list is when you re-run the test using the buttons at the top of the SQLDeveloper extension panel - you have buttons for 'ReRun All Tests', 'ReRun All Tests in a New Worksheet', 'ReRun All Tests with Debugger', and 'ReRun All Tests with Code Coverage'. If you are rerunning by clicking that button, it feels like (a little ) hassle to have to then re-populate the Code Coverage options window.
But, on the other hand, clicking 'Run All Tests' does add in any new tests that were added the suites since it last ran, and so I guess it is consistent for the automatic determination of dependancies to also run before re-running code coverage.
I think the only time it might be useful to have the option to keep the previous list is when you re-run the test using the buttons at the top of the SQLDeveloper extension panel - you have buttons for 'ReRun All Tests', 'ReRun All Tests in a New Worksheet', 'ReRun All Tests with Debugger', and 'ReRun All Tests with Code Coverage'.
The only option that runs code coverage is "Rerun all tests with code coverage". I understand that it could make sense to keep the previous settings in that case. However, what I do not understand is, when you need to adapt the default. As long as I do not understand that, I'm a bit reluctant to change something.