[Toaster] Toaster Weekly Meeting Minutes 02/10/16

[Smith, Elliot]

On 10 February 2016 at 16:50, Jolley, Stephen K <stephen.k.jolley at intel.com>
wrote:

> Elliot - Work with GDC QA team to show them an example of using data
> attributes.
>

I've fixed Selenium test 901 so that it uses data-* attributes on elements,
rather than IDs. I've tried to explain the rationale in the commits on:
elliot/toaster/data_attributes

I prefer data-* attributes to IDs because they add "semantic" markup to
elements: you can tell something about the purpose of the element by
looking at the data-* attributes. If you want to do the same thing with an
ID, you have to cram the purpose of the element into one string.

Because data-* attributes weren't added to templates at the beginning of
Toaster development, we don't really have an agreed naming convention for
them. I used "data-field" to mark the elements in the edit columns
drop-down (as you're choosing a "field" to sort by); data-column might be
better, but we can discuss that if anyone cares.

I wouldn't personally use IDs at all in our HTML, as they are fragile (as
we've seen), plus you can only have one instance of an ID per page and an
element can only have one ID (so IDs can end up being restrictive). But our
JS code relies on IDs (ToasterTable creates the IDs, in fact), which is why
I changed them when I converted to ToasterTable: keeping the old ID would
have meant changing all of our JS.

 (Using classes is also a bad idea, as we might remove or change these if
we redo the CSS for the templates.)

Note that because ToasterTable uses the same class for the column heading
and its cells, the existing tests would fail anyway (regardless of the ID
issue), as they were testing the content of the table cells + headers to
check whether sorting works correctly. I would argue that the tests were
too indiscriminate in this case, as they were only relying on classes; my
solution was to use a selector like 'td[class="started_on"]' instead, to
screen out the th elements.

A few things other came out of this while I was working on fixing the test:

* The Selenium tests are really painful to set up. It would help a lot if
we could put a test db on the wiki or somewhere, so that a user can easily
get a test database with the right content.

* Some of the test code is very fragile, because it uses long xpaths to
find elements. This restricts how much we can modify templates without
breaking tests. It would be much better if we used the shortest possible
CSS selectors instead; if there's no short selector, we should add data-*
attributes to elements of interest so we can use short selectors. (That's
what I've done in my branch.)

* Because not all the test cases are used in a default run (e.g. on Linux),
you have to fiddle with a config file to choose the cases you want. It
would be better if we had a core of tests which run *every* time on *all*
supported systems, and have that as the list of tests for all supported
systems in the config file. If a test won't work that way, we have to fix
the test or Toaster, not switch it off for the platforms where it fails.

* We really need a README in that directory, explaining how to set up and
run the tests. I got this information by reading one of the py files and
looking at the wiki, but it should be in one obvious place.

* We should pull the tests up to the root of the toaster directory, so it's
obvious they exist. They are buried in contrib at the moment, so no one
knows they are there.

* There's a big gap between a change being made to Toaster and a Selenium
test run which shows any bad consequences. As an example, test 901 attempts
to sort by the time field, but sorting by time was disabled at least as far
back as 18th December (see
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8131#c9). I didn't notice
that it broke the Selenium tests and wasn't really aware it was an issue
until last week.

I would like to easily be able to run the Selenium tests during
development, so I know when I'm breaking things; but the tests need to be
up to date with the current state of Toaster, and it should be easy to run
them. Because neither of those are true right now, the gap between the
tests and the actual UI will continue to grow, until we do something to
stop them drifting apart.

Elliot


>
>
>
> Opens:
>
> Mihail:  please kindly ask the developers to be careful not to remove IDs
> when they rewrite pages. (Elliot can expand on this if anybody wants
> details). - Elliot use a data attributes instead of ids.
>
> Belen: Next steps of image customization.  Need to think about package
> groups and how to handle them.  Can we devote Elliot and Dave to fix image
> customization?
>
>
>
> Thanks,
>
>
>
> *Stephen K. Jolley*
>
> *Yocto Project Program Manager*
>
> *INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 *
>
> (   *Work Telephone*:        (503) 712-0534
>
> (    *Cell*:               (208) 244-4460
>
> * *Email*:                            *stephen.k.jolley at intel.com
> <stephen.k.jolley at intel.com>*
>
>
>
> --
> _______________________________________________
> toaster mailing list
> toaster at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>
>


-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20160215/09a14bd0/attachment.html>