On 11/19/2015 09:30 AM, Lenka Doudova wrote:
> On 11/18/2015 04:51 PM, Martin Babinsky wrote:
>> On 11/18/2015 02:16 PM, Lenka Doudova wrote:
>>> Hi,
>>>
>>> here's a patch that adds a few comments to stageuser tests in order to
>>> allow easier determining of a problem when tests fail.
>>>
>>> Lenka
>>>
>>>
>>
>> Hi Lenka,
>>
>> Firstly a technical detail: Python indexes lists from 0, so the
>> comments in 'options_ok' do not correctly map to the test names anyway.
>>
>> I am also not sure if this patch is worth reviewing and pushing as it
>> IMHO doesn't help in the identification of failed tests at all.
>>
>> This should be solved at more fundamental level.
>>
> Ouch, good point, I didn't realize. Sorry.
> 
> Anyway, the issue is that even if tests are run in verbose mode, you get
> output like this:
> 
> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser27]
> PASSED
> 
> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser28]
> PASSED
> 
> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser29]
> PASSED
> 
> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser210]
> PASSED
> 
> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser211]
> PASSED
> 
> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser212]
> PASSED
> 
> 
> If some test fails, you can't really tell which command was the one
> responsible for the fail. This should be solved by
> https://fedorahosted.org/freeipa/ticket/5449. Until that's done, though,
> the only way to find out which command failed is looking at the code and
> finding which parameters were put into the command, which was not much
> possible without better commenting the test case (as I realized last
> week when David Kupka asked me to help him find the reason for failed
> tests).
> Obviously I can rewrite the tests so there's 27 separate test cases, one
> for each parameter, instead of one method that 'unwraps' into 27 test
> cases, which would entirely eliminate the confusion. So far I don't know
> of a way to put 27 similar test cases in one method which would allow
> easy recognition of the test cases.
> I'll wait with fixing the patch until further discussion.

Hello,
Pytest wants you to be a bit more explicit about how to name the
parameters. (It "hides" dicts by default, because large dicts would make
the output even more confusing than the numbers.)

Please try the attached patch.
Docs are at https://pytest.org/latest/fixture.html#parametrizing-a-fixture

-- 
Petr Viktorin
From 1d36f052102942dcf3dab24bf5ede504ec94ca2f Mon Sep 17 00:00:00 2001
From: Petr Viktorin <pvikt...@redhat.com>
Date: Thu, 19 Nov 2015 10:27:47 +0100
Subject: [PATCH] stageuser tests: Use "str" to display fixture parameter names

---
 ipatests/test_xmlrpc/test_stageuser_plugin.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipatests/test_xmlrpc/test_stageuser_plugin.py b/ipatests/test_xmlrpc/test_stageuser_plugin.py
index 43c59b7c7ec2902064fc363c66e98cc98e8b9e17..21bfe5f7fa9a39e3af1cdb14c48e821901765d39 100644
--- a/ipatests/test_xmlrpc/test_stageuser_plugin.py
+++ b/ipatests/test_xmlrpc/test_stageuser_plugin.py
@@ -329,7 +329,7 @@ def stageduser(request):
     return tracker.make_fixture(request)
 
 
-@pytest.fixture(scope='class', params=options_ok)
+@pytest.fixture(scope='class', params=options_ok, ids=str)
 def stageduser2(request):
     tracker = StageUserTracker(u'suser2', u'staged', u'user', **request.param)
     return tracker.make_fixture_activate(request)
-- 
2.1.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to