Ross Patterson's Blog - Posts tagged Testing

Emerald Sprint Report Out

2013-02-13T00:00:00+00:00

Merging versioning and and constrained types into Dexterity near Beautiful Seattle.

Thanks to the fabulous Seattle Plone folk, we had another west coast sprint, the Emerald Sprint, on lovely Camano Island. The focus was polishing Dexterity, it was a gorgeous location, a very productive sprint, and I very much hope we can make it an annual thing. We might have a better chance at that if we choose a topic next year such that David can just be another sprinter for once. :-)

Firstly, I have to give a huge shout out to our Maven of Fine Dining, Sally, and to Alice for yet more above-and-beyond contributions to the culinary experience of this sprint. The food was simply incredible and I have to say I love a sprint that has that element. I was spoiled before by the cooking at the Cioppino Sprint and the Sea Sprint and the food at this sprint may have out done them!

The sprint location was an excellent choice and everything was very well organized by Cris, Luke, Fulvio and David. I was very sad to learn that Cris wasn’t going to be able to stay for the sprint and wish him the best. Thanks also to Ian Anderson and Andy Leeb for treating us to a delicious dinner out on our first night.

We did a brainstorming session where we all voted for what we found to be the most important. Then David and Matthew marked the items that they thought were clear low-hanging fruit that didn’t require a lot of design or other discussion. After seeing what the other sprinters chose for I opted for tackling some of the remaining low-hanging fruit. That ended up being two tasks both of which involved merging work done by others previously in add-ons or other packages not in Dexterity core where they belong: versioning and constrained types.

Working on versioning involved merging two add-on packages into Dexterity core. The collective.cmfeditionsdexteritycompat add-on makes it possible to use the history view on Dexterity content and I merged it into plone.app.versioningbehavior. The collective.dexteritydiff add-on brings parity with Archetypes when viewing diffs between versions and I merged it into Products.CMFDiffTool. Both packages were done by Rafael Oliveira and worked perfectly, my only job was doing the merge and reconciling the tests. Fortunately, Rafael had written tests and had done so using plone.app.testing. Unfortunately, Products.CMFEditions does not use plone.app.testing and since such tests can not run in the same test run as ZopeTestCase tests are run, that meant I had to back-port the tests Rafael wrote off of plone.app.testing back to ZopeTestCase. I hate going backwards but enough things build on the Products.CMFEditions tests that I guessed it would take too long and be to disruptive to convert all those tests. After that, I spent the rest of the sprint trying to complete my plone.app.testing.api branch which is intended to make such conversions easier.

I also had the opportunity to bring Gin Apocrypha with me and bar tend for the event. It was my first time trying to check enough items on the plane to be able to mix my whole menu and it actually worked out very well. So I think I may be willing to check a bag in the future to be able to bring Gin Apocrypha to events I don’t drive to in the future!

It was a great sprint and I love the Seattle area so I really hope this happens again. This sprint being focused on Dexterity and David being Dexterity’s maintainer and fearless leader, I know I pestered him a lot as I needed to ask questions and get perspective, but he did a great job facilitating everything. For that reason if no other, I hope the next Emerald Sprint can be on a topic such that David can get back to basics and enjoy being just another sprinter again. :-)

Updated on 13 February 2013

Imported from Plone on Mar 15, 2021. The date for this update is the last modified date in Plone.

Looking for Projects and/or a Team

2012-11-09T00:00:00+00:00

I’m available for work and am interested in contract/consultant projects or a position with a team.

I’m available and looking for new opportunities. My strengths are Python web programming, particularly Plone and Zope with strong testing skills and habits. See my LinkedIn profile or my Careers 2.0 profile for more details. I’m interested in the following:

Pyramid or Plone are preferred technologies
open to any Python web work
would be nice to work on social justice or other activism projects
open to work with a good team on any kind of project
working from remote most of the time is preferred
open to on-site opportunities in San Francisco

Please contact me if you’re looking for anyone or know of anyone who is.

Name:

Ross Patterson

Resume:

LinkedIn

Resume:

Careers 2.0

GitHub:

rpatterson

Email:

me@rpatterson.net

Phone:

+1 (415) 894-5323

IRC:

zenwryly@irc.freenode.net

plone.org:

rossp

GTalk:

merpattersonnet@gmail.com

Yahoo IM:

patterson_ross

AIM:

rosspatters

MSN:

me@rpatterson.net

Skype:

merpattersonnet

Updated on 09 November 2012

Imported from Plone on Mar 15, 2021. The date for this update is the last modified date in Plone.

Sea Sprint 2012 Report-Out

2012-09-26T00:00:00+00:00

A Python snob’s adventures in JS testing land.

