Want to work alone for long periods without testing or running your code? Want to avoid doing TDD or at least test-immediately-after-coding because it breaks up your flow? Don’t want to be disturbed discussing things with your testers, product owners, and users because it takes time away from coding?

Believe it or not, there are times I’m OK with this.

I’m OK with the practices above if:

Your business stakeholders and users are happy with the system in production

New team members can pair up with an experienced member and be productive in days, not weeks

If you meet the above criteria, then it’s OK to pass up on disciplined, PROVEN approaches to software delivery–because you are meeting the end game: high-value, maintainable software that’s solving problems.

The thing is, very, VERY few people, teams, or organizations can answer all those questions affirmatively if they’re being remotely honest.

Some people, way to the right of the bell curve, and I’m talking like the miniscule number of folks out on the fifth standard deviation, can pull this off. Not intuitively, but after years of study and hard work and a metric crapton of failure.

The rest of the 99.865% of the software industry has decades of data proving how skipping careful work leads to failed projects and lousy care of our users.

Those of us who’ve been around the block a few times see the awful results time and time again: Dysfunctional organizations who can’t deliver critical internal systems but once every two or three years. Product companies folding due to angry customers and bad reputations. Miserable teams of humans trapped in death march scenarios.

Do not rationalize your concious decisions to do poor work with “I’m more effective when I just…” No. No, you are not. You think you may be, but not unless you can answer the questions above “Yes!” with confidence and honesty.

Friday, August 10, 2018

Understanding WebDriver Components

[UPDATE] This post is based on a submission I made to the official WebDriver documentation in early Spring of 2018. It's meant to help folks understand how pieces and parts fit together for WebDriver. [/]

Building a test suite using WebDriver will require you to understand and effectively use a number of different components. As with everything in software, different people use different terms for the same idea. Below is a breakdown of how terms are used in this description.

Terminology

API: Application Programming Interface. This is the set of "commands" you use to manipulate WebDriver.

Library: A code module which contains the APIs and the code necessary to implement them. Libraries are specific to each language binding, eg .jar files for Java, .dll files for .NET, etc.

Driver: Responsible for controlling the actual browser. Most drivers are created by the browser vendors themselves. Drivers are generally executable modules that run on the system with the browser itself, not on the system executing the test suite. (Although those may be the same system.) NOTE: Some people refer to the drivers as proxies.

Framework: An additional library used as a support for WebDriver suites. These frameworks may be test frameworks such as JUnit or NUnit. They may also be frameworks supporting natural language features such as Cucumber or Robotium. Frameworks may also be written and used for things such as manipulating or configuring the system under test, data creation, test oracles, etc.

The Parts and Pieces

At its minimum, WebDriver talks to a browser through a driver. Communication is two way: WebDriver passes commands to the browser through the driver, and receives information back via the same route.

The driver is specific to the browser, such as ChromeDriver for Google's Chrome/Chromium, GeckoDriver for Mozilla's Firefox, etc. The driver runs on the same system as the browser. This may, or may not be, the same system where the tests themselves are executing.

This simple example above is direct communication. Communication to the browser may also be remote communication through Selenium Server or RemoteWebDriver. RemoteWebDriver runs on the same system as the driver and the browser.

Remote communication can also take place using Selenium Server or Selenium Grid, both of which in turn talk to the driver on the host system

Where Frameworks Fit In

WebDriver has one job and one job only: communicate with the browser via any of the methods above. WebDriver doesn't know a thing about testing: it doesn't know how to compare things, assert pass or fail, and it certainly doesn't know a thing about reporting or Given/When/Then grammar.
This is where various frameworks come in to play. At a minimum you'll need a test framework that matches the language bindings, eg NUnit for .NET, JUnit for Java, RSpec for Ruby, etc.

The test framework is responsible for running and executing your WebDriver and related steps in your tests. As such, you can think of it looking akin to the following image.

The test framework is also what provides you asserts, comparisons, checks, or whatever that framework's vernacular for the actual test you're performing, eg

AssertAreEqual(orderTotalAmount, "$42");

Natural language frameworks/tools such as Cucumber may exist as part of that Test Framework box in the figure above, or they may wrap the Test Framework entirely in their own implementation.

Natural language frameworks enable the team to write tests in plain English that help ensure clarity of why you are building something and what it is supposed to do, versus the very granular how of a good unit test.

Following Up

Join the Slack Channel and ask questions. (But please, do yourself and the Selenium community a favor and first do a little research so you're asking questions in a fashion that can help others best respond!)

I spent the last week at THATConference in Wisconsin Dells, WI. It's a wonderful conference somewhat along the same lines as CodeMash, but with a very different culture and vibe.
I gave my talk "More Better Quality Coverage" which is on improving how your teams test--and understanding what modern testing and quality needs to look like.

Lots there on moving testing conversations to the left. Lots there about testing as an activity.

Thank you if you attended the session. I had some really good questions, folks were patient with my bad jokes, and there were some really good conversations after the talk.

Also: Thank you to THATConference staff and attendees. I've been to five conferences already this year. I'm finally finding myself coming out of the funk I've been in since January 10th, 2017. SeleniumConference Bangalore was the first conference I felt somewhat "myself" at. This time at THATConference I felt almost 100%.

About Me

I'm the owner/principal of Guidepost Systems. I help lots of great folks figure out what works and what doesn't in the world of delivering quality software -- something I'm very passionate about. I'm also a Father trying to remain sane while trying to build great software, herd my kids around, fix school lunches and handle the yardwork. (And roast great coffee!)