-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix trends back/ahead result selection logic #132
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested with the following command on the environment https://neoload-web.neotys.perfreleng.org/ (default workspace).
The report filter with +3 seems to work, but there is a regression with filter -3 :
With this command : neoload report --type trends --filter results=+4 --template tests\resources\jinja\sample-trends-report.html.j2 --out-file report+2.html d510da5c-ad87-4d69-ad24-256f35296f01
I get these outputs :
SonarCloud Quality Gate failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Kudos, SonarCloud Quality Gate passed! |
* Fix trends back/forward result selection logic * Add logic to remove duplicates from arr_selected * Don't add base ID results again, remove dedup logic * Remove commented out dedup code because Sonar * Add logic to remove duplicates from arr_selected * Remove commented debug code; Sonar * Remove extraneous logging.debug for trends per Guillaume's suggestion * Fixed debug printout of chosen results list
What?
Fix the report trends logic to properly calculate back/ahead values
Why?
Because there was a bug that I found during training.
How?
Update report.py :: compile_results_from_source where range should include +1
Testing
Locally, neoload --debug report --filter="results=44f1a611-bad3-451f-a7d5-9534cf62ee26|+1" --type trends --out-file ~/trends.json
Updated expected_trends json and html files for test_report_trends existing tests.
Additional Notes
I have left many logging.debug calls in the code because they are useful in prod scenarios when a customer uses a particular filter on results such as back or ahead numbers, then is confused by which results it [doesn't] pick up. Running in debug mode leaves just enough indicators to understand what the range logic is doing and why it brings back the results it brings back.