I was surprised and excited to receive an invite to the first Sea Sprint from Chris Calloway. When I read that it was also being put on by Andrew Leeb and Ian Anderson of Anderson Leeb, Inc. I knew I wanted to go. I’d had the chance to hang out with them at the Plone Symposium East 2012 and the sprints before and after and enjoyed their company a lot. When I heard I could get my airfare sponsored, I knew I absolutely had to go. Not to geek out, but this was the first sprint travel sponsorship and I’m pretty excited about that.

Location and Hosting

This was one of the better organized sprints I’ve been to. Flights were coordinated to arrive and depart within 1-2 hours of each other making rides around arrival and departure fast and easy. We got to Oak Island, a beautiful and very long barrier island not far from the border with South Carolina, Friday afternoon and had some time to go to the beach and go for a quick swim.

I’d never been to the atlantic coast on either side nor had I been to the Carolinas before and have always wanted to. Living on the north Pacific for so long, I’ve never swam in warm ocean water before, very interesting. The two beach houses were right on the beach with deck walks extending out to the dunes and a covered outside area. The beds were comfy and there were great views all the way around. It was off-season but the temperatures were still warm to temperate so there were no crowds and great weather.

Chris Calloway is simply an amazing cook. He made breakfast, lunch, and dinner for 14 people almost entirely by himself both Saturday and Sunday. As if the scope of that weren’t enough, these meals were top-notch. Seriously, the food really has to be called out here. Thanks so much Chris!

The Sprint

After a delicious dinner at a local Thai restaurant sponsored by Dylan Jay, David Glick did an excellent job facilitating the planning of the sprint work. This was the most efficient sprint planning I’ve been to, great job David! Before we went to bed Friday night, we all knew what we were working on the next day.

My biggest hope for my participation in this sprint was to get better at JavaScript/ECMASCript while still contributing towards the goals of the sprint. I’ve been confounded by JS much more than I’d like and have never really been able to develop the proficiency I’d like with it. Since I learn best by writing tests with a good testing framework, I decided to work on writing JS unit tests for the bits of Deco and the toolbar that are JS heavy:

I started working with Rob Gietema, someone whose mad JS skills I’ve always admired, and Clayton Parker, who is much in the same boat as I when it comes to JS skills. Rob introduced us to Buster.JS, a new cross-browser JS unit testing framework that everyone seems to prefer to use. Clayton began writing tests for plone.app.tiles JS and I began looking into ways to integrate the Buster.JS tests into our general testing story.

In Plone land, our buildouts do a pretty good job of serving two testing purposes:

Developers: Deployed locally and give individual developers a test runner they can use to run some or all of the tests before they commit changes.
Continuous Integration: Deployed on our CI server to run all tests and catch regressions and interactions.

I set my sights on providing something that served the same two purposes for JS unit tests.

When we started, running the Buster.JS tests was a fairly manual process and done in a very different way than running our other tests. One had to:

change directories
fire up the buster-server
capture a browser slave
run buster-test

I started working on automating as much of this as possible and integrating it with our buildout test runners if possible.

I didn’t make much progress on the first day, Saturday. In the morning, I was mostly learning how things were done and understanding the architecture. After lunch, I had a pretty good idea of what I wanted to do, so I began trying to understand the Buster.JS internals enough to add what we needed. That turned out to be a pretty deep rabbit hole for me at my JS skill level so in the evening, I abandoned that effort and started writing a simple Python script that would do the all the steps for you and finally shutdown the browser slave and buster-server. At least I was getting somewhere.

With that experience under my belt, I knew that what we needed was:

test discovery
shared test fixture set up and tear down
control of which tests are run

Look familiar? These are all the services provided by zope.testrunner that we make so much use of in our buildouts.

There was one more issue in that capturing browser slaves by just running firefox meant that buster-test runs could potentially be polluted by any extensions, themes, or other add-ons in your Firefox profile. The same would be in similar senses for other browsers. This is also a familiar issue, which is precisely why selenium.webdriver does a lot to invoke the browsers it’s driving in an isolated way.

So on Sunday I set about integrating the running of Buster.JS tests with zope.testrunner and to capture browser slaves using selenium.webdriver. I did this in a new package, buster-selenium. By Sunday night, I had it integrated with the testrunner in buildout.deco such that Buster.JS tests would be run alongside the Python unittest tests. By default it would use selenium.webdriver to capture a Firefox slave and use it’s JS engine to run the tests. I also added a part to run Buster.JS unit tests and coverage reports and output XML that could be integrated into our Jenkins CI. Finally, I added support for capturing browser slaves using Selenium Grid. That was enough to release buster-selenium.

There is more that can be done:

use buster-qunit run older QUnit tests
better unittest integration, consturct one unittest.TestCase for each Buster.JS test case

Let me know if you think those would be valuable. Hearing what the interest is will make it more likely that I’ll get around to it.

Conclusion

This was a really great sprint, we got a lot done and I feel like I was able to make a worthy contribution. I’m really glad that the organizers are thinking seriously about doing this every year.

Updated on 26 September 2012

Imported from Plone on Mar 15, 2021. The date for this update is the last modified date in Plone.