I would go with reverting the change now. If this is actually an important issue, we will fix it (including the tests), when somebody raises it again.
Back to the topic. If we ignore the tests that were failing because of the moved icon, we are still left with 6 failing tests on python 2.7 (5 on python 2.6.). Two are probably osx specific: 1. FAIL: test_getpath (tests.config.ProductConfigTestCase) 2. FAIL: test_inherit_multiple (tests.config.ProductConfigTestCase) 3. FAIL: test_product_edit (tests.web_ui.ProductModuleTestCase) 4. FAIL: test (tests.wiki.formatter.ProductWikiTestCase) Test Another arbitrary protocol Link 5. ERROR: test_tracadmin_global_plugins (tests.admin.product_admin.ProductAdminDispatchTestCase) Plugin admin panel with TRAC_ADMIN in global env The test failing on 2.7 but not on 2.6 is 6. FAIL: test (tests.wiki.formatter.ProductWikiTestCase) Test product: links - JIRA syntax with unicode digits 1. and 2. fail, because they compare a path that is returned from config.getpath, and has symlinks expanded, with a path with collapsed symlinks. (/var on osx is actually /private/var). I think the right approach here is to fix trac tests to expand symlinks on both paths. 6. The last test tries to match T-²⁰⁴¹ (unicode numbers) with the regexp that simplifies to T-d+ (multiproduct/api.py:646 for exact regexp), which fails in python 2.7. If this is something we want to support, does anyone knows a way to fix this regular expression? Even if it matches, can we get the ticket by unicode representation of its id? I haven't looked into the other 3 failing tests, but I plan to. If someone already has a fix for them or knows what is causing them, please notify me so I don't waste my time. On Thu, May 23, 2013 at 5:17 PM, Olemis Lang <[email protected]> wrote: > On 5/23/13, Gary Martin <[email protected]> wrote: >> On 22/05/13 18:52, Olemis Lang wrote: > [...] >>> >>> IMO , if <span /> position changes , then just update test cases, thus >>> making this decision obvious by inspecting the test suite . Also >>> beware of the fact that this will cause an extra overhead while >>> performing subsequent merges with Trac trunk . >>> >>> Otherwise , just revert to what they were before . >>> >>> What's more important ? A decision has to be made . >>> >> >> What do you mean? I was advocating reverting the change, partly because >> the change seems to me to be in the wrong place anyway. As far as I am >> concerned asking if the link icon should be on the left or the right of >> the link text is bikeshedding but it is something that is possible to do >> clientside if it is particularly desired. >> > > That's exactly my point . > > - If the link should be rendered on the right side then > change the code and update test cases to make it > obvious that this is expected behavior . > - If it's better rendered on the left side then keep it just > like it is now . > > My point is that keeping it the way it is and then changing its > position using JS code > > 1. will require extra JS code > * that might also fail > * or interact with other code in the page > * therefore (at least in theory) requiring JS TCs > * ... and that's a subject ... ;) > 2. will make the system to diverge from expected behavior > documented in test cases . > 3. ... and in the end the goal to do so is to satisfy legacy test cases , > not to assert expected behavior . > > ... that's why I suggested to define expected behavior and be > consistent with that when writing / updating test cases . > > -- > Regards, > > Olemis.
