ut_suite_manager.run_cur_schema_suites_static has this nice little parameter called a_force_parse_again. However, it seems to be all or nothing.
When I started to use utPLSQL, I found out that I created one test package for a unit of code (another package) that I wanted to test, and kept adding tests to that test package.
I think utPLSQL could be 'smart' in detecting whether or not I recompiled the package header of my test package since the last time it was parsed using USER_OBJECTS.LAST_DDL_TIME, and only in that case re-parse the package header.
I would still have to manually force reparsing when I add a new test suite, but changes to a suite or even dropping one could be detected this way.
This would cover the most common scenario of having a unit to test, having a test suite for it, and just making changes and additions to the test.
Benefits:
- Speed up running the tests, by only reparsing when needed.
- Speed up development, by automatically reparsing when needed.
ut_suite_manager.run_cur_schema_suites_statichas this nice little parameter calleda_force_parse_again. However, it seems to be all or nothing.When I started to use utPLSQL, I found out that I created one test package for a unit of code (another package) that I wanted to test, and kept adding tests to that test package.
I think utPLSQL could be 'smart' in detecting whether or not I recompiled the package header of my test package since the last time it was parsed using
USER_OBJECTS.LAST_DDL_TIME, and only in that case re-parse the package header.I would still have to manually force reparsing when I add a new test suite, but changes to a suite or even dropping one could be detected this way.
This would cover the most common scenario of having a unit to test, having a test suite for it, and just making changes and additions to the test.
Benefits: