Clicking Web Elements with Selenium WebDriver

Selenium WebDriver is the most popular open source package for Web UI test automation. It allows tests to interact directly with a web page in a live browser. However, using Selenium WebDriver can be very frustrating because basic interactions often lack robustness, causing intermittent errors for tests.

The Basics

One such vulnerable interaction is clicking elements on a page. Clicking is probably the most common interaction for tests. In C#, a basic click would look like this:

webDriver.FindElement(By.Id("my-id")).Click();

This is the easy and standard way to click elements using Selenium WebDriver. However, it will work only if the targeted element exists and is visible on the page. Otherwise, the WebDriver will throw exceptions. This is when programmers pull their hair out.

Waiting for Existence

To avoid race conditions, interactions should not happen until the target element exists on the page. Even split-second loading times can break automation. The best practice is to use explicit waits before interactions with a reasonable timeout value, like this:

const int timeoutSeconds = 15;
var ts = new TimeSpan(0, 0, timeoutSeconds);
var wait = new WebDriverWait(webDriver, ts);

wait.Until((driver) => driver.FindElements(By.Id("my-id")).Count > 0);
webDriver.FindElement(By.Id("my-id")).Click();

Other Preconditions

Sometimes, Web elements won’t appear without first triggering something else. Even if the element exists on the page, the WebDriver cannot click it until it is made visible. Always look for the proper way to make that element available for clicking. Click on any parent panels or expanders first. Scroll if necessary. Make sure the state of the system should permit the element to be clickable.

If the element is scrolled out of view, move to the element before clicking it:

new Actions(webDriver)
    .MoveToElement(webDriver.FindElement(By.Id("my-id")))
    .Click()
    .Perform();

Last Ditch Efforts

Nevertheless, there are times when clickable elements just don’t cooperate. They just can’t seem to be made visible. When all else fails, drop directly into JavaScript:

((IJavaScriptExecutor)webDriver).ExecuteScript(
    "arguments[0].click();",
    webDriver.FindElement(By.Id("my-id")));

Do this only when absolutely necessary. It is a best practice to use Selenium WebDriver methods because they make automated interaction behave more like a real user than raw JavaScript calls. Make sure to give good reasons in code comments whenever doing this, too.

Final Advice

This article was written specifically for clicks, but its advice can be applied to other sorts of interactions, too. Just be smart about waits and preconditions.

Note: Code examples on this page are written in C#, but calls are similar for other languages supported by Selenium WebDriver.

A Panda’s Retrospective on The Legend of Zelda: Breath of the Wild

Warning #1: This post has nothing to do with software development or testing. It is purely a post for my own pleasure.

Warning #2: SPOILER ALERT! This post is full of ’em.

The Legend of Zelda: Breath of the Wild is one of my favorite video games. Ever. I’ve been playing it regularly on my Wii U since Christmas, and I just beat the main quest. I redeemed all four Divine Beasts, found all 120 shrines, recovered all memories, and got a majority of the Korok seeds and Hyrule Compendium. It was truly the (virtual) adventure of a lifetime! In celebration of finally beating the game, I’m going to retrospect on what I loved about it so much.

What’s It About?

If you don’t know what this game is about, watch this:

Here’s the story: You, as a young man named Link, wake up in a cave with no memory about yourself or your past. As you explore the world and recover your memories, you discover that the kingdom of Hyrule was destroyed 100 years ago by the evil Calamity Ganon. Princess Zelda has sealed Ganon inside Hyrule Castle since then, but her power is weakening. You, along with four other “champions,” fought together to defeat Ganon but failed, and you yourself were nearly killed. Your main mission is to explore the land to strengthening yourself, recover lost memories, and reawaken four divine beasts. Then, you need to storm the castle to defeat Ganon, rescue Zelda, and bring a lasting peace to Hyrule.

How I Played

When BOTW was first announced as an open-world adventure, I immediately shut out all news and reviews aside from official trailers. I adamantly did not want any spoilers whatsoever. I wanted to fully explore the game on my own. And, truth be told, it was totally worth it.

When I play video games, I tend to be a completionist. I like to leave no stone unturned, and I take time to power up as much as possible before big challenges. As a result, my progress rate in BOTW was rather slow, but I feel like I didn’t miss out on anything. Even then, there are still side quests left incomplete and Korok seeds left unfound. All told, I spent 241 hours on a single save file.

botw_playtime

My total playtime after defeating Ganon.

After completing the Great Plateau and fully restoring the Sheikah Slate, my main approach to exploration was to look for shrines in a new area using the binoculars, make a mad rush for the shrine to claim a safety post, and then thoroughly search the surrounding areas for new stuff. I literally went around blind because I didn’t know where to find the Divine Beasts. Here’s roughly the path I took:

  1. Scoured Necluda for shrines for a while.
  2. Went to Zora’s Domain and reclaimed Vah Ruta.
  3. Went to the Great Hyrule Forest but couldn’t take the Master Sword.
  4. Found the Ancient Tech Lab in Akkala.
  5. Criss-crossed Hyrule Field and got blown up by Guardians.
  6. Climbed Mount Lanayru and OH CRAP THERE’S A DRAGON!
  7. Cross-dressed my way through the Gerudo Desert and reclaimed Vah Nabooris.
  8. Froze my butt off in the Gerudo Highlands.
  9. Rode through Lake Hylia and Faron.
  10. Took wings in Tabantha and reclaimed Vah Medoh.
  11. Set my butt on fire on Death Mountain and reclaimed Vah Rudania.
  12. Decided to freeze my butt off again, but this time in Hebra.
  13. Stormed Hyrule Castle, kicking butt and taking names.

For combat, I really preferred nimble melee combat. I favored single-handed weapons and spears. I got pretty good with arrows, too, and I would often try to sneak around as an archer before wailing on enemies with a sword.

guardian_artwork

Guardians – ruining Link’s day, every day.

I did not purchase the DLC, and I probably won’t anytime soon. Why? I simply don’t have time. I didn’t feel like the game was lacking without the DLC, though it looks like it adds some cool content.

What I Loved

The open world was breathtaking. The scenery was truly beautiful, and the whole game was completely explorable. Except for the very edges of the map, there were no invisible walls: if it was there, you could climb it or jump it.

https3a2f2fblueprint-api-production-s3-amazonaws-com2fuploads2fcard2fimage2f6711412fcfc041c6-cef4-4b89-8745-b3cf1d7a8570

It’s just wild.

As the player, you chose the order of events. In other Zelda games, as in most adventure games, the main quest is completely linear. The player must complete events in a certain order to progress. However, in BOTW, after fully restoring the Sheikah Slate, you can make up your own adventure. The divine beasts are recommended but not required. You can even attempt to fight Ganon immediately after stepping off the Great Plateau (though the King’s ghost rightfully says that would be foolish). If I were to play it again, I’d probably do this order: Necluda/Faron, Great Hyrule Forest, Zora’s Domain, Death Mountain, Tabantha, and Gerudo Desert.

The non-linear unfolding of memories made the story so much more engaging. Until you beat the main quest, you really don’t know everything that happened in the past. You find out bits and pieces about Link, Zelda, and the Champions all throughout the quest. The flashbacks become wonderful rewards for progression.

The Sheikah. My favorite race in BOTW are the Sheikah. They are bona fide ninjas with Jōmon stylistics. They’re the underdog good guys who help Link. They made the greatest technology in Hyrule. And for once, the Sheikah are a living, thriving people group. I loved running around Hyrule wearing the Sheikah armor in honor of the Sheikah.

tumblr_oq01gwfwmp1qhgj2mo1_500

I want a man bun like that.

The Gorons are hilarious. If the Sheikah are my #1, then the Gorons are my #2. They’re very friendly people with priceless facial expressions.

This slideshow requires JavaScript.

The music was elegantly serene. It always perfectly complemented the location. From the piano taps while crossing the fields on horseback, to the rambunctious trombones of Goron City, to the violins of Hateno Village that could move you to tears, the music was on point.

Sheikah technology is so cool. Link is running around Hyrule with a mobile phone. The only thing it can’t do is make phone calls!

sheikah-slate-breath-of-the-wild

So, somehow, Hyrule regressed after 10,000 years?

Cooking. I love cooking. The fact that it’s in a Zelda game is incredible. ‘Nuff said.

5c06dba4cd3432d490d919c0895ff0e4

Iron Chef Link!

Favorite Moments

Meeting the Sheikah monk at the end of every shrine. I loved how each monk had a unique name and pose. I also loved how the blue light would shatter as the monk blessed you with the Spirit Orb.

026

Every time was a special encounter.

The first horse. Taming, riding, and domesticating my first horse blew my mind. (Remember, I had no spoilers, not even horses.) I still have my first horse, a brown one with a white butt who I named Buttercup.

buttercup.jpg

Look at mah horse – mah horse is amazing!

The first Lynel defeat. I felt UNSTOPPABLE.

ee9

This is not easy.

The first blood moon. I panicked because I had no idea what was happening.

Discovering the Great Skeleton in Hebra. It’s in a secret, beautiful cavern under a mountain peak.

Defeating Master Kohga. I delighted in sending him straight down to hell where he belonged. I had zero tolerance for the Yiga Clan.

Finding Gorons in Gerudo Town. They don’t even know how they got it!

gtxdtk9zj7ny

It must be the gems.

Building Tarrey Town. Tarrey town is the place where all the races come together to build a productive new settlement together in peace. Everyone gets along. You can find some of the best goods in Hyrule there. It’s also the antithesis of the Great Calamity’s destruction: rather than finding previous towns decimated into ruins, Tarrey Town is the face of the new Hyrule rising from the ashes.

Finding the Hylian Shield. From the beginning, I hoped that the Hylian shield would be available somewhere in the game. I didn’t find it until the end of the game, but when I did, the shield was righteous.

Zelda’s face at the end of the game. #worthit

a87b59737f442d9c36c5eea72d68f923984f6f79_00

How is she 117 years old?

Finding out the location of Paya’s birthmark. Paya is probably my favorite character in the game. She’s a sweet, innocent Sheikah lass with a monster crush on Link. She will tell you she got her name from a papaya-seed-shaped birthmark somewhere on her body, but she won’t say where. I spent the whole game wondering where that birthmark was. Forget defeating Ganon and saving the princess, I just wanted to know. After finally completing the heirloom shrine in Kakariko Village (which was my last shrine because I overlooked the diary), Impa finally tells you.

5ynciqb

And now we know.

Some Critique

Although BOTW is marvelous, there were a few things I felt could have been improved. These critiques do not in any way mean that the game was poor.

It rains too much in Hyrule. Wanna go climbing? Nope – it’s a slip ‘n slide. Need to cook some food on-the-go? Sorry – flame goes out. Stuck waiting for time to pass? No sitting by a fire. Trying to explode a powder keg on some Bokoblins? Not today. And let’s just hurl some lighting bolts at you while you cross an open field, too. The rain does nothing but block your progress. My biggest frustration was climbing: I couldn’t explore the areas I wanted to go, and I couldn’t pass the time with a fire. Coming back later would be a hassle because I had already climbed high to get there, so I was effectively stuck. It would have been nice to have some sort of item to climb in the rain.

The weapons break too easily. The game mechanic of weapons breaking is pretty clever because it forces the player to always try new weapons. However, it feels like they break too soon. Weapon durability is a significant problem early in the game, because the player has very few inventory slots and strong weapons are hard to find. Later in the game, this is less of an issue. I think some better balancing could have been done.

There was no fishing rod. For being such an outdoorsy game, I was truly surprised that there were no fishing rods in BOTW. Link hunts deer with bows and arrows, but he needs to use bombs to catch fish? This struck me as strange and, to a small extent, thwarted the immersive feeling of surviving in the wild. A fishing rod may have been challenging to implement, but I think it could have been possible as a key item like the glider.

I craved more story points. Much of my gameplay narrative shifted between Divine Beast sagas and open exploration. At times, I felt like there was too much to explore without enough reward. I found myself avoiding enemy hideouts late in the game because I simply didn’t need their weapons or spoils. Having more memories to discover would have been awesome, though I suppose that’s what the DLC is for.

Behind the Scenes

Nintendo released a 4-part video series entitled The Making of The Legend of Zelda: Breath of the Wild that’s really cool. Video links are below.

Final Impression

I love The Legend of Zelda: Breath of the Wild. I can’t wait to see where Nintendo takes the franchise from here!

Why Choose BDD Over Other Test Frameworks?

People are heavily opinionated about Behavior-Driven Development. I frequently hear opponents say things like this:

Why would I use a BDD test framework instead of a traditional test framework like JUnit, NUnit, or pytest? The extra layer of plain language Gherkin steps gets in the way of the automation code. I can directly write code for those steps instead. BDD frameworks require lots of extra work that just doesn’t seem to add value. My team isn’t doing behavior-driven development practices, anyway.

I can sympathize with these sentiments, especially for those who have participated in projects where BDD was done poorly. Even if a team isn’t doing full behavior-driven development practices, I still assert that BDD test automation frameworks are better than traditional test frameworks for most feature testing (above-unit, black box). Here are reasons why.

Separation of Test Cases from Test Code

Test cases and test code are separate concerns. I should be able to design, discuss, and digest a test case without ever touching code. We describe features in plain language, and so we should also describe tests in plain language. Step definitions are nothing more than the automation behind the test case steps. Traditional test frameworks simply don’t have this separation of concerns, even if test methods are loaded with comments.

Guide Rails

BDD frameworks enforce good structure and layers for automation. There are designated places for test cases, step definitions, and support classes. The framework encourages good practices. Traditional test framework, however, are much more free-form. Programmers can do scary and stupid things with test classes. Functionally, a traditional test framework can still be structured well with layers and support classes, but it’s not required. Based on my experiences seeing less experienced automationeers shoving everything into Frankenstein’ed test methods, I much prefer to have the guide rails of a BDD framework.

Inherent Reusability

Steps are the building blocks of test cases, and test cases almost always have the same steps. BDD frameworks identify the step as a unique concern. One step with its definition can be used by any scenario, and steps can be parametrized for flexibility. This creates a “snowball” effect once enough steps have been developed: new tests may not require any new automation code! Traditional test frameworks simply don’t have this mechanism. It could be implemented by calling functions and classes outside of test classes, but not all automationeers are disciplined to do so, and everyone who does it will do it differently.

Aspect-Oriented Controls

Good frameworks handle cross-cutting concerns automatically. Things like logging, dependency injection, and cleanup shouldn’t interfere with test cases. BDD frameworks provide hooks to insert extra logic for these concerns around steps, scenarios, features, and even the whole test suite. Hooks can squeeze into steps because the framework is structured around steps. For example, hooks can automatically log steps to Extent Reports, instead of forcing programmers to write explicit logging calls in each test method.

giphy

The HOOKS, me bucko!

Easier Reviews

Nothing ruins your day like an illegible code review on features you don’t know. You are responsible for providing valuable feedback, but you can’t figure out what’s going on in the short amount of time you can dedicate to the review. Good Gherkin, however, makes it easy. A reviewer can review the test case apart from any code first to make sure it is a good test case. At this level, the reviewer could even be a non-technical person like a product owner. Then, the reviewer can either send the test case back with suggestions or, if the test case passes muster, dig deeper into the automation code.

Easier Onboarding

It can be hard to onboard new team members. They have so much to learn about the product, the code base, and the team practices. If tests are written using a BDD framework, then newbies can learn the features simply by reading the behavior specs. New automationeers likewise can rely on existing steps both for reuse and for examples as they develop new tests.

Other Reasons?

I’m sure there are other benefits to BDD frameworks, but these are the big ones for me. It’s an opinionated thing. Feel free to add comments below!

Are Multiple Scenario Outlines in a Feature File Okay?

Recently, someone asked me:

In Gherkin, is it good or bad practice to have multiple Scenario Outlines with Examples tables in one feature file?

The short answer is yes, it is perfectly fine to have multiple Scenario Outlines within one feature file.

However, the unspoken concern with this question is the potential size of the feature file. If one Feature has multiple Scenario Outlines with large feature tables, then the feature file could become unreadable. Remember, Gherkin is a specification language, not a programming language. A feature file should look more like a meaningful behavior example than a giant wall of text or a low-level test script. Make sure to follow good Gherkin guidelines:

  • Follow the Golden Gherkin Rule: Treat other readers as you would want to be treated.
  • Follow the Cardinal Rule of BDD: One scenario, one behavior.
  • Write declarative steps, not imperative ones.
  • Try to limit the number of steps in each scenario to single digits.
  • Use only a few rows and columns per example table.

Use, but don’t abuse, the templating facet of Scenario Outlines!

The Panda’s Dozen: Top PyCon 2018 Talks

There were tons of great talks at PyCon 2018 – more than I could attend in person – that are now available on the PyCon 2018 YouTube channel. This post has links to my favorites. Enjoy!

Check out PyCon 2018 Reflections to read my personal reflections, too. Watch my talk, Behavior-Driven Python, too!

By the Numbers: Python Community Trends in 2017/2018 (Dmitry Filippov, Ewa Jodlowska) – At the end of 2017, the Python Software Foundation teamed up with JetBrains to conduct an official Python Developers Survey. Data science is taking Python by storm, and Python 3 now has majority adoption. There are tons of other cool statistics, too!

How Netflix does failovers in 7 minutes flat (Amjith Ramanujam) – That speed at that scale is mind-blowing. This is a fascinating talk, even for non-engineers!

Solve Your Problem With Sloppy Python (Larry Hastings) – “If you ever start writing a shell script, delete it and write a Python script instead.” This talk is a jovial reminder that Python is a powerful tool, even for hack-n-slash jobs.

The AST and Me (Emily Morehouse-Valcarcel) – Emily gives a great overview of the inner workings of the Python language. This talk is a must-see for anyone into compiler theory.

Dataclasses: The code generator to end all code generators (Raymond Hettinger) – Dataclasses are new data structures to Python to generate classes based on specs.

Pipenv: the Future of Python Dependency Management (Kenneth Reitz) – Pipenv is a new tool that makes pip, Pipfile, and virtualenv easier to use together. Kenneth gives a good overview of Python packaging and why pipenv is awesome.

Type-checked Python in the real world (Carl Meyer) – Sometimes, I wish Python had static typing. Now, it can! Facebook has done some innovative things to make it possible.

Beyond Unit Tests: Taking Your Testing to the Next Level (Hillel Wayne) – Property tests + contracts = integration tests. Hillel gives a fantastic strategy for making tests smarter.

“WHAT IS THIS MESS?” – Writing tests for pre-existing code bases (Justin Crown) – This is a pragmatic guide to adding new tests to old code. Now, you’ll never procrastinate on your tests again!

Demystifying the Patch Function (Lisa Roach) – Mocking is a great practice for limiting scope in unit tests. Whether using unittest.mock or other patching/mocking packages, this is a great talk for learning why and how to do mocking in unit tests!

Automating Code Quality (Kyle Knapp) – One of Python’s most beloved traits is its elegance. Maintaining high standards of code quality can be challenging for large projects, though. Kyle shows how to use existing tools to drive higher quality.

Keynote (Ying Li) – [35:07] – Ying is a software security engineer at Docker. In her keynote, she urged all people involved in technology to learn the basics of security. Definitely watch the video recording – she used a fun story to illustrate her points.

Keynote: The People and Python (Qumisha Goss) – [1:07:35] – “Q” is a librarian at the Detroit Public Library who taught herself Python so she could teach coding classes to kids. She shared the highs and lows of her experiences, especially in light of many disadvantages her students had. My favorite takeaway was to “cultivate greatness in others.”

PyCon 2018 Reflections

PyCon is the main conference for the Python community. I attended it for the first time this year, and it was AWESOME. Here are my reflections. Enjoy!

I also compiled a list of my favorite talks at The Panda’s Dozen: Top PyCon 2018 Talks.

My Talk

The main reason I went to PyCon 2018 was to deliver a talk entitled “Behavior-Driven Python” about behave, one of Python’s most popular BDD test automation frameworks. One of my major professional goals for 2018 was to speak at a conference – and any conference would do. Fortunately for me, PyCon accepted my proposal, and Piper Companies in Raleigh graciously footed the bill! The video recording for my talk is linked below. It also has a GitHub example project and a companion article. (I’ll write a separate article with links to other talks I enjoyed.)

The Destination

PyCon 2018 was held in Cleveland, Ohio. I had never been to Cleveland before, and I found the downtown area to be charming. Everything I needed was within walking distance: the Huntington Convention Center where the conference was held, the DoubleTree by Hilton on Lakeside Ave where I stayed, the skyline, the city hall, the Rock and Roll Hall of Fame, the Great Lakes Science Center, and Lake Erie itself.

I flew into Cleveland on the evening of Thursday, May 10. Unfortunately, I missed the opening reception because my Frontier Airlines flight was delayed. (I guess I got what I paid for.) When I arrived, I had only one destination in mind: Great Lakes Brewing Company. Great Lakes has been one of my favorite breweries since I first started drinking craft beer in college. I boarded the Red Line train at the airport and rode it directly to the Ohio City station, where their pub is located. The food and beer did not disappoint!

The First Morning

PyCon 2018 had three major phases: tutorials from May 9-10, talks and events from May 11-13, and sprints from May 14-17. I attended only from May 11-13 for the “main” part of the conference. I really didn’t know what to expect, but I was blown away by what I found.

The first thing I did on the first day was registration. I showed up at about 8am to get my badge and my conference t-shirt. The volunteers also handed me a “swag bag,” pre-populated with a map and some random goodies. Since I had my backpack, I didn’t think I would need an extra bag – boy, was I wrong!

The main conference area was an expo hall full of companies and organizations giving away endless freebies, much to my naive surprise. (This was nothing like the last conference I attended, PyData Carolinas 2016.) The major stalls were Microsoft, Amazon (AWS), Google, Facebook/Instagram, LinkedIn, Anaconda, O’Reilly, and Heroku. Others included the Python Software Foundation, Django Girls, JetBrains, Elasticsearch, ChowNow, Yelp, Patreon, Squarespace, Linode, platform.sh, PostgreSQL, Nylas, DigitalOcean, DataDog, Cactus, Six Feet Up, OfferUp, Twilio, Nexmo, Okta, Pluralsight, Zapier, Bloomberg, Shopify, PyBee, EdgeDB, Anvil, and others I can’t remember. Over the three days of main events, I talked with people at nearly every stall to learn about what they do and to score that dank swag. I walked away with twelve t-shirts, five pairs of socks, laminated Python guides, a JetBrains yo-yo, a Google puzzle, Yelp gloves, a Facebook earbuds case, an OfferUp water bottle, a couple koozies, and a countless number of stickers.

While waiting for the first keynote address, I ran into Kenneth Reitz at the Python Software Foundation table. Kenneth is the original author of requests and pipenv. It was a pleasure to meet him in person. He also interviewed me for his PyCon 2018 podcast! My segment is at 19:11.

I was about to go to the keynote address when I walked by the O’Reilly stall and discovered a book signing: Harry J.W. Percival was scheduled to give away free signed copies of the second edition of his book, Test-Driven Development with Python. I got my “golden ticket,” waited in line, skipped the keynote, and scored that dankest swag of the conference. O’Reilly was giving out other books throughout the conference, but as a Software Engineer in Test, this one was the big kahuna for me. #worthit

My talk, “Behavior-Driven Python,” was scheduled at 12:10pm in Grand Ballroom A. I wasn’t terribly nervous because I had given this sort of talk many times, but I was worried that I would run out of time. Before speakers give their talks, they go to the “green room” where they test projector cables and meet the “runner” who will take them to the auditorium. I got to meet other speakers, which made me feel more comfortable. My talk got off to a delayed start due to some technical difficulties with the projector, but I think it went really well. The ballrooms could each seat several hundred people, and it looked like my talk was fairly well attended. A number of people asked me questions afterwards. Then, I ended up having lunch with a new friend I met named Gabriel, too!

The Rest of Day 1

I spent the rest of the afternoon attending talks, which can be mentally exhausting after too much. However, at the end of the day, I got to spend some sweet time with my dear friend Kennedy from college. Kennedy reached out to me before the conference to let me know that he would be there. I ran into him each day, but we got to spend the most time together sitting outside Ballroom A just catching up on life. We hadn’t seen each other since 2010 at RIT. Kennedy is really getting into software infrastructure and DevOps-like work. It was such a blessing to see him there.

Kennedy

My bro Kennedy sports that Linode shirt like a boss!

Dinner was another fortuitous blessing. ChowNow invited me to dinner and drinks at TownHall. I met their chief product officer, their engineers, and their recruiters. We talked a lot about test automation. They’re in a very similar situation as my current company, PrecisionLender: a hundred people and growing, realizing their need for automated feature tests, and discovering how hard it is to build an automation solution themselves or find someone who can. They were really great people doing awesome things, and I can’t wait to see them grow.

ChowNow also had a fun giveaway challenge. To enter, one needed to hit a REST API endpoint, which then returned further instructions. It was a bit of a puzzle – I got confused for the first few minutes, but after a hearty facepalm I figured out the challenge and successfully submitted my entry. (Python REPL and requests FTW!) The grand prize was an iPad Pro, but I won the consolation prize of $20 in ChowNow bucks. Not bad.

The Second Day

For me, Day 2 at PyCon was almost entirely about talks. The morning keynotes were really inspiring: Ying Li told a great story modeled after the Wizard of Oz about how everyone plays a part in security, and Qumisha Goss shared how she inspires kids at the Detroit public library to get into coding with Python. There were more talks I wanted to attend than I could. I learned about sloppy Python, developing arcade-style games, statistics on Python users, Appium, and compiler tools.

In the expo hall, my most memorable conversation was at the Python Bytes / Talk Python To Me table. These are major Python podcasts. Julian Sequeira of PyBites told me all about the #100DaysOfCode in Python, which I really want to try so I can learn about things beyond my domain. He then introduced me to Brian Okken, who wrote Python Testing with pytest and runs the Test and Code podcast. We talked quite a bit about testing practices and frameworks. I almost convinced him of BDD’s benefits, and he tried to convince me that unit testing is waste. It was a great conversation, and I really want to learn more about Brian’s pragmatic testing perspective.

Julian

Julian championing the Sceptre of Python!

That evening, Instagram invited me to dinner. I thought it would be drinks and appetizers at a bar, like with ChowNow. Oh, no, it was … Let me tell the story. Before PyCon started, Instagram invited me to join them for a special dinner. I think they invited me because I was a speaker. Instagram provided promo codes for a free Lyft to Crop Bistro, one of the best restaurants in the city. It resides in an old bank: marble columns and fresco paintings on the walls. When I arrived, the hostess walked me to the back, down the stairs, through the kitchen, and into the bank’s old vault, which had been converted into a private party room. They served a full three-course meal with a full bar, and it was damn good. That ribeye steak… I met a lot of great people, too. I talked with Instagram’s release manager at length about struggles with test automation. I also got to chat with a number of their engineers (many of whom were from China), as well as other Pythonistas who were invited. It was a wonderful event, and I truly thank Instagram for the invitation.

Also, I want to say that the weather in Cleveland was pretty darn cold! Daily temperatures were in the 50s, while at the same time in Raleigh, they were in the 90s. I froze my ears off walking from the hotel to the convention center!

The Third Day

At the Instagram dinner, I met a few guys who help organize Python conferences. They encouraged me to submit proposals to PyGotham and PyOhio. So, when I woke up on Day 3, I did! Hopefully, my proposals will be accepted.

The main event in the morning was the Poster expo / Job Fair. However, since I had already met most of the companies, I spent most of my time at the Rock and Roll Hall of Fame instead. I’m a huge fan of rock music. The museum had awesome exhibits with really cool memorabilia. I even got to vote for new inductees – I voted for Iron Maiden! I headed back to PyCon for the afternoon talks, but then I skipped out of the finale to finish seeing all of the Rock and Roll Hall of Fame exhibits before the museum closed.

My original dinner plan was to visit another local brewery. PyCon was hosting an event dinner at the Great Lakes Science Center, but I didn’t register in time to get a ticket. Nevertheless, my friend Kennedy offered me his meal ticket since he was returning home that afternoon. Hashtag-BLESSED. The museum was so cool. My favorite part was the NASA Glenn Visitor Center – they had one of the Apollo Skylab capsules! Many of us Pythonistas built a really tall tower out of wood blocks that we had to knock down once dinner was ready. The food was excellent, too: steak, salmon, mac ‘n cheese, green beans, and cheesecake for dessert.

My (Delta) direct flight home left on time Monday morning. I could barely fit all the swag into my suitcase! I caught a cold while attending the conference, but thankfully it didn’t take effect until I was back home.

Major Takeaways

So much happened at PyCon 2018. Even though I was doing stuff nonstop for three days, there was still so much more there to do. It will take me a few weeks to fully process everything. Here were my major takeaways:

I accomplished my goals. Before going to PyCon, I set three major goals for myself: (1) get a pulse on the state and direction of Python, (2) establish rapport in the community, and (3) become inspired to pursue greater work. CHECK! I met a lot of great people who all love using Python. A number of people really enjoyed my talk. I learned how so many groups, from top-tier Silicon Valley companies to local user orgs, are using Python to do cool stuff. There are also now just as many data scientists as web developers using Python. Seeing Python used in so many different domains really inspired me to learn more about those domains in which my knowledge is limited. I feel like I have more work to do after the conference than I did to prepare for it!

The Python community is so welcoming and friendly. When PyCon’s banner says, “For the community, by the community,” it’s true. This conference was about people much more than it was about programming. I was initially afraid that I would be lonely because I didn’t know anyone, but once I got there, everyone was outgoing; even me! Python is a language for everyone from beginners to experts, and there was no sense of elitism whatsoever at the conference. The atmosphere reminded me very much of freshman orientation week at RIT, when total strangers would strike up conversations and bestow well-wishes at every turn.

All companies have major test automation struggles. There is a universal awareness of the need for good testing, but there is also universal struggle to develop reliable feature tests at scale. Knowing that companies like Facebook/Instagram and ChowNow have problems similar to companies where I have worked gives me boosted motivation as a Software Engineer in Test to keep going!

Never write shell scripts. Just write Python scripts. Yes! This came from the “sloppy Python” talk. It’s so true. Shell scripting is so low-level and often unreadable. Plus, Python is cross-platform!

Flask is a big deal. Flask is a minimalist Pythonic web framework. It is a lightweight alternative to Django and Pyramid. Everyone was talking about it. O’Reilly was giving away books about it.

Prep for PyCon 2019! I want to return to PyCon very much. Next year, I have a better understanding of the talks, so I can make better proposals. I’ll also check out the open spaces and lightning talks. PyCon 2019 will be back in Cleveland, too!

What’s Next?

I feel like I have so much more to learn! Here’s what’s next for me:

  1. Watch videos for all the talks I missed.
  2. Come up with a personal professional development plan.
  3. Take the 100 Days of Coding challenge course.
  4. Learn about Flask, Arcade, and Pyre.
  5. Read more books about software testing.
  6. Look into data science, machine learning, containers, and security with testing.
  7. Develop more content for a blog.
  8. Write my own book(s) about software testing.
  9. Start speaking at more conferences!