/irc-logs / w3c / #testing / 2015-04-11 / end

Options:

Previous day, Next day

  1. # Session Start: Sat Apr 11 00:00:00 2015
  2. # Session Ident: #testing
  3. # [01:54] * Joins: bhill2_ (~bhill2@public.cloak)
  4. # [01:54] * Quits: bhill2 (~bhill2@public.cloak) (Client closed connection)
  5. # [02:26] * Quits: bhill2_ (~bhill2@public.cloak) (Client closed connection)
  6. # [02:26] * Joins: bhill2 (~bhill2@public.cloak)
  7. # [02:35] * Joins: bhill2_ (~bhill2@public.cloak)
  8. # [02:35] * Quits: bhill2 (~bhill2@public.cloak) (Client closed connection)
  9. # [02:45] * heycam|away is now known as heycam
  10. # [02:50] * Joins: playjax (~chatzilla@public.cloak)
  11. # [03:05] * heycam is now known as heycam|away
  12. # [03:05] * Quits: playjax (~chatzilla@public.cloak) (Client closed connection)
  13. # [04:09] * Quits: ArtB (~ArtB@public.cloak) ("Leaving.")
  14. # [04:49] * Joins: ArtB (~ArtB@public.cloak)
  15. # [04:49] * Quits: ArtB (~ArtB@public.cloak) (ArtB)
  16. # [05:10] <hgl> do browser engines use wpt? I see the gecko repo contains it. but not blink or webkit.
  17. # [05:19] * Joins: hgl- (~hgl@public.cloak)
  18. # [05:19] * Quits: hgl (~hgl@public.cloak) (Client closed connection)
  19. # [05:19] * hgl- is now known as hgl
  20. # [05:25] <MikeSmit1> hgl: webkit project has been working on integrating it, and we've talked to the blink/chrome CI team about integrating it too
  21. # [05:26] <MikeSmit1> I think in the case of the blink team, they want to make sure how much of a time cost it's going to add to their CI cycles
  22. # [05:28] <hgl> that's good to hear. if everyone uses wpt, that would be wonderful
  23. # [05:29] <hgl> I'm also convincing ftlab's polyfill services to use wpt, but currently its python based nature seems to make it harder to be consumed by a nodejs project
  24. # [05:49] <MikeSmit1> what benefits does ftlabs polyfill services get from using wpt?
  25. # [05:55] * Joins: playjax (~chatzilla@public.cloak)
  26. # [06:33] <hgl> MikeSmit1, for spec compliance I guess? You don't think it's a good idea for polyfill libs to use wpt?
  27. # [06:34] <MikeSmit1> hgl: ah I see what you're saying
  28. # [06:34] <hgl> MikeSmit1, they should use wpt for the unit tests if I'm not wrong. currently, they just write them themselves, and it's not as rigorous as wpt.
  29. # [06:35] <MikeSmit1> yeah it makes sense to test polyfills with wpt tests
  30. # [06:35] <hgl> Is there any docs that explain how wpt can be integrated into a nodejs project?
  31. # [06:40] <hgl> if wpt is more approachable to the general web community. I believe many people will add unit tests to it, and browser engines can directly benefit from them.
  32. # [06:43] <MikeSmit1> hgl: there are no docs on how to integrate wpt into a nodejs project
  33. # [06:44] <MikeSmit1> hgl: I don't know kind of unit tests you have in mind
  34. # [06:45] <MikeSmit1> if we were to add unit tests for the wptserve part of wpt, then the unit tests would be in python because the code is in python
  35. # [06:46] <MikeSmit1> and anyway wptserve itself is essentially a Web server
  36. # [06:46] <hgl> classList (multiple args for add, remove), dom4 methods (before, after, etc)
  37. # [06:46] <MikeSmit1> how are those unit tests?
  38. # [06:46] <hgl> many polyfill libs implements them, and if they use wpt, I believe they will add the unit tests to it, which is currently missing if I'm not wrong?
  39. # [06:47] <MikeSmit1> we have tests already for classList and for dom methods
  40. # [06:48] <hgl> ah, really? that's good to hear. last time checked they are still missing.
  41. # [06:48] <hgl> and ms2ger said that's because no browsers currently implement them
  42. # [06:48] <MikeSmit1> I guess there may be some gaps there, I don't know
  43. # [06:49] <MikeSmit1> but those tests have nothing to do with wpt being written in python
  44. # [06:49] <MikeSmit1> the tests for those are completely written in JavaScript and HTML
  45. # [06:50] <MikeSmit1> they can be run in any Web browser
  46. # [06:50] <MikeSmit1> from any Web server
  47. # [06:51] <MikeSmit1> we just provide the python stuff as a self-hosting Web server to run the tests in
  48. # [06:51] <hgl> my point is, if the web community can leverage wpt, they will contribute unit tests. but it's python based nature makes it less appealing to be adapted by them.
  49. # [06:52] <MikeSmit1> and what I'm telling is the fact that wptserve is in python is irrelevant in this case
  50. # [06:52] <MikeSmit1> they never need to touch any python code
  51. # [06:52] <MikeSmit1> any more than they need to touch nginx code, or Apache code, to write their Web applications and test them
  52. # [06:53] <hgl> they need to inject the polyfill code before running the tests
  53. # [06:53] <MikeSmit1> inject where?
  54. # [06:53] <MikeSmit1> inject code into the Web server?
  55. # [06:54] <hgl> inject into the html page running the unit tests.
  56. # [06:55] <MikeSmit1> well that's what the polyfill itself does. that's what the polyfill *is*
  57. # [06:55] <MikeSmit1> and it's all done in JS, right?
  58. # [06:55] <MikeSmit1> on the client side
  59. # [06:55] <MikeSmit1> in the browser
  60. # [06:55] <MikeSmit1> not in the server-side runtime
  61. # [06:55] <MikeSmit1> so it doesn't matter what the server-side runtime is
  62. # [06:56] <hgl> if I'm not wrong, the server needs to provide a way to let people inject polyfill code before the test code. so if a failing older browser now pass all tests because the polyfill code, we can know the polyfill code is working correctly
  63. # [06:59] <hgl> and i'm not sure wpt currently provides such a hook to let people inject code. but maybe I'm wrong.
  64. # [07:04] <MikeSmit1> hgl: wptserve does provide a way to inject code but I really don't understand why you're saying it would be needed here
  65. # [07:04] <MikeSmit1> it's JS code, right?
  66. # [07:04] <MikeSmit1> the test case can load the code on the client side before it runs the test, right?
  67. # [07:05] <MikeSmit1> the test case can make the browser load the polyfill JS code on the client side before it runs the test cases
  68. # [07:06] <hgl> we are talking about wpt's test case here. wpt is willing to accept the extra code that loads the polyfill code? or you are saying people should fork wpt?
  69. # [07:07] * Quits: vitt (~vitt@public.cloak) (Ping timeout: 180 seconds)
  70. # [07:08] <hgl> i was thinking people should use wpt as a submodule and use it directly.
  71. # [07:08] <MikeSmit1> hgl: I guess we could just add some option in the testharness.js code to allow a test to self-identify as a "polyfill" test
  72. # [07:09] <MikeSmit1> all in the JS code
  73. # [07:09] <MikeSmit1> I don't see that we'd have any need to ever touch the python code for this
  74. # [07:10] <hgl> that's a pretty good idea. I was thinking the server could allow people to specify a js file, and it will insert it as <script> before the test code.
  75. # [07:10] <MikeSmit1> sure it could be done that way I guess but I don't think it would need to be
  76. # [07:11] <MikeSmit1> and even if we implemented it that way, nobody writing tests would need to ever touch the related python code
  77. # [07:12] <hgl> yes. after talking to you i think the python based nature doesn't matter.
  78. # [07:12] <MikeSmit1> we'd just, say, expose the mechanism as a GET query paremeter in the URL for the test
  79. # [07:12] <MikeSmit1> hgl: the best place to bring this up for further discussion is probably the public-test-infra@w3.org list
  80. # [07:13] <hgl> sure. will do. thanks.
  81. # [07:13] <MikeSmit1> cool
  82. # [07:53] * Quits: bhill2_ (~bhill2@public.cloak) (Client closed connection)
  83. # [09:13] * Quits: playjax (~chatzilla@public.cloak) ("ChatZilla 0.9.91.1 [Firefox 32.0.1/20140911151253]")
  84. # [09:27] * Joins: darobin (rberjon@public.cloak)
  85. # [09:33] * Quits: darobin (rberjon@public.cloak) ("Leaving...")
  86. # [10:02] * Joins: Ms2ger (~Ms2ger@public.cloak)
  87. # [11:53] <jgraham> hgl: Pretty sure we can fix something up here
  88. # [11:54] <jgraham> (as an aside I feel the argument that something isn't "web" enough unless it's using node is pretty sad)
  89. # [12:00] * Joins: playjax (~chatzilla@public.cloak)
  90. # [12:09] * Joins: tripu (antonio@public.cloak)
  91. # [12:15] <hgl> jgraham, I guess mainly due to the difficulty of running it in a public ci like travis, which currently doesn't support running multiple languages in a single repo.
  92. # [12:17] <hgl> but i guess the unit testing can be its own repo. i admit my "web should be using node" mind set is something i need to change. :)
  93. # [12:19] <Ms2ger> hgl, hm? Servo has used wptrunner as well as test harnesses implemented in Rust on Travis
  94. # [12:20] <hgl> Ms2ger, i need to check it out, thanks for the heads up
  95. # [12:28] * Quits: playjax (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  96. # [12:39] <hgl> from the travis config file in the main servo repo, they only run mach test-tidy on travis, which don't even run wpt if I'm not wrong. I guess they run wpt with a different repo?
  97. # [12:41] <Ms2ger> No, this was a long time ago :)
  98. # [12:41] <Ms2ger> We moved off of Travis
  99. # [12:43] <hgl> ah, but thanks anyway. I now think I can just use python to run all tests with wptrunner, no need to rely on node.
  100. # [12:46] <hgl> another reason for "web should be using node" mindset is that most web developers aren't very familiar with python, like myself, we just want everything web related to be in js. :) but now I have a very good reason to dig into python.
  101. # [13:45] * Joins: ArtB (~ArtB@public.cloak)
  102. # [16:19] * Joins: playjax (~chatzilla@public.cloak)
  103. # [17:46] * Quits: playjax (~chatzilla@public.cloak) (Client closed connection)
  104. # [18:22] * Joins: bhill2 (~bhill2@public.cloak)
  105. # [18:27] * Quits: bhill2 (~bhill2@public.cloak) (Client closed connection)
  106. # [18:33] * Joins: playjax (~chatzilla@public.cloak)
  107. # [19:05] * Quits: tripu (antonio@public.cloak) ("Leaving")
  108. # [19:17] * Quits: playjax (~chatzilla@public.cloak) (Client closed connection)
  109. # [19:20] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  110. # [19:28] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Ping timeout: 180 seconds)
  111. # [19:31] * Quits: ArtB (~ArtB@public.cloak) ("Leaving.")
  112. # [21:21] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  113. # [21:28] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Ping timeout: 180 seconds)
  114. # [21:40] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  115. # [23:17] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  116. # [23:18] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  117. # [23:25] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Ping timeout: 180 seconds)
  118. # [23:30] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  119. # Session Close: Sun Apr 12 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn