+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 <hurgleburg...@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 <r1chardj0...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
