jgebal
commented
1 month ago Hello @alan-rosenthal Thank you for reporting this reaquest. There is a reason why utPLSQL is reporting the count of procedures instead of number of expectations.
A procedure that is annotated as --%test is a test.
One teat may consist of multiple expectations.
Single test should always represent a single specific requirement.
So it is common that for one unit of code (functionality) you will have multiple test procedures.
In order for a test to pass all expectations in that test must pass. In order for a test to fail any one of the expectations in that test must fail.
The reason why we don't display the number of expectations is because one expectation is often not sufficient to represent a meaningful result and should kot be used as a metric of any kind.
What value will you get from having a count of expectations? Maybe you have structured your test procedures differently. Is one test testing one behavior/requirement? How will a count of expectations be helpful?
Is your feature request related to a problem? Please describe. Not a problem
Describe the solution you'd like At the end of a run it shows the number of tests performed, succeeded, and failed. That's fine. But it seems to be counting the number of test procedures that were executed. However, I frequently break the rule of one expectation per procedure. Some of mine have a couple calls to ut.expect() and some work off of lists and have hundreds of calls.
Is it possible to get the number of calls to ut.expect() in the final summary ?
Describe alternatives you've considered I thought of adding a global counter to the ut.expect() calls like this:
ut.expect(x, 'values do not equal').to_equal(y); expect_count := expect_counter + 1;
and then print out the value of expect_counter .
Additional context
Note
Want to discuss