Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Le 19/08/10 12:29, Sidnei da Silva a écrit : On Wed, Aug 18, 2010 at 2:14 PM, Dorneles Treméadorne...@tremea.com wrote: from his recent work on Canonical, I'm sure Sidnei has some great insights to share here, don't you Sidnei? :-) We've been using YUI, so Y.Test as the test framework. We run tests manually in the browser when debugging, but for automated unit tests we use JsTestDriver from Google to drive the tests, save output to XML then report failure/success back to Python's unittest by parsing the XML. There's a little bridging needed to get the tests registered with JsTestDriver, but not terrible. JsTestDriver ships with a version of jQuery, but might not be the same you guys are using. There's another test runner coming up, YETI, but it might be YUI-specific. Is JsTestDriver qUnit compatible ? For functional tests, we're using Selenium2, which is alpha-something IIRC. It's *way* better than Selenium1. We're using the webdriver API (remote webdriver and Firefox, on local machine), and it's Good Do you test multiple browsers or only Firefox ? Enough, just forget about recording tests in the browser and saving them - at least for now. One way or another, writing tests manually isn't that hard once you get the idea, and produces better, more concise tests, specially if you have to match elements with CSS classes or XPath. Do you use Selenium IDE or write from scratch ? The Launchpad team is using Windmill. From the amount of groaning I hear over there, I would avoid it at all costs. First time I hear bad sound about Windmill. Happy that I am no the only one not convinced. It is possible to run headless tests with both Selenium2 and Windmill, under xvfb-run. Pretty trivial actually. Forget about writing a ton of tiny tests though. I would say functional Selenium tests should be end-to-end, massive use case tests. Because they take a long time to run. If you think Plone tests take a long time, think again. ;) Reason why I insist on automated tests. Functional tests run too slowly to rely on developers running them regularly. We need to delegate to Hudson or buildbot. -- Sidnei Regards -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Le 18/08/10 19:01, David Glick a écrit : Godefroid, I am definitely interested to learn from your experience in this area. Regarding functional testing of Javascript, would you recommend looking at KSS to see how it is done there, or are there newer best practices that have emerged since those tests were written? I think KSS testing practices are OK. Browse to http://demo.kssproject.org/zuite/core/TestRunner.html?test=http//demo.kssproject.org/suite.html Then click Run all tests However, we miss continuous integration. I am procrastinating since a long time to refactor KSS buildout and add a builbot buildout. I guess it should not be that hard today (compared to the hell it was) when I sum up advances in Selenium RC, buildbot and buildout. I would definitely take a look at gocept.selenium. Gocept has worked a lot on it those last monthes so I guess if fits their workflow. Christian, would someone from your team mind to give us some feedback ? Regards -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Le 19/08/10 18:14, Eric Steele a écrit : On Aug 19, 2010, at 10:24 AM, Godefroid Chapelle wrote: Reason why I insist on automated tests. Functional tests run too slowly to rely on developers running them regularly. We need to delegate to Hudson or buildbot. I agree completely. I very nearly* have a Hudson/Selenium Grid/plone.app.testing pile running Selenium tests automatically across multiple browsers and machines. If I can convince the kid to give me a few free hours to work today, I'll wrap it up and write up what I have. Have you written a new layer ? Have you looked at gocept.selenium ? * For some definition of nearly Eric -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Great work so far, framework team! On 8/17/10 10:39 PM, Eric Steele wrote: * 30 PLIPs! * Cover those PLIPs which were dependencies of other PLIPs first. • 9473 (z3cform) • Ross: Better than Archetypes at form generation, better documentation than formlib, but still requires a lot of knowledge of the internals to work with. • (Small?) improvement over formlib, extensive (but not very approachable) documentation. • Approachability can be improved with layers on top: autoform, dexterity. • Heavy Plone adoption will likely lead toward better documentation. • plone.app.registry makes it largely transparent • Approved Fwiw, Martin has some partly-finished more approachable documentation at http://plone.org/products/dexterity/documentation/manual/schema-driven-forms/. He needs some help finishing it though, as he's busy updating his book. • 10877 (Plone/CMFPlone egg separation) • Concerns: • Subversion location change • Confusion of integrators looking for moved code • Win for application developers after a more stripped-down Plone, transparent to the remainder • What do we gain by doing this in a minor release? • Not particularly needed right away, but it's something that would be widely used if available. • Low risk • Precedent in Plone 3.2 • Eventually make Archetypes optional. • Should be an immediate change. Other plips will be branching Plone, it'll be a mess to merge. +1, Good call. (Too late for a few of us though...oh well, hopefully with svn mergeinfo it won't be too bad.) • 10787 (Site admin role) • Like the idea. Nervous about required updates, reindexing • Everyone who would be assigned this new role would have previously been a manager. Should be safe enough for a minor release. • Add site admin group? I've been meaning to add that as a task to the ticket. • Concern over ability of site admin to assign themselves manager rights • Remove sharing page manager role, add site admin? • Prevent site admin from gaining manager role? • Should control panels use same registry as sharing tab? I don't think the manager role appears on the sharing page. Anyway, it's a valid concern which I'll find a way to address. • 10888 (Make KSS optional) • Quick consensus • Selenium testing • KSS does this. Plone doesn't. Do we require plip to add this for rewritten work? • Approved Don't worry; if the work we do isn't tested we haven't done the job right. • 10778 (Stand-alone UUID) • Required step toward allowing Dexterity to work well in a Plone site • Community confusion that IntIds are unique identifiers, needs to be corrected • Exist as a well-used add-on that Dexterity depends on Dexterity doesn't depend on plone.app.uuid yet. • 9327 (Unified interface for lists of content) • Very useful for integrators • Being used by search results, collections PLIPs • Yes, but if the PLIPs depending on this don't make it through, likely not to include it. • Approved Will the existing folder listing templates be updated to use the new API? Doing so might be difficult to do without breaking backwards compatibility, but not doing so makes the word unified in the title a bit of a misnomer, and reduces the value of this (makes it one more thing to learn, instead of a replacement that is easier to learn). -- David Glick Web Developer davidgl...@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
On 8/18/10 7:35 AM, Godefroid Chapelle wrote: Le 18/08/10 07:39, Eric Steele a écrit : • 10888 (Make KSS optional) • Quick consensus • Selenium testing • KSS does this. Plone doesn't. Do we require plip to add this for rewritten work? Short: This plip is a chance for the FWT to give a strong push in the right direction by REQUIRING AUTOMATED tests for JS code. Longer: Plone runs more and more js code (iow in the browser), too much being untested (AFAIK). It is time to require automated tests for new JS code added to Plone core; both js unit and functional (selenium or windmill) tests. It would be an opportunity for the community to experiment and decide on best practices in this context. We need these experience and tests as we plan to integrate more complex code (iow code easier to break) like the foreseen Deco editor. I'd be happy to participate to a sprint focused on setting up those practices and building a set of tests for existing JS code. However, I am not proposing to pull the community : I tried at various sprints and miserably failed. Godefroid, I am definitely interested to learn from your experience in this area. Regarding functional testing of Javascript, would you recommend looking at KSS to see how it is done there, or are there newer best practices that have emerged since those tests were written? peace, -- David Glick Web Developer davidgl...@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
On 18-08-2010 08.07, Martin Aspeli wrote: • 10778 (Stand-alone UUID) I think my reason for wanting it in the core, is twofold: - There's a proliferation of half-solutions to this problem right now. We need something blessed that people feel safe relying on. There is a cost associated with each half-solution in terms of catalogue bloat and in terms of confusion. We have repeatedly had frustration with the lack of a unified UID system that we can depend on when writing add-ons. To base something on it as a developer, you need to know you can depend on it being available always. I don't think it makes sense to postpone it because nothing uses it yet. -- Geir Bækholt www.jarn.com/baekholt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
