[openstack-dev] [Horizon] unit test improvements: work with DOM, not raw HTML strings?
Timur Sufiev
tsufiev at mirantis.com
Fri Oct 23 18:53:27 UTC 2015
+1 here. While the exact library choice may still be a topic for the
discussion, unit tests clearly shouldn't hardcode html stings inside, it is
too fragile.
On Fri, 23 Oct 2015 at 02:00, Diana Whitten <hurgleburgler at gmail.com> wrote:
> Richard,
>
> I'm absolutely with you ... I've been bitten by these very tests recently
> when changing a class in a simple template. If anyone wants to override
> these templates in the future, then they are forced to fight this
> 'expected_string' test as well.
>
> I think this is a good idea.
>
> - Diana
>
> On Thu, Oct 22, 2015 at 3:52 PM, Richard Jones <r1chardj0n3s at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I've noticed that we have quite a few places in our unit test suite that
>> test for correctness of behaviour by searching for quite complex HTML
>> fragments in page renders. An example would be
>> openstack_dashboard/dashboards/project/access_and_security/floating_ips/tests.py
>>
>> (there's plenty more - search for "expected_string")
>>
>> The code in question is testing far more than it should. We are testing
>> for the presence of the "disabled" class in an element which has a clear id
>> attribute by constructing the whole element HTML, including label and title
>> text, glyph icon, other classes, the tag type itself, etc. All of those
>> things are quite irrelevant to the test in question, but any change to
>> those will cause the test to break unnecessarily.
>>
>> In these cases a far more robust and targeted unit test would construct a
>> DOM from the rendered HTML and use semantic searches to determine the
>> correctness of behaviour. I would recommend we consider using something
>> like https://django-with-asserts.rtfd.org/ which allow us to write:
>>
>> with self.assertHTML(res, element_id='security_groups__action_create')
>> as elem:
>> self.assertContains(elem.attrib['class'], 'disabled')
>>
>> Who's with me?
>>
>>
>> Richard
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151023/00a8a390/attachment.html>
More information about the OpenStack-dev
mailing list