+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.<br><div class="gmail_quote"><div dir="ltr">On Fri, 23 Oct 2015 at 02:00, Diana Whitten <<a href="mailto:hurgleburgler@gmail.com">hurgleburgler@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Richard,<br><br></div><div>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.<br><br></div>I think this is a good idea.<br><br></div></div><div dir="ltr">- Diana<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 3:52 PM, Richard Jones <span dir="ltr"><<a href="mailto:r1chardj0n3s@gmail.com" target="_blank">r1chardj0n3s@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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</div><div><br></div><div>(there's plenty more - search for "expected_string")</div><div><br></div><div>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.</div><div><br></div><div>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 <a href="https://django-with-asserts.rtfd.org/" target="_blank">https://django-with-asserts.rtfd.org/</a> which allow us to write:</div><div><br></div><div> with self.assertHTML(res, element_id='security_groups__action_create') as elem:</div><div>    self.assertContains(elem.attrib['class'], 'disabled')</div><div><br></div><div>Who's with me?</div><span><font color="#888888"><div><br></div><div><br></div><div>    Richard</div><div><br></div></font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>