Fri 28 Feb 2014
This week saw the latest WebDriver F2F to work on the specification. We held the meeting at the Mozilla San Francisco office.
The agenda for the meeting was placed, as usual, on the W3 Wiki. We had quite a lot to discuss and, as always, was a very productive meeting.
The meeting notes are available for Tuesday and Wednesday. The most notable items are;
- Changing switchToFrame to only accept a WebElement or Index
- Adding switchToParentFrame to the API
- Potential changes to the way we do clicks on elements larger
- Numerous bugs in the spec
- Removing findElement(By.className and By.Id)
- Landed the User Interactions spec and created an endpoint for batched actions
The other amazing things that happened was we had Blackberry join the working group, especially after their announcement saying they have created an implementation.
And... how can I forget about this...
The specification is getting a lot of attention from the people that we need and want which makes me really excited!
Mon 03 Feb 2014
After much neglect I have finally put some effort into writing some documentation for the BrowserMob Proxy Python bindings however I am sure that they can be a lot better!
To do this I am going to need your help! If there are specific pieces of information, or examples, that you would like in the documentation please either raise an issue or even better create a pull request with the information, or example, that you would like to see in the documentation.
Wed 20 Nov 2013
Last week I was at W3 TPAC for week of face to face meeting to discuss WebDriver and other W3C specifications that other working groups are working on.
Our initial agenda went up just before the meeting and we were lucky enough to get through all the items. If you would like to read the notes for the meeting (Monday and Tuesday.
Highlights from the meeting are
- We are rescoping the specification to have the relevant things we need - we have been suffering from scope creep so we are removing things that aren't complete or won't be completed soon. We will be creating WebDriver "Level 2" specification which those features will go into.
- We have roughly 36 weeks worth of work to get the spec and tests done. - I will be writing details on how anyone can help make this time line realistic so we hit all of our milestones!
- We are going to be adding an API for when an element is intractable via mouse/touch, we haven't decided on a name yet but will be in the spec soon
- Simon and I were speaking to other editors/working groups to see if we could offload definitions of things to them. It seemed to be positive, let's see where things head.
There are other actions from the meeting that need to be done but I think the items above cover the main points, at least for me, that came out of the meeting.
I found the rest of the week actually really useful from a networking perspective and from a learning perspective. I have a lot of changes that I need to put into the WebDriver spec and have been getting feed back about when i am doing it wrong which is great!
Tue 19 Nov 2013
Just over a week ago I was in Shenzhen, China helping with Test The Web Forward. A great initiative to get anyone and everyone to write tests for browser companies to use. The tests are conformance tests for W3C.
In the next couple of weeks I am going to document what is needed to help out and how you, yes you, can help! The WebDriver open source test suite needs to be checked against the WebDriver Specification and then ported over or bugs raised against the spec or implementations. There will be bugs which is a great thing!
P.S. We had 4 patches with ~10 tests from people who had never used WebDriver so I consider that a great success. We also noticed a number of pain points we need to fix before we get more people involved
Wed 17 Jul 2013
Last weekend there was another HackBMTH, this time hosted by Adido. This was my first time going to a hackathon in the Bournemouth area and it was a great. Jonathan Ginn and Adam Howard are the organisers and to be honest, they did a brilliant job of organising the event.
There were people from all over Bournemouth and as far away as Reading who came to work on their little projects or create new hacks. There were ops people helping people setup Apache and a few other things. There were people creating games, one of which was a tank game that took a picture from the webcam and turned that into the level. Finally a use for QR codes!
I worked on my GitHub+Travis Firefox Add-on. I worked to start pulling in the build history of Travis CI Projects to the project page on Github. Below is a screenshot of what it looks like at the moment. It's still rough around the edges.
You can install a pre-release from Github if you want play with it. Feel free to raise bugs about it on the Github page.
The only thing that I was disappointed with was that there was only 1 female. This I should point out I don't think is the fault of the organisers. When I worked in Southampton there weren't many females applying for positions so I know the area suffers from a lack of them. I know that there are some as students, having met them at B & W Meet, so I hope that more will come. After all, one of the main reasons there are not enough woman in tech is because there are not enough woman in tech, to paraphrase Sheryl Sandberg.
Thu 27 Jun 2013
A couple weeks ago was the latest face to face of the W3C Browser Automation (WebDriver) Working Group. We as a group don't meet anywhere near enough in my opinion but when we do the conversations we have are quite amazing.
Below is the Agenda that we used for discussions. If you want to read the minutes you can read them here and here.
- Visibility of Elements
- what is considered visible?
- Interact-ability of elements
- How do we handle partially visible elements
- Elements that can't be scrolled to
- Touch Events
- Mozilla has a strawman for touch to put forward
- I spoke about this at SeConf
- Security dialogs
- Handling location, camera input, device orientation, other sensors provided to browsers
- Setting up and clearing caches
- And LocalStorage/AppCache
- Modern input types
- Interaction with Accessibility APIs such as WAI-ARIA (provided expertise is in the room) - There wasn't so we never discussed
- Interaction with SysApps, specifically testing mobile OSs based on browsers (conversation to be lead by Mozilla)
- W3C WebDriver Test Suite
- When should we meet again? TPAC 2013 is November 13-15 in China.
If you have any questions please leave a comment!
Wed 26 Jun 2013
The selenium project has for a while now wanted to create a library that allows user emulation in the browser. The project has done a reasonable job at this so far with respect to this. We check if items are in the DOM, we check the visibility of items and we normalise text from the browser, amongst our other amazing talents!
Our default position is we enforce the idea of emulation. "How would a user do this action?" is the main question we ask ourselves! So when a bug that doesn't meet that we tend not to implement it. One of these times is bug 141 - WebDriver lacks HTTP response header and status code methods. This is one of the most contentious bugs in the Selenium repository. People see Selenium as more than browser automation library, they see it as a web testing framework. Yes, Selenium RC was like this but then again Selenium RC also had ~140 methods hung off one object. We made a mistake in the past, let's try not to repeat it! Anyway, I digress, in a web testing framework world there may be times where there are use cases where you need to find out data from the response header and status codes.
So is this a feature we want to add to WebDriver? No. "But David, we do!?!?!?" I hear you cry! The use case that comes up regularly is I want to know if a server is returning a 404 or 500 when I access a page. Why is there a need to start a browser to find this out? When I asked this question on twitter, my friend and fellow committer Kevin Menard said that it could be useful to to see the page response on failure and some pages can only be accessed with a real browser. The use cases that Kevin had is you want to check that the endpoint that you originally hit might might change based on the user agent passed in or there might be a site that follows the single page idea and breaks push state and therefore most of the web semantics. I admit Kevin is right with those use cases. However its only looking at a small part of the issue and there are a lot of corner cases. The major one for me is watching XHRs. What if one of your XHR returns a 500 and you get an error? Should WebDriver show you that information as well? I am sure you can see how quickly this can escalate. If you start worrying about all requests, and you should if you are worried about the initial request to a page, then you want the browser to capture all of this information and return it in a standard format. There just happens to be a format called Http Archive (HAR).
So does the project take the task of creating a mechanism for extracting a HAR from the browser? That could be near impossible on browsers that don't readily share network usage information. So we go from WebDriver being a browser automation framework for user emulation to browser automation framework for user emulation and networking information gathering. That might be a little obtuse but its meant to be.
While Selenium's main use case is for test automation, is not solely designed for that. We want to be the best at browser automation. Proxies are really good at managing network information and reporting on it in standard formats. Examples are fiddler and browsermob-proxy. And you can even hook them into Selenium WebDriver! Like the following:
from browsermobproxy import Server
server = Server("path/to/browsermob-proxy")
proxy = server.create_proxy()
from selenium import webdriver
profile = webdriver.FirefoxProfile()
driver = webdriver.Firefox(firefox_profile=profile)
proxy.har # returns a HAR JSON blob
Yes it might be a little verbose to use them but if you really want to see that type of information then you should do it properly otherwise the real errors, that you originally wanted, will go missing.
Putting in half a solution into Selenium is just going to create scope creep and a large number of bugs because its not doing the "right" thing. The "right" thing is far too subjective for it to be done correctly.
Thu 20 Jun 2013
Last week was Selenium Conference in Boston, MA. This was the 3rd conference this year and it did
not disappoint.This was the largest Selenium Conference ever! There were around 450 people there this year and we managed to get a large number of good high quality talks.
The main take aways from the conference, other than meeting some really brilliant people, was that:
- Selenium 3 will be coming out around December.
- Marionette, also known as FirefoxDriver 2 to some is available in the Nightly branch of Firefox. If you want background please read this post
- A good automated test is indistiguishable from monitoring.
- Mobile is the future
I managed to get myself doing 2 talks at the conference but they seemed to be well received. Below are the links to the slides and videos.
Thanks to the organisers who did a great job and worked many hours to make this years conference happen. I am already looking forward to being at next years conference!
Tue 26 Feb 2013
The other day I got asked if I knew of a tool that would notice changes to IDs of elements and update Selenium tests accordingly because there was an incurred maintenance cost in updating these all the time because the test will fail.
The tl;dr; is there isn't a tool and I don't think there should ever be one
HTML documents are not complex things, far from it, so when we change them we should think about how this is going to impact everything that hangs off a page.
The non-obvious thing that they tend to forget is the test automation like, Selenium, that uses that element too!
Why? Well 9/10 times its because they don't have any ownership in the process! They don't submit tests nor do they run tests so they don't see the problem.
Now you are probably going to say "We use XPath/ CSS/ Names because (insert excuse here)!"
The point is still the same, your testing process and your development process are silo'ed and you're feeling the affects of this! Just remember everyone involved has a stake in the final product and QA aren't gate keepers for the product.
Mon 18 Feb 2013
Recently there was a bit of a rant on the Selenium users mailing list about how there were a few bugs irritating the person and, because they are only testers with not enough development experience, didnt feel that they could help with fixing these issues.
Note: this person was not rude and was not trolling so was happy to reach out.
One thing that I want people to know is that you don't have to be a brilliant developer to work on Open Source projects. You don't even have to have any experience as a software developer. You are now wondering how you can help?
By submitting a patch, even with mistakes an inexperienced would do, you are solving the problem. Once you have submitted it one thing is going to happen. Someone is going to look at your patch, eventually and reply. The reply will be we landed it or your patch needs some work. The latter is a good thing, even if you see it as a negative, since you will be learning.
Now, and is the most important thing to remember, is that the developer looking at your patch could very well learn something from you! Committers on Open Source projects tend to have come up through the ranks, unless they created the project, and have learnt what code does what where. They have learnt from other developers and want to share the knowledge back.
Going through all of these processes is a good thing. As people in software we have to be constantly learning or we fall behind. Once you are behind it can be hard to get employment in some companies you would love to work.
Next time you feel negative about contributing to Open Source, try change the thought to how you can learn something new and make a difference to your favourite projects. Selenium has getting involved bugs and Mozilla has its good first bugs that people can solve.
Don't be afraid to contribute to numerous projects because you will likely learn from a number of different people. This way you will get many years worth of meaningful experience instead of just many years of doing the same thing over and over.