The Framework for Optimization of ResourCes and Economics is a collection of software tools, models, and datasets acquired and developed under the Integrated Energy Systems (IES) program to enable analysis of technical and economic viability of myriad IES configurations. FORCE is the consolidating interface and data repository for all the IES toolsets ranging from macro technoeconomic analysis to transient process modeling and experimental validation for integrated energy systems.
Is your feature request related to a problem? Please describe.
No. Code coverage tracking merely provides a quantitative approximation of the comprehension of the overall test suite and eases the process of identifying specific areas where additional testing is most valuable.
Describe the solution you'd like
A script should be added that allows the user to check the coverage of FORCE. It should return detailed information including not only the total coverage percentage, but also the specific percentages for individual files and functions. This script should not mask the results of the tests run.
In addition, if the additional overhead time from running tests with coverage is acceptably low, the run_tests call in the testing github action should be replaced with a version that also checks coverage. Presumably this would be the same script as recommended above.
Describe alternatives you've considered
Manually approximating which files, functions, etc. need additional testing is far less precise than checking coverage, and is thus not a good solution. If the overhead time caused by running coverage tracking every time the github action is run is at some point unacceptably high, reverting the github action to its previous form and checking coverage less frequently is an easy change.
For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.
[x] 1. Is it tagged with a type: defect or task?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)
For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.
[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[x] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?
Issue Description
Is your feature request related to a problem? Please describe. No. Code coverage tracking merely provides a quantitative approximation of the comprehension of the overall test suite and eases the process of identifying specific areas where additional testing is most valuable.
Describe the solution you'd like A script should be added that allows the user to check the coverage of FORCE. It should return detailed information including not only the total coverage percentage, but also the specific percentages for individual files and functions. This script should not mask the results of the tests run. In addition, if the additional overhead time from running tests with coverage is acceptably low, the
run_testscall in the testing github action should be replaced with a version that also checks coverage. Presumably this would be the same script as recommended above.Describe alternatives you've considered Manually approximating which files, functions, etc. need additional testing is far less precise than checking coverage, and is thus not a good solution. If the overhead time caused by running coverage tracking every time the github action is run is at some point unacceptably high, reverting the github action to its previous form and checking coverage less frequently is an easy change.
For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.
For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.