-
Notifications
You must be signed in to change notification settings - Fork 165
[1LP][RFR] Add customer scenario marker/filter, move tier and requirement markers #9225
Conversation
conf/polarion_tools.yaml
Outdated
@@ -66,6 +66,7 @@ docstrings: | |||
# default for manual mark is 'notautomated' | |||
# @pytest.mark.manual('manualonly') to set 'manualonly' | |||
linkedWorkItems: "@pytest.mark.requirements" | |||
customerscenario: "@pytest.mark.requirements.customer_stories" |
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.
Not possible to set meta with these markers, evaluating if its worth supporting this. Could also be set via BZ marker if by resolving items attached to the BZ.
85b6dc4
to
8ef68e5
Compare
it's really great PR !. I love it |
8ef68e5
to
54d4599
Compare
I've abstracted the meta-filter itself into pytest-polarion-collect: |
33b2fd0
to
fdd2fb6
Compare
fdd2fb6
to
40a193b
Compare
cfme/test_requirements.py
Outdated
assignee_id='ndhandre', | ||
) | ||
|
||
day2 = pytest.mark.requirement( |
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 thought day 2 scenarios are different from customer scenarios . If yes then we need to change the description
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.
So, they are not mutually exclusive.
customerscenario
meta is for polarion boolean flag, and may apply to test cases that are not necessarily linked to customer stories/day2 initiatives. It is the lowest level marker (meta) that indicates a test case is linked to a customer use case. It could be applied automatically by the BZ meta marker if the marked BZ is linked to a customer support case.
This requirement marker is used to group/link test cases that are a direct result of the customer stories initiative, or are related specifically to day2 operations type testing.
I chose to change this requirement marker to day2
to more clearly separate the names, and because its shorter. I left the first argument, the requirement title, the same, because that keeps the existing polarion requirement linked. I'll leave it to the requirement owner, @digitronik, if he also wants to change the requirement title.
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.
@sshveta would you like to see more documentation in the marker module for customerscenario?
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.
@mshriver : yes please , day 2 is not very evident by name that it is for customer stories .
@digitronik : What do you think ?
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.
@mshriver as per our discussion is it possible to put same name means customer_stories
.
one will be requirement
and other will be simple meta
marker.
-
@pytest.mark.customerscenario
: setscustomerscenario
flag (polarion), indicates a test originating from acustomer Bugzilla
related to specific FA. -
@requirement.customer_stories
: Customer operations, actual integration tests means sharing multiple FA. It not bound to onlycustomer bugzilla
butcustomer stories
collected from
- Bugzilla
- Mail threads
- Support people threads
- FA owner thoughts (how specific FA used in combination with other FAs)
@sshveta we will add customerscenario
meta over customer stories
tests. but customer_stories
requirement marker will not applicable for every customer Bugzilla automation test.
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.
Changed it back
9b96714
to
4bc1fb9
Compare
@@ -246,7 +246,7 @@ def get_miq_server_id(self): | |||
|
|||
def get_pids_memory(self): | |||
result = self.ssh_client.run_command( | |||
'smem -c \'pid rss pss uss vss swap name command\' | sed 1d') | |||
"/usr/bin/python2.7 /usr/bin/smem -c 'pid rss pss uss vss swap name command' | sed 1d") |
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.
This is otherwise unrelated, and I can move the commit to a different branch if preferred. Found this running cfme-performance test repository, smem is not python 3 compatible, this is being run on the appliance, not locally.
view = _navigation(param, appliance) | ||
assert view.search.is_advanced_search_possible, (f"Advanced search not displayed " |
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.
@psimovec I found when updating the polarion tooling packages, that this pattern of decorating to inject the tests was not including metadata.
Even modifying the inject_tests
methods to explicitly include the __doc__
for the methodized test function, the meta parsing tools were not processing it correctly. There will need to be updates to these tools to support a test structure like this.
In the mean time I collapsed these two tests, as a separate test just to assert that the advanced search button is there is redundant to a test that is actually asserting that advanced search is opened when clicked.
I left methodize/inject_tests in place, but removed the decorators and put the boilerplate in place so that meta would be applied.
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.
LGTM
@@ -19,6 +19,7 @@ | |||
|
|||
pytestmark = [ | |||
test_requirements.v2v, | |||
pytest.mark.customer_scenario, |
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.
👍
SearchParam('ansible_tower_job_templates', 'All', 'ansible_tower_explorer_job_templates', | ||
'Job Template (Ansible Tower) : Name', | ||
('sidebar.job_templates', 'All Ansible Tower Job Templates')), | ||
|
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.
This empty line can be removed
Add customer-scenario filter and marker register the markers default customerscenario update pytest-polarion-collect and other polarion packages Remove test injection from test_advanced_search, for meta The polarion meta was not correctly parsed, and with updates to pytest-polarion-collect and polarion_docstrings, the unmerged docstrings are causing exceptions and failures during collection. Go to boilerplate for this test module, until the meta processing is resolved. Update smem to run with python2 explicitly
4bc1fb9
to
07dc41c
Compare
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.
One minor comment about an old TODO
, nice PR! 👍
keep.append(item) | ||
|
||
items[:] = keep | ||
# TODO(rpfannsc) add a reason after pytest #1372 is fixed |
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.
Can this TODO be removed? I see that the issue referenced is resolved pytest-dev/pytest#1372
Changes to test_advanced_search are to repair its metadata collection and to prevent exceptions from pytest-polarion-collect during collection.